This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/11/01 06:56PM I find your replies consistently helpful: may I ask for yet one more? > you keep on insisting ... resisting ... I heard these but left them to the end, on the theory that the apparent miscommunication here is an illusion. > receiver ... clocking sender's data ... abnormal Yes, very, kudos to UDma folk for fixing this. > clocking ... sender ... [implies] no need > ... for the receiver to have any preknowledge > of the number of bytes to be transferred I likewise see no need, unless we accept the common desire of host folks to limit in advance how much receiver memory the sender may write. > ... Pio ... UDma ... > The bridge ... just as well for either protocol Do we invite less confusing digressions if we speak in terms of the 16-bit Ide Dma engines of broader concern to many here rather than in terms of the bridges to Atapi well known to me? Can we agree ... The API between a PC and a 16-bit Ide Dma engine is a request to clock across at most N * 2 bytes either in or out. All other things being equal, with UDma, a 16-bit Ide Dma engine will sometimes clock more "word"s across the bus than with SwDma. This will happen whenever the device stops data out prematurely, unless the Dma engine had coincidentally, independently, chosen to delay for a turnaround time just when the device decided to stop data out. These coincidences that discourage extra "word"s may happen most often at mutually agreed block boundaries. > you keep on insisting > that the receiver "requests" bytes > during a data transfer from a sender. Sorry, I think my terminology comes from Scsi, where the REQ line is the REQ line even when it is the ACK line that is clocking data out. I mean to say the receiver's only advance indication of how many bytes to move which way is its interpretation of the Scsi command block, but the command block per se never specifies more than the max count of bytes to move. I mean now to focus on the case of UDma Data Out when the receiver chooses to move less than the max permitted by the command, especially when this hapens without the receiver reporting an ERR. > you keep on referring to ATAPI/PIO as the model, > where actually [counting arbitrary bytes in Ide] > is a clever hack. I think I see now standard Atapi Pio can count requested bytes accurately only by the accident that there the device requests via BSY:DRQ = 0:1 a count of bytes to move rather than a count of 16-bit words to move. Sorry I was ever clueless enough to think different. > The API between a PC and a 16-bit Ide Dma engine > is a request to clock across > at most N * 2 bytes either in or out. This is the only API I've ever seen in Ide source code for Wintel drivers. I'm told this is the standard API in Windows - both the '9X/ME and 2K/XP flavours. I know this is the API between a Usb host and a generic UsbMass device, that API being designed to ape the Pio legacy of Wintel Atapi. In all these cases, the API specifies the content of the Scsi command block completely independent of the max count of bytes to move which way. I'm hoping that this is accordingly the API of a typical 16-bit Dma engine on a Wintel PC motherboard. How wrong am I? Thanks again in advance. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
