This message is from the T13 list server.
> From: "Mcgrath, Jim" <[EMAIL PROTECTED]> > Date: Wednesday - December 19, 2001 5:40 PM > > x 12 0 0 0 FF 0 /i xFF > > x 12 0 0 0 FF 0 /i x1000 > > x 3B 0 02:00:00:00 0 01:FD 0 /o x1000 > you keep on mixing up > DATA IN (like INQUIRY commands) > and DATA OUT (like WRITE commands). Ah. Fun. I meant well. Often people like familiar analogies. Given that now we say here we don't like this analogy, I'm ok drawing a sharp Three way distinction: 1) host NOT wanting to move data in, 2) host wanting to move data IN, 3) host wanting to move data OUT. I think in the discussion to date I only remain confused over the thinking re moving data OUT. Only there do I see Atapi UDma 33 byte counts differing from Pio by as much as 5, like x202 instead of x1FD, where other people here by contrast see no differences larger than 1, like just x1FE instead of x1FD. > > The device may cut this transfer short arbitrarily. > That is not correct. Eh? Hmmm. Let me try first to echo what you say, you tell me if I've heard you accurately? Let H be the max count of data bytes that the standard says a command block may move. Let D be the actual count of data bytes that the device requests to move. When moving data OUT for any standard command block, Scsi requires D = H else an error. Is that what you said? With this, I agree, for each of the few standard command blocks that I know. > you tell me if I've heard you accurately? I don't understand why this is relevant. I mean to get us on the same page regarding how byte-wide asychronous Scsi decides how many bytes move, without again falling away into discussions of how Microsoft & friends should have written their code so that more rarely do we have to care how mny bytes move. I mean to focus on how byte-wide asynchronous Scsi decides D, apart from H. May I ask you to read again the following, focusing only on how true or false it is for moving data OUT, at least temporarily ignoring how true or false it is for NOT moving data and for moving data IN? "In the original byte-wide asynchronous Scsi, the device waits indefinitely for the host to answer each new REQ clock with an ACK clock. With each REQ clock, the device says to move data or not, in or out, by de/asserting C/D:I/O with each REQ. "In the simple circumstances analogous to Atapi Pio, the Scsi host & device move just command, data, and status in that order. "The Scsi host & device discover the actual byte count of data transferred as soon as the device stops asking to move data and starts asking to move status. No? If yes, then in summary we can say "the device may cut the data transfer short arbitrarily", but the Scsi standard only "requires the device to cut transfers short on occasion". "This I standby, so if it's not now obviously true to you, then we're not using the same words to mean the same thing. Can you help me guess which words are at issue? "I'm saying in Scsi, therefore likewise in Atapi, the host & device cooperate to decide the byte count that actually moves, without ever actually communicating the max permissible byte count that each has decoded independently and more or less indirectly from the command block. Thanks again in advance. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
