This message is from the T13 list server.
Courtesy people kind enough to clue me in by phone, I think I have now heard a coherent AtapiPio vs. AtapiUDma story that I can now go try to learn to say in spec words. // Key Walkway: Because the UDma protocol does not distinguish the final terminating pause from other terminating pauses, neither should the receiver or the sender. // The Bottom Line: Standard Atapi UDma DOES count bytes as well as standard Atapi Sw/MwDma. And that's as good as merely standard Atapi Pio for any even total of bytes. // The Whole Story In Three Parts: 1) From Atapi Pio Yes AtapiPio accelerators have been bursting as fast as Sw/MwDma but now won't keep up with UDma. Yes any compliant AtapiPio device differs from a merely AtaPio device by giving its host a precise, possibly odd, total of bytes moved. 2) To Atapi Sw/MwDma Yes, for N positive and even, nothing in the standard Sw/Mw/UDma protocols lets the receiver of data distinguish a sending of N bytes from a sending of N - 1 bytes, such as distinguishing 5 bytes of Atapi Inquiry data in from 6 bytes of Atapi Inquiry data in, or distinguishing 511 bytes of Atapi WriteBuffer data out from 512 bytes. 3) To Atapi UDma Yes a UDma receiver can't stop the sender on a dime, not even after receiving the last expected byte pair. Specifically in UDma 33, after any pause, the sender has the right to send another 1 or 2 clocks. Yes at even higher burst rates, the sender gains the right to send more clocks: since the round trip time holds constant, more burst clocks fit inside it. The UDma protocol passes one Crc across the bus for each terminating pause, but does not distinguish the final terminating pause of a command from any other terminating pause. Because the UDma protocol does not distinguish the final terminating pause from other terminating pauses, neither should the receiver or the sender. After any terminating pause, once the Crc's match, the receiver and sender can believe they each saw the same number of byte pairs cross the bus. Accordingly, a compliant host that has more byte pairs to send can know the device did not receive them. And a compliant device that has more byte pairs to send cannot clear DRQ and raise INTRQ. With Ata UDma, all standard traffic is block traffic, so a sender who sends more byte pairs than expected typically sends another whole block, so the host easily perceives the trouble. With Atapi UDma, we will less rarely see a sender send just one or a few unexpected additional byte pairs past the final terminating pause. This will highlight a quality of implementation issue in the receiver. To transfer bytes as reliably as Ata block transfers do, the receiver has to pass those byte pairs on or signal trouble. Most simply, the receiver could exclude the byte pairs from the Crc. Infinitesimally more reliably, the receiver could distinguish this case and complain of it. 4) Yes? Pat LaVarre P.S. I'll write back if I can dig out more about that major hard drive requiring receivers to quietly toss byte pairs received after the final terminating pause. The story I heard was that device would always clock N * 512 + 4 bytes whenever you sent an Ata xC8 Read Dma of N blocks. Hopefully I heard wrong. Subscribe/Unsubscribe instructions can be found at www.t13.org.
