This message is from the T13 list server.
On Wed, 05 Dec 2001 17:31:17 -0700, Pat LaVarre wrote: >If we can fix this without parsing the command, then we can >build a fully transparent bridge. If we can build a fully >transparent bridge, then we can use it over and over and over ... >for less and less and less dollars. I have been following this long thread of messages. Here we finally have the problem clearly stated: The desire to create tranparent bridges for X-to-ATA/ATAPI. Well, sorry, that can not be done. An ATA/ATAPI host must understand what type of command it is using... The host must know the command protocol, the direction of data movement, the number of bytes that are expected to be transferred for an error-free command execution. In the case of an X-to-ATA/ATAPI bridge it is the bridge that is the ATA/ATAPI host. I know that lots of companies would like to be in this X-to-ATA/ATAPI bridge business. I also know that many of these companies start out with little or no understanding of ATA/ATAPI. Their engineers fail to understand that they are designing an ATA/ATAPI host (the hardware, firmware and software normally found in an ATA/ATAPI host). They think it is possible to build a transparent bridge device. They fail to understand that their device must fully understand the ATA/ATAPI command protocols and even the details of every command that passes through their bridge device. Yes, the bridge must correct for things like the N vs. N-1 (odd length) data transfers especially when the bridge's host doesn't understand pad byte(s) at the end of data transfers. I don't see this as a ATA/ATAPI standards issue at all. DMA, Multiword or Ultra works just fine on the ATA and ATAPI devices I have seen so far (where it is correctly supported by the device and when the ATA/ATAPI host is a normal host). I am sorry that it is not possible to build cheap and reliable X-to-ATA/ATAPI bridge devices. But I don't think building one that works correctly is that difficult (it has been done). It just requires a full understanding of ATA/ATAPI and the designers need to work for a company that understands this is not some simple little project that can be done by one engineer in an afternoon. *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
