This message is from the T13 list server.
Pat LaVarre said: > This message is from the T13 list server. > > When you say "transfer" you could mean "copy" from > memory to memory. Absolutely not. T13 is only concerned about the ATA/ATAPI interface. When I said "transfer" or "transferred" I am talking only about what happens on the ATA/ATAPI interface. How the host hardware fetches/stores that data in system memory or how a OS driver stack moves/copys that data around in system memory is nothing T13 (or I) care about. A host that claims to be ATA/ATAPI compatible must implement the host side of the interface as described by the ATA/ATAPI-x standards. What the host hardware/software implements beyond what is required by the ATA/ATAPI-x standards is not T13's problem. Incorrectly implemented host side hardware or software is also not T13's problem - the T13 documents are well written - and if someone had a question they could post a message to this forum and get a quick answer. If, as you claim, a certain major OS supplier has failed to implement their OS driver stack correctly and their OS driver stack does not conform to the ATA/ATAPI-x requirements then that is not T13's problem. This OS vendor required devices to conform to SFF-8020 and now to ATA/ATAPI-x and if they don't implement their OS driver stack to conform to these documents then I don't know what to say other than their OS is broken. > > 1) On write commands the host side must always > > prepare an even number of bytes to transmit to the > > device. > Yes, though not necessarily contiguous in memory. How the data is organized or fetched from system memory has nothing to do with the ATA/ATAPI interface and nothing to do with how T13 defines the ATA/ATAPI interface. > > This means that if an OS application really wants > > to send an odd number of bytes the OS device driver > > must add a pad byte. > One or more pad bytes, yes. For existing ATA/ATAPI parallel interfaces there is never more than one pad byte and if that pad byte exists it is the last byte of the data transfer. This is true for all forms of data transfer: PIO, SW DMA, MW DMA and UltraDMA. > > and without accesing memory beyond the > > application's data buffer. > I find this English difficult also. > OS drivers differ in how deeply they trust the app. Yes, but this isn't T13 problem. This is an issue that the host side ATA/ATAPI hardware vendors must work out and then the host side software vendors must use that hardware correctly. Again this has nothing to do with T13 definition of the ATA/ATAPI interface. Yes, this is, or should be, part of the T13 Host Adapter standard document or at least something discussed as that document is developed. > > 2) On read commands the host side must always > > accept an even number of bytes from the device. > I find this English difficult also. What do we mean > by "accept". OK, maybe I should have said the host will always transfer an even number of bytes across the interface from the device. > > This means that if an OS application really wants > > to receive an odd number of bytes the OS device > > driver must discard the pad byte. > Same ambiguity as when copying data Out: one or more, yes. I will repeat myself: For existing ATA/ATAPI parallel interfaces there is never more than one pad byte and if that pad byte exists it is the last byte of the data transfer. This is true for all forms of data transfer: PIO, SW DMA, MW DMA and UltraDMA. > > But the most important cnncept is this: In PIO > > mode, just like in DMA mode, only an even number of > > bytes are transferred on the ATA/ATAPI interface. > Same "copy" vs. "clock" ambiguity as above. No ambiguity: Data is "transferred" on the interface. Data is "copied/moved" in system memory. I think you try to use "clocked" to mean the same thing as trnasferred? But again, T13 doesn't care how a host copies or moves data around in system memory - T13 only cares about how data is transferred on the ATA/ATAPI interface between the host and the device. > Furthermore, in Atapi Pio with an x86 host, we can > discard bytes copied to registers, without ever > dirtying extra memory. That may be true if the x86 host executes the actual ATA/ATAPI PIO data transfer via x86 instructions - may not be true if the host side hardware automates the PIO data transfer. > The x1F5:1F4 Cylinder = ByteCount value from the > device is a number between x0001 and xFFFE, SFF > consciously did not require it to be even, T13 > followed faithfully. Yes, but I said... > > In reality the BC is always an even number. This > > is because before transferring a PIO data block > > the host must perform the following computation: > > numberWords = ( BC + 1 ) / 2 And you said... > In the de facto Win 95 B standard, this calculation > was incorrect: > numberWords = ( BC ) / 2 Too bad this OS vendor did not read and understand and implement the requirements of the SFF-8020 and/or ATA/ATAPI-x documents - documents they require a device to conform to. T13 can't fix this problem. This is a broken OS. > > That is, the host must convert the BC into a word > > count every time (no exceptions): > I don't know what "no exceptions" means here, sorry. It means no exceptions: the BC value is really always an even number (really it is a "word count"). The host must conver the PIO BC value to an even number (if it isn't even) and then convert it to a "word count". > Probably not. T13 Atapi UDma was developed more > publically than Sff Atapi, developed broken, and yet > noone spoke at the time. To this day, none of my > employer's, may they ever remain anonymous, have > shipped a device that needs the speed of Atapi UDma. UltraDMA is not broken in any way at all. It works the same for ATA as it does for ATAPI. > > * Part 2 - CDBs with odd data transfer > Agreed, that's a good place to go next. > In a bus trace, the only distinction between > -x "12 0 0 0 05 0" -i 5 > -x "12 0 0 0 06 0" -i 6 > is that the x1F5:1F4 ByteCount is odd. > It is the odd number x0005 rather than the even > number x0006. I think this value, 5 or 6, that you talk about is a value passed from an OS application to an OS device driver - most likely it is the size of the applications data buffer? But we don't care here - this is something deep inside the host side software and something that T13 does not control or care about. > > The answer is that if there is to be an odd length > > data transfer only the CDB data can imply that > > (perhaps with an Allocation Length field value that > > is an odd number). > No. > For example, the cdb[4] AllocationLength of an op x12 > Inquiry tells us only the max count of bytes a > compliant device may ask to copy In. OK, I agree, during a "read" command a device can always transfer less data to the host than the host expects or the host allows. But it will still be an even number of bytes. > Whether the max count is odd or not tells us nothing > of whether the device is actually asking to copy In > an odd count or not. > Only the odd x1F5:1F4 Byte Count that tells us that. A device can transfer (not copy) only an even number of bytes. This is true for PIO and DMA. If a device actually transferred 5 data bytes and 1 pad byte it could set the BC for that data transfer to either 5 or 6 - it would not matter - the BC would be converted to 3 words by the host and 3 words would be transferred on the ATA/ATAPI interface - this is true for PIO and DMA. The only way the host can determine the number of bytes transferred (the number of bytes received by the host from the device) is to look at the CDB and/or the data received. It should be noted that this is never a real problem for SCSI "block transfer" commands. And for most other SCSI commands the data transfer is well known (like Read Capacity) or the data received from the device is "self descriptive" (like Mode Sense). Yes, I will admit that in the case of PIO the OS drive stack might be able to pass back to the OS application the total BC value for the command and that value might be an odd number. But who cares? In your example: a) If the device used a BC value of 6 then the driver would probably pass back 6. b) If the host, unknown to the application, used DMA the value passed back would most likely be 6. If the host passed back the "word count" value multiplied by 2 (the word count converted back to a byte count) then the value passed back would be 6. > No, only the device knows. A Scsi pass thru protocol > that lets the device share that info has a > competitive advantage over a protocol that does not. Maybe... But you should take this up with T10 and get them to define a way for a SCSI device to tell the host how much data it will transfer (assuming no error). Then come to T13 and get the ATAPI PACKET command protocol for PIO and DMA updated to match that capability. > In standard Atapi Dma, > as yet there is no way for the device to share its > knowledge of how many pad bytes clocked across the > bus. If there is a pad byte there is only ONE pad byte. PIO and DMA have the same number of pad bytes for the same command's data transfer - that number is 0 or 1. DMA does not add any extra pad bytes`- there are never 2, or 3, or more, pad bytes. > Pad bytes have been harmless in Ata/pi because Win 95 > B always guaranteed at least one, and because Pio > often remains an option when the command is not a > read/write op known to need the thruput of Dma. Please explain - I don't understand. > Not because anyone knows how to count them in Atapi > Dma. Counting is easy - there are 0 or 1 pad bytes. The CDB and/or the data received tell you if the pad byte exists. This is the same for PIO and DMA. Hale *** Hale Landis *** www.ata-atapi.com ***
