This message is from the T13 list server.
And speaking of old topics that keep coming back... Here is one... One more time (perhaps the last time for me), here goes... * Part 1: The Physical Interface and Command Protocol The ATA/ATAPI interface is 16-bits wide during data transfer. That means only an even number of bytes can be transferred. This rule applies to both PIO and DMA transfers. For ATAPI data transfer commands... 1) On write commands the host side must always prepare an even number of bytes to transmit to the device. This means that if an OS application really wants to send an odd number of bytes the OS device driver must add a pad byte. The OS driver must do this without violating any memory access requirements the OS may have imposed on the application program and without accesing memory beyond the application's data buffer. The only way the device knows it is receiving an odd number of bytes is by looking at the SCSI CDB data. 2) On read commands the host side must always accept an even number of bytes from the device. This means that if an OS application really wants to receive an odd number of bytes the OS device driver must discard the pad byte. The OS driver must do this without violating any memory access requirements the OS may have imposed on the application program and without accessing memory beyond the application's data buffer. The only way the device knows it should send an odd number of bytes is by looking at the CDB data. But the most important cnncept is this: In PIO mode, just like in DMA mode, only an even number of bytes are transferred on the ATA/ATAPI interface. This means that at the lowest level of the host OS device driver stack, the host software is restricted to host hardware that transfers only two bytes at a time. Nowever now we run into one of the strange things about ATAPI: the Byte Count (BC). The BC really isn't a "byte count" - it is a "word" count (a word being two bytes in the long standing x86 tradition). In reality the BC is always an even number. This is because before transferring a PIO data block the host must perform the following computation: numberWords = ( BC + 1 ) / 2 That is, the host must convert the BC into a word count every time (no exceptions): BC=1 and BC=2 is word count 1 BC=3 and BC=4 is word count 2 ... BC=59 and BC=60 is word count 30 ... BC=65533 and BC=65534 is word count 32767 and finaly the strange one BC=65535 is the same as BC=65534 or word count 32767 So why is this value a byte count and not a word count (as it should be)? My answer is because the ATAPI protocol was defined by a "secret society". Perhaps if the development of ATAPI was more open to public comment we would not still be having problems with the meaning of BC and how to handle odd BC values and how to handle BC=0 values. OK, I know, learn to live with it! (What mess will we have to live with once SATA becomes widely implemented? Sorry, just had to add that!) BC is really a "word count" and that makes PIO and DMA transfers entirely equivalent - a data transfer command will transfer the same number of words in PIO as it does in DMA. Something to think about for the future: What if the ATA/ATAPI interface could do 32-bit wide or 64-bit wide data transfers? This would be no problem for traditional ATA commands but for ATAPI it would add more pad bytes to some data transfers. BC would still be an even value: 4 or 8. Bottom line: BC is really always an even value at the physical interface and command protocol level. * Part 2 - CDBs with odd data transfer So how does ATA/ATAPI deal with SCSI CDBs that attempt to transfer an odd number of bytes? The answer is based upon the fact that at the hardware level and at the lowest level of an OS device driver stack there is no such thing as an odd length data transfer - all data transfers are for an even number of bytes (PIO and DMA). The answer is that if there is to be an odd length data transfer only the CDB data can imply that (perhaps with an Allocation Length field value that is an odd number). The answer is that only the application program that built the CDB or some higher level part of the OS driver statck that is attempting to execute the CDB knows the data transfer is an odd length. On the device side the only indication of a odd length transfer comes from looking at the CDB data. At some level within the OS device driver stack there must be an understanding of how to handle this odd transfer length request vs. the even transfer length requirement of the ATA/ATAPI interface. If an OS driver stack claims to support CDBs with odd data transfers then that OS driver stack must be properly implemented. There is nothing that can be changed in the ATA/ATAPI-x standards to fix the problem of an incorrectly implemented OS driver stack (or application program). * Part 3 - "x" interface to ATA/ATAPI bridge devices There is nothing simple about designing a X-to-ATA/ATAPI bridge device, such as 1394-to-ATA/ATAPI or USB-to-ATA/ATAPI. A bridge device of this type is very complex - it must: 1) Fully implement all the requirements of an ATA/ATAPI host. 2) Understand every ATA command or ATAPI CDB that is executed on the ATA/ATAPI side. 3) Fully implement all the requirements of the X side. 4) Understand every command on the X side. 5) Buffer and repackage data as required by the X and ATA/ATAPI sides, including adding or removing pad bytes. It is unlikely a pure hardware state machine can meet these requirements. Yes, these requirements make a bridge a very complex device. A X-to-ATA/ATAPI bridge device must implement all the requirements of a real host side OS device driver stack and all the requirements of the ATA/ATAPI physical interface and command protocols. Not a simple thing. Are there bridge devices out there that do not meet these requirements? Do they work some of the time with some X interfaces or with some ATA/ATAPI devices? Of course the answer is yes. That does not change the fact that they may be violating basic X or ATA/ATAPI interface rules. Do they work because some improperly implemented OS device driver (for X) allows the bridge to break the X or ATA/ATAPI rules? Sure. But again that does not change the fact that these are incorrectly implemented OS drivers or bridge devices. We should not be changing the standards for X or for ATA/ATAPI just because some designers fail to read the standards or take shortcuts in their hardware/software implementations. * Part Last - Need we say anything more? ? Hale *** Hale Landis *** www.ata-atapi.com ***
