This message is from the T13 list server.
> "Eschmann, Michael K" > <[EMAIL PROTECTED]> 12/07/01 06:55PM > > ... I'm amiss about the odd-byte issue floating around, > since ATA is a word interface (well, ok, CFA is an exception). > Anyone willing to fill me in (Hale, not you!)? I can't speak to CFA, but Atapi, when viewed as an alternative Scsi transport, certainly includes transfers of arbitrary byte counts. > A byte-based bridge must be responsible > for dealing with the extra byte > (when an odd-byte count was requested) > since ATA cannot deal with it. Ata can deal with the extra byte, if the transfer in question uses the AtapiPio mode. I'm asking now for the Atapi SwDma/MwDma/UDma modes to learn to deal with their (X * 2 + 1) extra bytes, where max X goes up to 5 or so with UDma 133. > AtapiPio can deal with it. The sum of DRQ INTRQ samples of x1F5:1F4 AtaCylinder (aka AtapiByteCount) is odd only if the total byte count is odd, else it is even. In effect, rather indirectly, when the total byte count is odd, the AtapiPio device has reported that one extra unwanted byte clocked across the bus. > Software must deal with it for the same reason the bridge must deal with it. Byte-based software was written without appreciating that AtapiDma distinguishes itself in contrast with other forms of Scsi by failing to communicate non-whole-block residues back to the host from the device. In practice, I hear Win95B's refusal to support odd byte counts sharply discouraged the use of them ... but I think byte counts that are not a multiple of x10 remain common, most notably the 8 bytes of the standard Atapi op x25 ReadCapacity? Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
