This message is from the T13 list server.

> Just looking to be educated
> What is all this about -:?

Here's another try at nutshelling the issue, snipped from some offline conversation 
associated yesterday with the "ohhh"s I'm hearing:

> > UDma indeterminacy ...
> pause ... only matters ... in the middle.

That would be true only if in advance the sender and the receiver always agreed where 
the middle ends ...

> UDMA is no different than PIO or DMA in regard to number of words 

True [but not significant].

I think I see you focusing on the exchange of WORDs across the bus.

Let me ask you to turn your focus awhile to a slightly larger question: how do the 
host & the device come to agree how many BYTEs have crossed the bus?

For example, suppose we have an op x12 Inquiry for 5 bytes.

How can a Usb bridge know it should pass 5 bytes on to its host, not 6?

We can't afford to teach the bridge precisely how the ... drive connected at the 
moment parses every command, even if we knew.

With AtapiPio, we don't have to.  The drive reports in x1F5:1F4 how many bytes it 
means to move.  Maybe that's x00:05.  Maybe x 00:04 + 00:01.  Maybe x 00:02 + 00:02 + 
00:01.  Whatever, we know precisely the correct byte count to pass on.  We can handle 
anything from 0 to xFF:FF:FF:FF, no worries.

With any form of Ide Dma, life gets harder.  We get only the status INTRQ, no DRQ 
INTRQ with x1F5:1F4 reports of byte count.  By definition, the drive can only ask to 
move whole "word"s.  We lose the ability to distinguish an Inquiry for 5 bytes from an 
Inquiry for 6, unless the drive helps us out.

With Ide UDma and data out, life gets harder still.  What's new there is that there is 
no protocol to tell the sender which terminating pause is the final terminating pause 
of the command.  So that sender can't know to avoid sending more clocks past the 
receivers request to pause to terminate.  So the receiver ends up receiving more bytes 
than it would have moved in Pio mode.

Teaching the bridge and the device to report a count of these extra bytes gets us back 
as much information as we had in Pio days, so we can precisely reproduce the 
bridge-to-Pio behaviour that we know works.
...


Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to