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.
