> Hi USB users :-) > This is a reply to FDOS basic how-to questions, trying to > give an introduction to Bret's drivers and a summary of > the documents or at least ideas about which bits to read.
Quite a job, Eric. Thanks. Just a few comments and corrections: > You create the bootable stick using another PC / OS. If your BIOS supports booting from USB devices, you can also just do things like FORMAT /S or SYS to make a flash drive bootable after it's been mounted in DOS. Doing things in another OS isn't necessarily always required, depending on circumstances. > Note that usbdos only uses the slower USB UHCI or USB 1.1 > transfer, but I think newer chipsets still support that as well > so the only problem is speed loss Some do, some don't. Over time, UHCI and OHCI are disappearing from the hardware. > If you do not use PS/2 for those, you will have to load > USBKEYB and USBMOUSE for your keyboard and mouse, because the > BIOS will stop helping you with USB keyboards and mice as soon > as you start using your own DOS driver for the USB controller. Sometimes yes, sometimes no, It depends on how many USB ports there are, which ports the keyboards and mice are plugged into, and which ports are associated with which UHCI controllers. USB is EXTREMELY complicated. > Maybe Bret (or Richard Bonner) could write some "quick start" > document for the average DOS user and include it in the ZIP? I would not be the one to do that. I'm "too close" to it, and certainly don't have the perspective of an average user. > 27 UHCI OHCI EHCI XHCI ... controllers: If you have USB 2, you > have both EHCI and implicitly either OHCI or UHCI USB 1 compat. On older hardware, yes. On newer hardware, the full-speed UHCI or OHCI may not exist -- only high-speed EHCI and/or super-speed XHCI. > Note that there is also OHCI, which is the not supported OTHER > variant of USB 1. If you have USB 2, you also have either UHCI > (good) or OHCI (you will need another driver). Again, true only on older hardware. Newer hardware may not have either UHCI or OHCI. > Not sure how much those 2 variants differ from each other. Maybe > Bret can explain? They are extremely different at a technical level. The biggest difference is that UHCI uses PIO (Programmed Input/Output) while OHCI uses MMIO (Memory Mapped Input/Output). PIO is much easier to use in DOS (MMIO can't be accessed from real mode). All of the internal structures and the way packets are scheduled and transmitted across the bus are also very different, so there's not a whole lot of commonality in the driver software. Having two very different standards for USB 1 was such a problem that they made sure it didn't happen again (that's why there's only one standard for USB 2, EHCI). > 29 both real mode (at most HIMEM) and VCPI (EMM386) are compatible > with the DOS drivers, but DPMI (Windows) is not. The drivers can be compatible with DPMI (depending on exactly how a program is written), and in some cases even with older version of Windows (such as 3.x). They are rarely compatible with newer versions of Windows (such as 9x). > 41 important to know: The drivers are static, so they do not do > special magic for you about plug and play. Instead, plug in the > device, then load the driver. When done, you can unload it and > then unplug the device. Those two steps are of course optional. The drivers do support plug-and-play, at least as far as it is practical to implement in DOS. It doesn't matter whether the driver is loaded before the device is plugged in, or the other way around. It doesn't do what Windows does, though, which is to have a "half driver" installed that recognizes when a device gets plugged in, and then automatically finds and loads the "second half" of the driver that actually makes the device work. The DOS architecture simply isn't designed to do that -- you need to manually install the drivers you want to use. > 84 USBDEVIC seems similar to USBUHCI options Addr./Descr./Report? USBDEVIC is the same as the USBUHCI /Address option (USBUHCI actually calls USBDEVIC to display the output). The /Descriptor and /Report options call USBSUPT1, so if you call USBSUPT1 directly the output will look similar to USBUHCI. Similarly, the USBUHCI /Host option calls USBHOSTS. The different programs call each other a lot to display status and debugging information on the screen. > 88 USBHUB adds hub support, if you have USB hubs to use. I think > USB cardreaders often have a built-in hub, / "are many readers". There is no hub involved in a cardreader. USB has a special category of devices called Mass Storage Devices (MSD), which includes flash/thumb/pen drives, floppies, hard drives, CD/DVD readers/writers, and cardreaders. They all use subsets of the SCSI protocol. The SCSI protocol allows a single device to have up to seven "sub-devices", called Logical Unit Numbers (LUNs). Cardreaders use LUNs, not hub ports, to separate the different disks from each other. LUNs are associated with /Disks option of USBDRIVE. > 142 USB storage has some similarity with SCSI, I think? Yes, they use the SCSI protocols (discussed above). It's called "SCSI Transparent" in the specifications (it's the SCSI protocol, but not the SCSI hardware). Actually, most USB devices only do a partial or bug-ridden implementation of the SCSI protocol, which is why it's so hard to write "universal" drivers for them. > 143, 144 by default, the driver allocates space 4 devices, > you can change that to a value between 1 and 8 devices and > for more than one "disk" per device. More than one disk per USB device is called a LUN, as discussed above. > I think some also count as USB hub with multiple devices instead? No, just LUNs, not hubs. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
