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 -----------------
