This message is from the T13 list server.
On Fri, 21 Dec 2001 05:42:36 -0700, Pat LaVarre wrote: >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, In ATA/ATAPI the host has limited options. If the command is a non-data command (ATA non-data or ATAPI PACKET non-data) then there is no data transfer. If the command is a "read" (data in) command (ATA or ATAPI PACKET, PIO or DMA) and if the device wants to transfer data then the host must accept that data or the host must reset the device to stop the data transfer. There is no ATA/ATAPI method (other than a reset) for a host to tell a device "I do not want any more data". >2) host wanting to move data IN, If the ATA or ATAPI PACKET "read" command then the host SHALL accept all the data the device sends. The device will determine the amount of data from only one thing: the ATA command parameters or the ATAPI PACKET SCSI CDB parameters. A correctly implemented host will have also determined the amount of data by using the same command parameter data. Of course the host could be prepared to accept more data and could be happy to let the device determine when the command is complete. >3) host wanting to move data OUT. Here in ATA/ATAPI the host is even more restricted. A properly implemented host will provide exactly the correct number of data bytes for a "write" command. If the host provides to few data bytes the device will hang with (in PIO mode) BSY=0 DRQ=1 or (in DMA mode) BSY=1 and DMARQ asserted. A host that provides too few data byte will need to reset the device in order to continue. If the host provides too many data bytes then in PIO mode that probably means the device will stop the PIO transfer and we hope the host will not attempt to write the Data register while the device status is BSY=1 (or BSY=0 DRQ=0). If the host provides too many data bytes in DMA mode then it is possible that the device might receive a few extra bytes that it SHALL ignore (except for the U-DMA CRC). Implement your ATA/ATAPI host correctly and then you will not need to worry about this. Sorry if that makes your X-to-ATA/ATAPI bridge a little more complex. There are lots of X-to-ATA/ATAPI devices out there and most must work right because they seem to be popular and mostly reliable (as long as the X side host lives within the implementataion restrictions of the bridge device). >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. Implement your ATA/ATAPI host correctly and except for a pad byte now and then you will not see this difference in byte counts. What more can we say? *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
