This message is from the T13 list server.
> I have been following this long thread of messages. Good to hear, thank you. > Here we finally have the problem clearly stated: > The desire to create tranparent bridges > for X-to-ATA/ATAPI. Sorry. I did take that as given, obvious, indisputable. I can see well now how that might not have been obvious to anyone who wasn't me or paid by my employer, but I failed to see that earlier. Just as we have done this in millions for PC parallel port to Scsi, for Usb1 to AtapiPio, now likewise we need to do this for Usb2 to UDma, else a few profitable business models are going to choke. Nothing like money for making change happen. > Well, sorry, that can not be done. I beg to differ. My simulations were dying when we began this conversation. I began posting here last week after my major partner told me this could not be fixed. Seven days later all my simulations run fine, courtesy the help I found here. Got even one concrete counter example? What is even one example where a bridge to AtapiPio needs to understand "the details of" the "command that passes" thru it ... provided the AtapiPio device is compliant with Ansi as published? Take a look at your Windows binary or your Linux source. Windows bridges transparently to Pio and Dma every day. Yes a bridge in software, not hardware, but that difference is unimportant. Their bridge includes a parameter to let the caller choose between Pio and Dma. Often the term for this is "Scsi pass through". Don't like the word bridge? How about "layer" Designing an o.s. in layers is broadly accepted good practice. It's the only known way to keep complexity manageable. Why should an app care how a device is connected? Windows bridge transparency is a little stained, granted, butit "works" in the sense Jim was speaking. Microsoft has most of us beat at the art of "good enough". Here momentarily I was in trouble only because UsbMass doesn't define a standard way to pass that parameter across the Usb cable, so I couldn't easily port what Windows does. On top of what is already standard AtapiDma, to bridge transparently, all we need is a protocol for the device to pass back across the Ide bus to the host its interpretation of the count of how many bytes to move which way. In AtapiPio, we have this protocol, as an indirect and probably inadvertent part of the standard. The I/O bit gives direction, the sum of x1F5:1F4 samples taken at DRQ INTRQ time gives the total count. In AtapiDma, we have to add protocol. First on a vendor-specific basis, then also hopefully in a standard way. > bridge ... must fully understand > the ATA/ATAPI command protocols Yes. > and even the details of every command > that passes through their bridge device. No. Do you appreciate how impractical this is back in the real world? The people who defined the de facto details of the dark corners of what commands mean are retired, even dead. It's not like someone wrote a spec and the people wrote code - it happened the other way around. It's not like a bridge ever has enough info to know what a command means anyhow. The bridge is often connected to nothing but power, the host-side bus, and the device-side bus. The device has a lot more info available internally that it can abuse in any number of creative ways to change its mind over time what a bit-identical command means. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
