This message is from the T13 list server.
By the way, T13's own English comes pretty close to acknowledging that an
Atapi Pio device reports the bus residue. I quote:
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.
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
>>> Pat LaVarre 04/15/02 07:25AM >>>
This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ]
>>> Hale Landis 04/14/02 23:45 PM >>>
...
> I'm still not sure what Pat means by "residue"
I imagine I meant different things in different contexts, sorry about that.
The "residue" that matters most is Microsoft's: the difference between the
count of bytes the host offered to copy and the count of bytes the host did
copy.
To make that residue accurate, the host & the device have to negotiate a
length of bytes to copy across the bus.
[ If you deny this T10 Sam reality, then the rest of this email will not make
sense, so please don't quote it in reply. The contemporaneous message thread
titled "on residue - not cracking the Cdb" discusses how real this reality is
or is not. ]
Now suppose we have a host that politely never does copy more bytes than the
device agrees to copy. Still the host & device may clock across the bus more
bytes than the host copies.
[ If you refuse to distinguish bytes clocked from bytes copied, then the rest
of this email will not make sense, so please don't quote it in reply. ]
The "bus residue" is then the count of these "extra" "pad" bytes.
I think "residue" is not a new term here? I hear the IgnoreWideResidue
message of parallel Scsi exists to say to be sure to discard the bus
"residue".
Nonzero bus residue occurs in AtapiPio because that bus is 2 bytes wide.
Therefore any copy of an odd count of bytes necessarily involves clocking
across an extra pad byte - a residue of one, rather than zero.
For example:
BSY DRQ C/D I/O ByteCount = 0 1 d i x00:06
3 "word"s copied In
[ busResidue = 0 = 3 * 2 - x0006 ]
BSY DRQ C/D I/O ByteCount = 0 1 d i x00:05
3 "word"s copied In
[ busResidue = 1 = 3 * 2 - x0005 ]
Nonzero bus residue occurs in AtapiDa for the same reason ... but in Dma we
can't see whether the residue is 0, 1, or N * 2.
Changing to SwDma from Pio, we lose the ByteCount, so we can't know if the bus
residue is 0 or 1. We also lose the I/O bit. If the device asked to copy
data In, then the residue after copying N "word"s is N * 2.
I claim further that that MwDma in theory and UDma in practice are less
determinate still. I vote we defer discussing MwDma and UDma until we can
agree how to express this much of the reality of Pio & SwDma.
Pat LaVarre
