> I guess I should have rephrased my goal yet even better: set flash > disk + associated port + controller + transfer speed to maximum > supported.
Understood. You're actually able to do that with Georg's or ASPI drivers. Your real problem is that you want to both do that AND use a USB keyboard at the same time. That simply may not be possible with your current hardware configuration and today's availability of drivers. It will be possible eventually, though. > BIOS bug if it starts/operates in 1.1 mode? Probably not. The BIOS should enable all controllers (OHCI & EHCI), but may not support all of your hardware (may support the keyboard but not the disk, e.g.). It's conceivable, I suppose, that the BIOS only enables OHCI and not EHCI, though that would be unusual. > Verified the device in Windows to be a 2.0 one, doing around 20MB/s. Makes sense. > 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). Actually, neither mine nor Georg's act as an ASPI manager. Acting as an ASPI manager really only makes sense if the driver is going to limit itself to disks, since USB disks use the SCSI software protocol. None of the other USB devices (hubs, keyboards, mice, printers, joysticks, cameras, Ethernet/serial adapters, audio, video, ...) use SCSI. So, while a modular USB driver could, at least theoretically, use ASPI for disks, it is actually "better" (at least in my opinion) to emulate the standard BIOS INT 13h interface for low-level access. This allows all of the standard low-level disk manipulation tools (FDISK, SYS, FORMAT, etc.) to be used on USB disks, rather than requiring special ASPI-aware tools. I actually don't have a USB CD/DVD driver yet, but when I do (or if somebody else does) it may make sense to make that use ASPI instead of making it compatible with MSCDEX. This would make it much easier to use CD/DVD writing tools in DOS. > Basic USBHOSTS seems to work for me. The D option results in "could > not obtain detailed data from the USB Host". If USBHOSTS says it can't obtain data from an OHCI or EHCI host, it probably means your BIOS has a problem. USBHOSTS uses BIOS function INT 15.87 to download configuration data from the controller, and that particular error message means INT 15.87 doesn't work on your computer. INT 15.87 is a standard BIOS function that's supposed to work on ALL computers. If you're not using an EMM (EMM386, JEMM, etc.), load one and see if it fixes the problem. EMM's are required to "intercept" INT 15.87 since the BIOS' INT 15.87 won't work correctly any more when an EMM is installed. However, this doesn't matter if you only have one OHCI controller installed (if the basic USBHOSTS only lists one). If that's the case, then you know all of the ports are on the same controller, so it would be impossible to have Georg's driver control one and the BIOS control the other. Since you are able to sometimes keep the keyboard working for a little while, I'm guessing that you probably have (at least) two OHCI controllers. But, for some reason, the BIOS doesn't work correctly when it's only managing one of the controllers and not the other. You can try swapping cables around and try to get the keyboard on the opposite controller it's on now, and likewise with the disk. Then, tell Georg's driver to exclude the one it's currently not including. I don't know if that will make a difference or not, but it could. I know on one of my computers (with UHCI) I have to install the driver for the first controller before I install the second one. If I try to install the driver for the second controller first, the system hangs. > Pity it's protocol specific, als wondering how it would act if > loading MS KEYB (or the FreeDOS one) afterwards for NLS-specific > stuff. USBKEYB is compatible with MS KEYB and compatible programs. However, depending on which particular keyboard language you're using, you may need to add a few special command-line "translation" options to USBKEYB to make sure that every single key on the keyboard is accounted for properly. Also, it's usually better to load KEYB before loading USBKEYB. Though the current USBKEYB doesn't do it, I may make a future version of USKBEYB that "adjusts" itself automatically on installation to match the KEYB language (if it detects one). That way, you wouldn't need to worry about adding any command-line "translation" options at all. I don't currently have enough information on non-US USB keyboards to even be able to attempt that, though. There is one additional thing I need to say here. Most KEYB "clones" (including the FreeDOS one) are not actually compatible with MS KEYB, and may or may not work correctly with USBKEYB. ------------------------------------------------------------------------------ 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
