This message is from the T13 list server.
>On Wed, 30 Jan 2002 11:24:51 -0700, Pat LaVarre wrote: >This message is from the T13 list server. >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. OK... AtapiDma supports odd byte transfers too... >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. Yes, but the host received 6 bytes and knows the last byte is a pad byte. It knows this because the SCSI CDB said 5 bytes would be transferred (therefore there is a pad byte). >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. Yep. >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. No, there is no confusion here. A properly programmer host side DMA engine would be programmed to receive 6 bytes. Again that is because the SCSI CDB said 5 bytes would be transferred (therefore there is a pad byte). Pat, are you aware that most x86 host side DMA engines can only be programmed to transfers words? So the host side software has no choice but make the transferred count 6 when programming the DMA engine. Therefore the host side software also knows that the last byte is a pad byte. >Yes, Ansi AtapiPio does support odd byte transfers. And so does Ansi AtapiDMA... No difference... The host side MUST (SHALL?) know that the actual transfer will be an even number of bytes and the host side must (SHALL?) program its PIO or DMA transfer to receive 6 bytes. No difference, no problem, no foul, no change needed to the ATA/ATAPI command protocols. This is all a host side issue. I am sorry if you are dealing with broken hosts but ATAPI has been around for 8+ years now and AtapiDMA should work correctly! If it doesn't then fix those broken devices and hosts. *** Hale Landis *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
