This message is from the T13 list server.
> Harlan Andrews <[EMAIL PROTECTED]> 12/10/01 10:34AM > ... > Both the host and the target know the TOTAL number of bytes required. > ... > Sorry, I don't see the problem. You almost do see the issue: you state it precisely. You only have one step further to go: all you have to add is your explanation of HOW the host and the target come to agree over how many bytes they jointly agreed to move. They observe the bus? No. Except for AtapiPio transfers, all the host & device can observe mutually is that N * 2 bytes clocked across the bus. They both see N * 2 bytes clock across, no matter that the receiver of clocks may have begun signalling to stop as far back as X * 2 - 1 bytes ago. They came to exist only after their designers read the standard? No. Some commands were not well-standardised before the host and device shipped, especially in contexts like changing power modes, removable media, varying block sizes, and so on. Of the commands that were well-standardised, Scsi often flatly requires the device to stop short of the byte count given in a command. And all this gets worse any time the out-of-band communication of block size goes awry, or anybody ships any other kind of bug that scrambles byte counts. How do the host and the target come to agree over how many bytes they jointly agreed to move? They don't agree. Not unless the device reports precisely where it cut the expected data transfer short. Ansi Ata/pi Pio gives the device a way to do this. Ansi Ata/pi Dma, as yet, provides no option for the device to do this. My current Atapi prototypes report the residue in x1F5:1F4 at x03 Status INTRQ time. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
