> 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 

> 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 

> 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, 

> 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

Reply via email to