This message is from the T13 list server.
> I don't see why this is so hard to understand?! Me neither. The bus traces are plain. > Anyone doing otherwise has a special case design, > such as your USB-ATA bridge. Yes, AtapiPio sustains more special purposes than does AtapiDma: in particular, AtapiPio lets people count bytes precisely. > ATA/ATAPI as a transport layer, > the data will always > come across the boundary as words. A helpful difference in perspective, thank you. > The data may have a pad byte, In AtapiPio, whether the data has a pad (aka residual) byte is locally visible: the data clocked across the bus ends with precisely one residual byte if and only if the sum of x1F5:1F4 Cylinder (aka byte count) was odd. AtapiDma makes the count of residual bytes locally invisible. Atapi UDma by design raises the max possible count of residual bytes with increasing burst rate. > ATA/ATAPI as a transport layer, > the data will always > come across the boundary as words. Which boundary. When moving data in, any host that thinks of Atapi as Scsi over Ide tosses residual bytes: such a host does NOT copy those bytes to memory. In Intel asm AtapiPio terms we see repeat in string quad word, then repeat in string word, then repeat in string byte. We don't see just repeat in string word. Not in AtapiPio. > You will always get an even number > of "Bytes" transferred to/from memory. No. Not in AtapiPio. Yes, me, when I do i/o, I allocate aligned pages and I leave a page free at the end. Lots of host folk are less careful. > You will always get an even number > of "Bytes" transferred to/from memory. > Anyone doing otherwise has a special case design, Yes, last I checked, Intel AtapiDma hardware didn't offer the option of carrying forward the AtapiPi legacy option of copying a precise count of bytes. Rather, the host has to allocate an even number of bytes. If this requires double-buffering, so be it. More of the "just resort to Pio when Dma doesn't work" attitude, an attitude being made obsolete as UDma learns to burst faster than Pio. > The data may have a pad byte, > that is driven by fields in the data. Yes in Ata. The Atapi story is painfully more fuzzy. We have to ask first if the data in buffer includes another byte - or will copying an extra byte cause a page fault and/or smash memory we do not own. Yea, on paper, for commands standardised before both the host & the device shipped, we can reconstruct from the data how many bytes should move. Trouble is, actual devices don't work that way. Microsoft doesn't use the fields in the data, so they're often wrong i.e. not calculated like I read the specs require them to be calculated. Best example I know is the Scsi emulation Microsoft Win2K/XP provides for Ata hard drives doesn't transfer the first 8 bytes of op x12 Inquiry data. After the command, what's in your buffer there is whatever you began with. This is Bad because the byte at offset 4 is the byte designed to tell you how many bytes moved total. Pat LaVarre -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 10:25 AM To: [EMAIL PROTECTED] Subject: [t13] yes AtapiPio supports odd byte transfers 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 Atavs 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 paifully 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. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
