This message is from the T13 list server.
Jeff W: > Just looking to be educated > What is all this about -:? >From time to time I get paid to make a remote-attached Y/X bridge work precisely as >well as direct-attached X. Just lately I turned my focus seriously for the first >time to how to make Usb2/UDma work as well as direct-attached Atapi UDma. For my employers, "but it's out of spec" is not an acceptable excuse: I have to bridge the protocol that's actually used, not the subset that is well known, not the slightly different protocol that's published. Triggering a bus analyser with existing Usb1/Pio bridges is a good way to get a quick glance at how often people violate protocol in the real world. I did just now blunder noisily around here at <mailto:[EMAIL PROTECTED]> very lost for a very long time. Sorry about that. One phone call from one listener here and I was straight again - but the conversation included one long "oooooh" from the person on the other end. I'm now deeply persuaded that I really do know what is required. > remote-attached A lot of Usb issues feel a lot like Tcp/ip issues. > Besides Atapi Inquiry, what other commands > have a variable length write or read > (i.e. you get more or less than you requested) ? This happens any time the host & the device did not adequately coordinate their understanding of the command block. To my knowledge, failing to adequately coordinate understanding is only standard with the "additional length" commands of Scsi like Inquiry. I heartily wish a failure to coordinate was a de jure and de facto standard nowhere. The de facto standards often involve a much more open loop coordination than the de jure standards. For example, I hear reports of devices that support only the x12 0 0 0 24 0 Windows flavour of op x12 Inquiry, no matter that the only way to duck this kind of misunderstanding with a standard Inquiry is to begin with x 12 0 0 0 05 0, retrieve the additional length byte, and use that to decide how many bytes to ask for. I know specifically that the Windows 2K Scsi emulation of hard drives reads rather than writes the first 8 of any N Inquiry bytes, so a host that tries to use a standard "additional length" byte ends up looking at whatever it had buffered at offset 4. > Besides Atapi Inquiry, what other commands > have a variable length write or read > (i.e. you get more or less than you requested) ? All of the "additional length" data in commands of Scsi behave this way. For example, Iomega op x03 RequestSense made x19 bytes available ... until Win95B arrived with an inability to move odd bytes even via AtapiPio. Thereafter Iomega made x1A bytes available. The extra bytes report, for example, where the heads are. If you feel like it, you can put a picture of the heads moving around on your desktop. Op x15/1A ModeSense is another good example. The sense of the bit that decides whether you get all available block descriptors differs in Scsi and SFF. Scsi says active lo, Sff says active hi. Devices that never have available block descriptors don't care. > Besides Atapi Inquiry, what other commands > have a variable length write or read > (i.e. you get more or less than you requested) ? Any firmware that implements commands without a redundant check on total byte count can behave this way. My favourite example is a device that moves 8 bytes of header when you request 2. > EVERY time I have ever seen this it falls into 1 of 3 bins: > 1) Broken device (i.e. defective) > 2) Bad software (i.e. Improper design) > 3) Badly designed device (i.e. Improper design) Yes. This kind of trouble appears only secondarily. Plug 'n play software had to break first. Any time you control both sides of the cable, you fix whoever is broken. Any time you're trying to talk to a boot Bios, or a booting o.s., or a plug 'n play o.s. with "generic" drivers, life gets harder. > Do properly designed ATAPI CD/DVD/CDRW > devices do this (I have never seen it) ? "Properly designed"? By definition no. Devices that pass WHQL qualification? Definitely yes. Devices that pass Compaq qualification? I dunno. Devices that pass Iomega qualification? I can't comment. Devices that get combined with bridges I designed? Definitely yes. This is my major source of info. > If not, then make all other devices and drivers BEHAVE. Wish I could. > BTW: I'm have no idea how you are getting anywhere near > 17MB/s out of PIO with IN/OUT turn around times of a > Pentium II and beyond. I don't get that there, though I do better on motherboards that support the quadbyte burst Pio instructions. I see 17e+6 byte/s = 2/120 byte/ns with bridges designed to deliver that. > Just looking to be educated I'm glad to feel heard. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
