Op 12-6-2011 22:26, Bret Johnson schreef: > 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.
Thanks for having written such an extensive respons :) I guess I should have rephrased my goal yet even better: set flash disk + associated port + controller + transfer speed to maximum supported. BIOS bug if it starts/operates in 1.1 mode? Verified the device in Windows to be a 2.0 one, doing around 20MB/s. > 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. Both products are incomplete I guess. Yours does about everything, seems to operate as SCSIMGR$/ASPIMGR$ (likely allowing CD drivers to work, as well as CD recording using CDRECORD/WODIM) but only works for UHCI and thus lacks drivers for OHCI/EHCI/XHCI (my system only has OHCI/EHCI). His works in a slightly more non-standard way (no SCSIMGR$, thus no CD writing?). It seems to work reasonably with handling USB ports (not devices..). Occasionally the keyboard stays working for a bit if I load it as DOSUSB /XEFFFF000. So basicly to work with his driver I'm forced to use a PS/2 keyboard, or get a USB3 PCIe controller and put keyboard on that. As for your drivers I'd have to get a PCI USB card supporting UHCI (thus Via chip I guess, no NEC, TI, whatever?) and find a way to connect case's USB2 hub to that card (provided it uses connector instead of motherboard pin header!). > 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. Basic USBHOSTS seems to work for me. The D option results in "could not obtain detailed data from the USB Host". > 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). thanks for clearing that up. Pity it's protocol specific, als wondering how it would act if loading MS KEYB (or the FreeDOS one) afterwards for NLS-specific stuff.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. I've verified USB2 speed after George's drivers by loading an ISO file from USB disk into RAM. Went a lot faster, 3secs or so. USB keyboard access is quite easily killed, haven't been able to keep it permanently. Above testing was thus done using a batchscript and afterwards pressing the reboot switch ------------------------------------------------------------------------------ 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
