This message is from the T13 list server.
> So in these cases I think we either: > 1) settle on not getting the last byte > (which is fine whenever we are discussing > ALLOCATION LENGTHs, not TRANSFER LENGTHs). I don't follow, as posted separately, in the thread titled "fewer back is always ok? say again?". > 2) get the extra byte, but rely on something somewhere > to drop the extra byte (as a uP based bridge > which cracked the command would do) Yes. I'm asking for the protocol to clue the host in: let the device tell the host when to drop the byte or not, no matter whether the host is uP based or not. > 3) add something like IGNORE WIDE RESIDUE > for packet commands using DMA. > I'd suggest that if DMA is being used then > set Byte Count High to 0 and Byte count Low to 0 > (indicating no pad) or 1 (indicating a pad byte). Yes. Except I think after UDma Out we may have as many as X * 2 + 1 pad bytes that have clocked out, with X rising with burst rate, with X = 2 for UDma 33. > Of course, one of the bits someplace else could be used > if there are some reasons to not use Byte Count > (today no value for Byte Count is defined when DMA is used, > so there could be legacy issues). > > I'd also specify that this is looked at > after the DMA is complete > (so that the device has loads of time to set the bit, > in firmware if needed). > This should mirror IGNORE WIDE RESIDUE nicely. Yes. How about an xEC/A1 Identify bit to say whether the x1F5:1F4 AtapiByteCount (aka AtaCylinder) registers at BSY:DRQ=0:0 C/D:I/O = x03 StatusIn time contain indeterminate garbage or a typically zero byte residue? Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
