> Properly working as in giving access to all disks without killing > USB keyboards.
Much easier said than done, at least in today's environment. Like Eric stated, each USB host controller can only have one "manager" -- either the BIOS or the OS. If it's the BIOS, you must accept whatever the BIOS gives you. Depending on the specific BIOS, this will be some subset of hubs, disks, mice, and keyboards, and may or may not support hot-plugging. If it's the OS, and the driver is not modular (AFAIK, all except Georg's and mine), you must accept what the driver allows. The ones that use ASPI will usually only do disks, and won't even try to manage keyboards or mice (and may not do hubs, either). I remember testing an ASPI driver a long time ago (I don't remember which one) that did support mice, but the mouse support was so bad that it was unusable. Georg's and mine are modular, so theoretically can allow a driver for any USB device to be written. From an architecture standpoint, though, Georg's and mine are VERY different. I haven't actually done much testing with Georg's drivers, but based on his documentation, Georg's only allows one USB bus transaction to be processed at a time, and is polled. E.g., if you have both a USB keyboard and a USB disk, while the disk is being accessed, the keyboard will not work (preventing you. e.g., from pressing Ctrl-C to cancel the disk access if you wanted to do that). Georg's architecture also does not support hot-plugging. My drivers are "further behind" than Georg's in that they currently only support UHCI controllers (USB ver 1 controllers from Intel and Via). However, the architecture is multi-tasking and re-entrant, is interrupt-driven rather than polled or threaded, and fully supports hot-plugging. You can have dozens of devices plugged into the same USB host controller at the same time and they will all "cooperate" with each other. AFAIK, there is no USB keyboard driver available anywhere other than mine (and some BIOS's), and likely never will be. You can use by USBHOSTS program to tell you how many host controllers you have and what kind they are (UHCI, EHCI, or OHCI). With the D (Detail) option, it will show you which ports of which hosts have devices attached to them (the columns labeled "Conn") and what speed the devices are running at (Low, Full, or High). It can't tell you which kinds of devices are attached, but can tell you whether or not anything at all is attached. By plugging and unplugging things and running USBHOSTS, you can figure out which ports are associated with which host controllers. USBHOSTS even works with EHCI and OHCI controllers that I don't have drivers for yet. If you only have one host controller, or if all the ports available on the outside of the computer are on the same host controller, you probably won't be able to "fix" your problem with just new drivers, at least right now. You might be able add another host controller, though, assuming you have spare PCI/PCMCIA slots available. > The only USB keyboard driver I know is Bret's, and it simply doesn't > even load, claiming no SCSI/ASPI driver found (despite SCSIMGR$ > existing). My driver won't claim that it can't find a SCSI/ASPI driver, since it doesn't use SCSI or ASPI. It will claim that it can't find a compatible host controller driver, the only one at this time being one for UHCI controllers (USBUHCI or USBUHCIL). > It seems like the 1.5mbit/s USB 1.1 speed is used, rather than a > 12mbit/s USB 1.1 speed, or a higher speed for USB 2.0 (provided the > flash disk is 2.0). Loading an 8MB ISO file from USB disk takes > about 25 seconds. You're running at 12 Mbps, not 1.5. The actual usable bandwidth of a USB bus is nowhere near the maximum, AT BEST 1/3 to 1/2 of it. Also remember that serial speeds are in bits/sec, not bytes/sec, so your files is actually 64 Mb. Assuming a usable bandwidth of 1/3 (4 Mbps), an 8MB (64 Mb) file would take about 16 seconds to transfer. This would be if it was a simple "serial" transfer of data, which it isn't. Part of the transfer time is also spent reading the FAT, during which time no "real" data is being transferred. 25 seconds is actually not unreasonable for an 8 MB file on a USB 1 bus. It could possibly be better, but you're not going to get it down to just a couple of seconds as I suspect you're hoping. Unless you have an EHCI (USB v2) controller installed with an appropriate driver, I don't think you'll ever see an appreciable increase in speed. Some kind of read-caching software could help. ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
