This message is from the T13 list server.
There is no state in the diagram, aye. The standard expresses the need to read x1F5:1F4 AtapiByteCount (aka AtaCylinder) only in the English text far below, never in the picture. <http://www.ietf.org/rfc/rfc1123.txt>, published in 1989, nutshells the widely accepted notion that communication is consistently successful only when people on each end of the cable work around the bugs in the code at the other end. The English there is: "be liberal in what you accept, and conservative in what you send". Accordingly, when designing hosts, you'll find you limit your compatibility if you assume that every AtapiPio device will give you only one DRQ INTRQ to move all the non-block data of any non-block command that moves less than xFFFE bytes. Symmetrically, when designing devices, you correspondingly will find you limit your compatibility if you assume that every AtapiPio host will cope if you try to use more than one DRQ INTRQ to move all the non-block data of any non-block command, especially if you move something other than precisely one block in any of the DRQ INTRQs that precede the last. Pat LaVarre >>> "Ooi, Thien Ern" <[EMAIL PROTECTED]> 12/13/01 11:33AM >>> This message is from the T13 list server. Hi Jim, Could you elaborate on your statement: "Today in ATAPI/PIO the receiver in DATA IN gets the byte count explicitly from the device in the form of register values. The receiver then uses that to generate the correct number of PIO clocks. " Isn't is true that the host always knows much PIO data it will transfer when the command is issued? Does the host need to read the taskfile in order to determine the amount of data to transfer? Specifcally, if you look at the protocol for ATAPI/PIO in the ATA/ATAPI spec (Figure 31: Host PACKET non-data and PIO data command state diagram, T13/1321D revision 3, d1321r3.pdf), there is no state to indicate that the host needs to read the taskfile to determine the amount of data to transfer. So, I conclude that the host must know in advance exactly how many PIO cycles it is going to issue, when it sees DRQ=1, which doesn't seem to agree with your statement. T.E. Ooi -----Original Message----- From: Mcgrath, Jim [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 5:57 PM To: 'Pat LaVarre'; [EMAIL PROTECTED] Subject: RE: [t13] to Dma from Pio: more Atapi clocks sent? This message is from the T13 list server. [..] So except for the possible odd byte residue problem, I still cannot see why there is a problem. Today in ATAPI/PIO the receiver in DATA IN gets the byte count explicitly from the device in the form of register values. The receiver then uses that to generate the correct number of PIO clocks. In ATAPI/UDMA the receiver gets the byte count from latching the clock transitions from the sender. The sender is sending the clocks, so the receiver does not have to worry about that. In either case the receiver always knows the number of bytes sent, and the information is ultimately always derived from actions of the device. The bridge can rely on that value just as well for either protocol - it just gets it in different ways. Jim Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
