This message is from the T13 list server.
MKE: > ATA/ATAPI can ever stop at an odd-byte boundary? > ... not specifically > due to any ATA/ATAPI interface allowance. I say yes specifically per Ansi text. In detail: Thank you for listening closely and for finding the time to speak up. I am trying hard to politely entertain the idea that I'm confused in more areas than I know, but, here, shortly, flatly: Yes, Ansi AtapiPio does support odd byte transfers. I'm sorry to hear that's not broadly appreciated. Indeed, when trading off Ata vs Atapi, I'd say a key advantage Ata holds is that this committee has very sensibly maintained that nearly all data transfers be whole block transfers. In Ata, we have only block transfers and (obsolete) long block transfers. In Atapi, we have a third kind of transfer: the non-block transfer. Before now, I don't remember hearing the existence of fully arbitrary non-block total transfer lengths seriously disputed here. Before now, only when the English gets vague did I see us raise the idea that AtapiPio doesn't transfer odd bytes. I'm so painfully familiar with how often Atapi commands do involve odd byte counts because in the real world, Win95B Atapi did not sustain the odd byte transfers that blesses Ansi on paper, so devices designed to work with more robust hosts had plug 'n play troubles there that I was paid to fix. (As of Win98, Win Atapi life suddenly became less frustrating because Microsoft suddenly added odd byte count support.) A concrete example is the common Cdb x 12 0 0 0 05 0 i.e. an op x12 Inquiry for up to 5 bytes. By Scsi, any device that has 5 or more bytes available is supposed to interpret this Cdb to mean move precisely 5 bytes in - an odd number. In AtapiPio, this works, no worries. Most commonly, there is exactly one DRQ INTRQ,the C/D I/O is then x02 DataIn, the x1F5:1F4 Cylinder (aka byte count) is 5. Not 4. Not 6. Yes 5. By Ansi text. 3 data clocks follow, 6 bytes clock across the bus, and by the AtapiPio protocol both host and device can know they agree to discard just the last byte, leaving a total of 5 bytes, merely because the DRQ byte count was odd. By Ansi text. What's missing from AtapiDma, vs. AtapiPio, is a corresponding expression of "residue" i.e. the agreed count of bytes to quietly copy into the void. I can only guess why x 12 0 0 0 05 0 is common. Clearly, the Cdb x 12 0 0 0 24 0 works better: that's the Cdb that Windows sends, and nothing plugs 'n plays so well as TalkLikeWindows. All the same, in my painfully limited experience, outside of Windows, outside of block commands, then the most popular technique for ensuring beforehand that the host and device do agree how many bytes will transfer is to stutter reads. That is, first read a header believed to be always available, then interpret that header to decide how much more to read the second time. In the case of op x12 Inquiry, the "additional length" byte is at offset 4. So to read just enough of the header to get the additional length is to read 5 bytes. So we see the Cdb x 12 0 0 0 05 0. If the byte at offset 4 is even, for example x8C, then next we see another odd length transfer, for example the Cdb x 12 0 0 0 91 0. Am I yet more clear than mud? Yes, Ansi AtapiPio does support odd byte transfers. Hope this helps, thanks in advance. Pat LaVarre >>> "Eschmann, Michael K" <[EMAIL PROTECTED]> 01/30/02 08:51 AM >>> This message is from the T13 list server. Pat, why do you insist that ATA/ATAPI can ever stop at an odd-byte boundary? It transfers data as atomic words (except for CFA, which I hope you aren't gonna confuse matters by talking about that). You may be getting this on the host-side of a USB-to-ATA/ATAPI bridge, but not specifically due to any ATA/ATAPI interface allowance. Your nsistence that this happens on ATA unnecessarily perpetuates these threads. MKE. Subscribe/Unsubscribe instructions can be found at www.t13.org.
