This message is from the T13 list server.
On Mon, 10 Dec 2001 09:54:59 -0700, Pat LaVarre wrote: >I can't speak to CFA, but Atapi, when viewed as an >alternative Scsi transport, certainly includes >transfers of arbitrary byte counts. CF (CFA) devices are really PCMCIA PC Card ATA devices. PCMCIA PC Card ATA devices are really ATA devices. All data transfers are a multiple of 512 bytes, no expections. However ATAPI is very "SCSI like" (if not just another version of "real SCSI"). SCSI does allow for odd length transfers, or at least the thing creating the SCSI CDB (application program, OS driver, X-to-ATAPI bridge chip, whatever) is allowed to create SCSI CDBs with an odd value in the "allocation length" field. I am sure many of the SCSI physical transport layers, like ATA/ATAPI, handle only even length transfers. So I would assume that it is normal for the device to expect a pad byte (on a write to the device) or for the device to provide a pad byte (on a read from the device). There should not be anything new here and it should not matter if the ATA/ATAPI host decides to use a PACKET command in PIO or DMA mode. Here again, as I have said before, it is completely the responsibility of the ATA/ATAPI host to understand the CDB it is about to send to the device and to set up all the data transfer hardware correctly. Failing to do that will most likely end with: a) some timeout condition because one side or the other will be waiting to complete the data transfer (and the command) -or- b) some error because one side or the other was smart enough to detect a data transfer length mismatch (not likely on x86 PCI bus ATA hosts). In the environment that keeps poping up here, that is an ATA/ATAPI host that is really an X-to-ATA/ATAPI brdige device, then the bridge device had better fully understand every command that is sees from its host and be prepared to take some appropriate action. That action could include modifying the CDB before sending it to the device so that at least on the ATA interface there are no data transfer mismatch errors or timeouts or worse. And a bridge must do it job correctly and make sure it does not mess up the data transfer between itself and its host. The bridge device IS THE ATA/ATAPI HOST... It must act like an ATA/ATAPI host. That means, and I can see no way around this, that the bridge device must parse and understand every SCSI CDB it processes. Bottom line... There is no such thing as an "imprecise data transfer" and there are no "residual data bytes" (even using DMA). The number of bytes that the command transfers IS THE NUMBER OF BYTES. Correct execution of the command on the ATA/ATAPI interface requires that the host (yea, including those bridge devices) transfer THAT NUMBER OF BYTES on the ATA interface. Better fux those bridge devices that try to short cut this. *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
