This message is from the T13 list server.
>>> [t13] but both host and device know >>> Hale Landis 04/12/02 21:23 PM >>> > this conversation ... the phone. I include my office/voicemail phone number in most person-to-person email, on request I'd be happy to include my pager number also. > ATA/ATAPI PIO works just like ATA/ATAPI DMA > Where or what is the difference you see? We now have actual concrete bus traces on the web, trivially reproducible, to show the reality of this difference that people here have been so consistently denying. Here I'll discuss: http://members.aol.com/plscsi/20020328/oddwinme.txt As Sbp3 folk suggested Friday, maybe the key misconception confusing the talk here is the false idea that an Atapi Cdb plainly tells the device how many bytes to copy which way. Try for example the Atapi Cdb -x 12 0 0 0 05 0. The pretty fiction published by Ansi T10 claims this Cdb asks to copy In up to 5 bytes i.e. up to all of the fixed length header that ends with the additionalLength byte at offset 4 to tell us how many more bytes the device has made available. Back in the real world, the annotated soft bus trace I mentioned i.e: http://members.aol.com/plscsi/20020328/oddwinme.txt shows us how I commonly see actual hosts and devices choose instead to copy In 8, 6, or 5 bytes. Only with AtapiPio - not with AtapiDma - do we ever see 5 bytes. Copying a T10-correct count of bytes is a competitive advantage AtapiPio, Usb, and classic parallel Scsi hold over some of the alternatives. Even with AtapiPio, we see 6 bytes instead of 5 depending on the quality of AtapiPio implementation. Always, because an Ide bus is two bytes wide, 2 * N bytes clock across the bus. The only question here is whether the device reports and the host appreciates that the last byte is meaningless. With AtapiDma, mere quaity of implementation can't rescue us. T13 offers no standard protocol for the device to report that the last N bytes were meaningless. Always, if we want to copy a fifth byte into memory, we have to also copy a sixth byte into memory. Microsoft's WinME AtapiDma implementation traced here is poor, but not uncommonly poor. Here the implementation seemingly rounds up the length of all AtapiDma copies to the nearest multiple of four. By analogy we can expect that in the years to come real people will start rounding lengths up to multiples of eight. WinME AtapiDma is at least not as broken as Win95B AtapiPio, which hung any time the AtapiPio DRQ ByteCount wasn't even. Clear now? An Atapi Cdb does not plainly tell the device how many bytes to copy which way. And neither does any vendor-specific Ata op. Nor do they plainly limit how many bytes to copy which way. Actual Cdb's correlate no more than loosely correlate with the counts of bytes the host and the device ask to copy which way. The reality of an actual bus trace is undeniable. We could still argue about how rare or common such traces are - but maybe I can't contribute much there. I have nothing but my seven years of fixing real plug 'n play troubles to back my claim that such traces are common. Thanks again all for helping me work thru why this reality is difficult to explain. Pat LaVarre
