This message is from the T13 list server.
[ BC "[EMAIL PROTECTED]".API.EXAPI, ] x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Harlan Andrews 04/15/02 06:47PM >>> > Yes. I'm talking about the 8-bit "DATA" bytes that appear on the 16-bit ATA bus. ... > Ah Ha !!! This may be the crux of the matter. > 6 bytes is what was actually transferred across the ATA BUS. > You PHYSICALLY can not transfer only 5 bytes. Yes. My English for this is that we "clock" N * 2 bytes across the bus in order to "copy" between 0 and N * 2 bytes between device and host. > Since it is PHYSICALLY impossible to transfer an odd number of 8-bit quantities across a 16-bit bus without a pad, it is suggested that the device round up to the next word boundary so that it can get ALL the requested data to the host. Not sure what you mean, sorry, but: > Thus, the device is SUPPOSED to transfer 6 > bytes (3 words) if the host asks for only 5 bytes. Yes the host & device are supposed to clock across 3 * 2 bytes to copy 5 bytes. But Ansi T13 on paper also requires an AtapiPio device to tell the host if it is asking to copy only 5 bytes and not 6. I gave a long quote before (still copied below), the key quote is "if the last transfer of a command has a pad byte, the byte count shall be odd". > Are we talking about the ATAPI Packet command ? I thought the length in the packet command was always 12 and the packet itself defined the CDB. Where do 1F4 and 1F5 get involved ? > Yep. 3 "words" across the 16-bit bus in every case. I still don't know what 1F4 and 1F5 have to do with the ATAPI Packet. Oh, sorry. I'm talking about the Data copy in the middle - between the copy of the Cdb Out and the copy of the Status In. Yes "word" 0 of op xA1 IdentifyPacketDevice data decides the cdbLength is x0C or x10. Yes the first burst to the x1F0 Data port after o x1F7 xA0 Packet should be a burst of the bytes of the Cdb, padded with zeroes out to the length decided ... in response to the device reporting BSY DRQ C/D I/O = 0 1 c o. I'm talking about later, when BSY DRQ C/D I/O = 0 1 d i. At that point in time, the x1F5:1F4 ByteCount tells us how many bytes the host copies in order to provoke another INTRQ. > Where do 1F4 and 1F5 get involved ? > Is it defined anywhere that they should have a particular value at the end of the transfer ? Not yet. > > Microsoft Win95B > I think the device did the correct thing to try to send 6 bytes (3 > words). Did Microsoft actually round down and only request 4 bytes (2 > words) ??? Seems 'odd' to me. Win95B did actually round down. This forced me to make only even amounts of data available in the device e.g. for the Cdb -x 12 0 0 0 FF 0 my device only asked to copy an even x7A count of bytes In, rather than the legacy odd count of x79. Win98 & WinMe are ok here. Back in Win95B, if you try the command -x 12 0 0 0 05 0 -i 5 with a compliant device, you see: BSY DRQ C/D I/O ByteCount = 0 1 d i x00:05 2 "word"s clocked across the bus The host & device then hung. The device was waiting for the 3rd "word" to be clocked across the bus. The host was waiting for the next INTRQ. With a rounding up device you see: BSY DRQ C/D I/O ByteCount = 0 1 d i x00:06 3 "word"s clocked across the bus The host then hung anyhow. It knew it had copied 6 bytes into a 5 byte buffer, it concluded it has 6 - 5 = xFFFF bytes left to copy, I forget the ugly details after that. With a rounding down device you see: BSY DRQ C/D I/O ByteCount = 0 1 d i x00:04 2 "word"s clocked across the bus The app then got unhappy, because it wanted a copy the 5th byte (that byte at offset 4 is the additionalLength). If you change the app to ask for another byte and to allow for another i.e. the command -x 12 0 0 0 06 0 -i 6, then everything works ok. But we were making devices, not apps. >>> Harlan Andrews 04/15/02 06:47PM >>> This message is from the T13 list server. Pat, I'll reply to your points individually here. Full copy of your message appended below. >> If there is actually a differance at the application level >> then it must be due to the operating system >> double buffering the Inquiry command in one case, >> and not in the other. > >Yes exactly. T13 AtapiPio lets the device ask the o.s. to double-buffer >at least the last byte by making the sum of x1F5:1F4 odd. T13 AtapiDma >leaves that feature out. Are we talking about the ATAPI Packet command ? I thought the length in the packet command was always 12 and the packet itself defined the CDB. Where do 1F4 and 1F5 get involved ? >Yes. Microsoft Win95B AtapiPio copied in 4 bytes when the device suggest >5 ... and then hung, waiting for another INTRQ. I mean, we're talking >about basic elementary programming here. Count of two-byte "word"s does >not equal count of bytes divided by two unless the count is not odd. Hello. I think the device did the correct thing to try to send 6 bytes (3 words). Did Microsoft actually round down and only request 4 bytes (2 words) ??? Seems 'odd' to me. > >> The device is SUPPOSED to transfer in 6 bytes >> the host requests 5. > >No ... or you lost me. > Since it is PHYSICALLY impossible to transfer an odd number of 8-bit quantities across a 16-bit bus without a pad, it is suggested that the device round up to the next word boundary so that it can get ALL the requested data to the host. Thus, the device is SUPPOSED to transfer 6 bytes (3 words) if the host asks for only 5 bytes. >Are you carefully distinguishing the 6 bytes that should be clocked across >the bus from the 5 bytes that should be copied into memory? I'm not sure, >since you chose to use the term "transfer". Yes. I'm talking about the 8-bit "DATA" bytes that appear on the 16-bit ATA bus. >Sorry, in this blizzard of email we said that once already. Specifically, >for the sake of this discussion, we've said we'll believe the hard bus >traces were: > >The Dma copy of 8 bytes In: > > 3 "words" clocked In across the bus > >The Pio copy of 6 bytes In: > > BSY DRQ C/D I/O = 0 1 D I > x1F5:1F4 ByteCount = x00:06 > 3 "words" clocked In across the bus > >The Pio copy of 5 bytes In, differing only in its ByteCount: > > BSY DRQ C/D I/O = 0 1 D I > x1F5:1F4 ByteCount = x00:05 > 3 "words" clocked In across the bus Yep. 3 "words" across the 16-bit bus in every case. I still don't know what 1F4 and 1F5 have to do with the ATAPI Packet. Is it defined anywhere that they should have a particular value at the end of the transfer ? >Potential? More like common reality. Can you name an Atapi Cd-rom that >doesn't wrongly present x1F5:1F4 = 6 in response to the Cdb -x 12 0 0 0 05 >0? I can't. > Ah Ha !!! This may be the crux of the matter. Given that I don't understand how the values for 1F5:1F4 are determined (or what they are used for), it MAY be correct for the device to put in 6, because 6 bytes is what was actually transferred across the ATA BUS. You PHYSICALLY can not transfer only 5 bytes. ...Harlan ---------------- Begin Origonal Message ---------------- Date: 4/15/02 3:45 PM Received: 4/15/02 3:49 PM From: Pat LaVarre, [EMAIL PROTECTED] To: [EMAIL PROTECTED] [ BC [EMAIL PROTECTED] ] Excerp from Pat LaVarre, 1/15/02: >... I wish somebody would go take a port to Mac OS X of the traditional Cizer >tool and try http://members.aol.com/plscsi/20020328/oddwinme.txt >and see if you don't see 6 bytes copied In when the device said to copy >In 5, for a Cdb like -x 12 0 0 0 05 0. Ouch ... x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Harlan Andrews 04/15/02 04:01PM >>> Hi! Thanks for joining in. I thought Jim M & I were making progress, but I can see Hale & I are pretty stuck. > If there is actually a differance at the application level > then it must be due to the operating system > double buffering the Inquiry command in one case, > and not in the other. Yes exactly. T13 AtapiPio lets the device ask the o.s. to double-buffer at least the last byte by making the sum of x1F5:1F4 odd. T13 AtapiDma leaves that feature out. > 6 bytes ... beats the alternative of transfering > in only 4 bytes when the host requests 5. Yes. Microsoft Win95B AtapiPio copied in 4 bytes when the device suggest 5 ... and then hung, waiting for another INTRQ. I mean, we're talking about basic elementary programming here. Count of two-byte "word"s does not equal count of bytes divided by two unless the count is not odd. Hello. > The device is SUPPOSED to transfer in 6 bytes > the host requests 5. No ... or you lost me. Are you carefully distinguishing the 6 bytes that should be clocked across the bus from the 5 bytes that should be copied into memory? I'm not sure, since you chose to use the term "transfer". > In spite of what your software analyzer seems to show, > I think you will find that the actual data words transferred > accross the ATA bus are IDENTICAL for the two devices. Sorry, in this blizzard of email we said that once already. Specifically, for the sake of this discussion, we've said we'll believe the hard bus traces were: The Dma copy of 8 bytes In: 3 "words" clocked In across the bus The Pio copy of 6 bytes In: BSY DRQ C/D I/O = 0 1 D I x1F5:1F4 ByteCount = x00:06 3 "words" clocked In across the bus The Pio copy of 5 bytes In, differing only in its ByteCount: BSY DRQ C/D I/O = 0 1 D I x1F5:1F4 ByteCount = x00:05 3 "words" clocked In across the bus > They both MUST transfer 3 DATA words > accross the bus -- independent of whether > it is PIO, SWDMA, MWDMA, or UDMA. May I vote to defer discussing MWDMA and UDMA til we understand each other re PIO and SWDMA? I agree with you that PIO and SWDMA always will clock across 3 "word"s to copy 5 or 6 bytes, and that MWDMA and UDMA do this any time the host and the device agree out of band to copy 5 or 6 bytes one way or the other. > The device is SUPPOSED to transfer in 6 bytes > the host requests 5. No ... or you lost me. May I ask you to walk me thru all this more slowly? First the Microsoft spec, then the Ansi T13 spec: 1) I'm saying, by Microsoft: a) The AtapiPio host is supposed to clock 2 * 3 bytes across the bus. b) Microsoft AtapiPio copies 2 * 3 bytes into memory if the x1F5:1F4 ByteCount is 6 when BSY DRQ C/D I/O = 0 1 d i. c) Microsoft AtapiPio copies 2 * 3 - 1 bytes into memory if the x1F5:1F4 ByteCount is 5 when BSY DRQ C/D I/O = 0 1 d i. d) Eight-bit parallel Scsi copies 2 * 3 - 1 bytes into memory when given the Cdb -x 12 0 0 0 05 0. Therefore, in Atapi Pio, the device should present x1F5:1F4 ByteCount = 5, not 6. 2) Let's now quote relevant Ansi text: Revision 18 19 August 1998 ... Ata/Atapi 4 ... 8.21 PACKET ... A0h ... 8.21.5 Normal outputs ... 8.21.5.2 Data transmission ... ... 5) if the byte count is odd, the last valid byte transferred is on DD[7:0] and the data on DD[15:8] is a pad byte of undefined value; 6) if the last transfer of a command has a pad byte, the byte count shall be odd. ... I/O - Shall be cleared to zero if the transfer is to the device. Shall be set to one if the transfer is to the host. Again, in Atapi Pio, the device should present x1F5:1F4 ByteCount = 5, not 6, to copy 5 bytes In. Furthermore, the AtapiPio host should copy in just 5 bytes, after clocking 6 bytes across. If to do that the AtapiPio host has to double-buffer, so be it. > I admit there is a potential for the device to "do it wrong" Potential? More like common reality. Can you name an Atapi Cd-rom that doesn't wrongly present x1F5:1F4 = 6 in response to the Cdb -x 12 0 0 0 05 0? I can't. > the host CAN resolve the ambiguity by requesting > an EVEN byte count for the variable length stuff > and providing adequate buffer for the "extra byte". Yes that's good practice. We should note that inaccurately forecasting the count of bytes copied can have serious speed penalties e.g. 50 to 300 ms (yes those are MILLIsecond eternities folks) for Scsi-over-Usb1. The host should instead try to construct Cdb's that don't provoke alignment troubles so commonly. The command -x 12 0 0 0 24 0 -i x24 is popular - that choice doesn't cause trouble until you have a machine with int's larger than four bytes. ----------------- End Origonal Message -----------------
