This message is from the T13 list server.
>>> Hale Landis 04/15/02 05:21PM >>>
Sorry, when it's Microsoft vs. Ansi, Microsoft wins.
Here, however, we have Ansi's own words requiring a device to tell the host to
copy only 5 bytes and not 6:
Revision 18
19 August 1998
...
Ata/Atapi 4 ...
8.21 PACKET ... A0h ...
8.21.5 Normal outputs ...
8.21.5.2 Data transmission ...
...
5) if the byte count is odd, the last valid byte transferred is on
DD[7:0] and the data on DD[15:8] is a pad byte of undefined value;
6) if the last transfer of a command has a pad byte, the byte count
shall be odd.
...
I/O - Shall be cleared to zero if the transfer is to the device. Shall
be set to one if the transfer is to
the host.
Surely the assymetry between this T13 text and the analogous T13 text for
AtapiDma is plain?
How does it serve anyone's interest here in T13 to have the choice between Pio
& Dma change the count of bytes copied?
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
>>> Hale Landis 04/15/02 05:21PM >>>
>Take the now familiar example of Cdb -x 12 0 0 0 05 0. In
>unambiguous English, Ansi T10 claims this Cdb means copy between
>0 and 5 bytes In. But the trivially repeatable trace
>http://members.aol.com/plscsi/20020328/oddwinme.txt shows that
>Windows often decides instead to copy In 8 or 6 bytes, not just
>5.
OK, but this is a Windows driver stack issue. And for all I know
the Windows driver documentation tells why this happens. I'm
sure it is not some random action just to confuse us. Sure,
maybe it is poor software design or even a bug that should be
fixed but it has nothing to do with the ATA interface or the
actual exection of ATA or ATAPI PACKET commands on the ATA
interface.
...
