crazii/USBDDOS

USB Hub, Wireless, Printer, etc.

Opened this issue · 15 comments

Torinde commented

Is it possible to add support for ...?

crazii commented

Theoretically it is possible, but..., by the current state of USBDDOS (which is not stable and only works in VirtualBox), it is very hard for now.
I've tested it on some real machine, there are various problems (i.e. controller not found, USB mouse emulation behaving wrong with DOS games).

crazii commented

Theoretically it is possible, but..., by the current state of USBDDOS (which is not stable and only works in VirtualBox), it is very hard for now.
I've tested it on some real machine, there are various problems (i.e. controller not found, USB mouse emulation behaving wrong with DOS games).

crazii commented

My network is f**ked and cannot post comment, sorry if I cannot reply you in time.

Torinde commented

OK, I understand. I've seen mentioned an example set of USB drivers for DOS - USBUHCI, USBMOUSE, CuteMouse - per the description at Bret Johnson's page it includes source code and UHCI drivers for keyboards, mice, joysticks, printers, disk drives, and hubs, as well as several different test and support programs. Will that help?

Another use-case are external USB-to-ISA adapters 1 2 - they even sell dosbox-x.conf and win9x.img files! I wonder how they get access to the USB-attached ISA slots in DOSbox-X - via .conf chages, by some DOS driver, by changing the DOSbox-X source code itself?

crazii commented

Yes that helps, actually some of the USBDDOS code has the same implementations (maybe in different form, inlined asm or C etc) because I learned from it :D. there's also comment in the source code that have mentioned it or have links.

  • 👍2
Torinde commented

FYI, USB in DOS - I don't see anything directly applicable to this project, but maybe there is something (it has general information, mentions the USBDOS from above, a commercial/closed source DOSUSB product, links to some USB device drivers for DOS)

  • 👍1
jan-kleks commented

@crazii It would have been lovely to have support for Xbox controllers (it is probably the most popular gamepad for PCs). With gamepads/joysticks support in (potentially simulating a keyboard/mouse if necessary) + SBEMU, modern DOS gaming would become so much easier...

  • 👍1
Torinde commented

Simulating keyboard (parts of), mouse, joystick/gamepad via each other is a useful function, yes.

  • 👍1
Torinde commented

@crazii, you already added Hub support, that's great!
Does it support low speed hubs connected to high speed hubs?

Joystick, Printer, Serial port - added note to top post that those are supported by Bret Johnson's code. If you're going to use that please take in mind a few pending items for it:

  • FAT28 capability autodetection doesn’t work with EDR-DOS - use switch to override
  • INT $13 support is not always uninstalled well at driver removal and causes a mess after reinstalling (Bad: don’t uninstall or reboot after)
  • Very slow - there is a switch to override, by default it’s “better safe than fast” for now
  • Callback address rejection doesn’t always work (just don’t try it)
  • Various efficiency and “internal” source issues
  • Some referenced documentation files don’t exist yet

Does USBDDOS exhibit some of the first four issues? Does it support hotplugging and can it be load/unload itself from the command line?

crazii commented

Forgive me for my ignorance, I never heard of FAT28, is it a FAT file format? or joystick/serial related?
Also I didn't implement INT 13 hook in the BIOS level, just a install & modify of DOS drivers to handle disk IO, I don't know whether it is enough. Let me know if there's any test cases.
Callback address rejection - I didn't know that it stands for either, please help me clarify. Any links will help.
It may be because I only read some specific part of Bret Johnson's driver, not all of them. I read about the HID part.

I thought about hotplugging, it can be done, but the hardest part is hot-unplugging, there's too much cases to cause errors, and unrecoverable errors.
USBDDOS loads itself in the command line, not in CONFIG.SYS (not supported), but there's no unloading. The worst cases of unloading is like unplugging, i.e. usbddos gained control of drive C (a booting USB disk) and unloading usbddos will make the system unable to run.

I didn't read the spec about low speed hubs yet, whether it needs special handling. There's special handling for low speed devices, if a low speed device connected to a high speed hub, USBDDOS can handle it in EHCI, not the in hub driver. For a low speed hub - it should work, because a low speed hub acts like any other low speed devices. Maybe the spec is just dedicated to the bus protocol in HW level, no extra handling for low speed hubs. But I'm not 100% sure, that remains to be found out.

  • 👍1
Torinde commented

The six bullets come from here, I don't have a lot more info except per my understanding:

As specified by Microsoft, the upper 4 bits of each FAT entry of a "FAT32" file system are reserved and must be ignored. This results in only 28, not 32, actually usable bits in each FAT entry.

Low speed hubs connected to high speed hubs - that's mentioned as one of the TODO items for DOSUSB, along with Isochronous transfer, thus it warrants at least testing/confirmation.

Agree that unplugging/unloading is tricky for storage. Although, please consider:

  • hot-plugging is useful even without unplugging - and for all devices, not only storage
  • hot-unplugging and unloading is useful for non-storage devices (and maybe it just works for some)
  • hot-unplugging issues are the same for modern operating systems (e.g. user can unplug a device without clicking/waiting for "safe to remove hardware")
  • DOS being single task should mostly prevent issues with unplugging/unloading. In addition to:
    • system drive is a special case - maybe when loading give warning to user not to unplug the system drive if it's USB (regardless if managed by USBDDOS or BIOS) and also don't allow unloading if system drive is managed by USBDDOS.
    • for other storage devices - when user requests unplug/unload - flush caches (SMARTDRV /C for MS-DOS/PC DOS, NWCACHE /FLUSH=ON for DR-DOS, FreeDOS equivalents), give warning and wait for confirmation before unloading.
  • Bret Johnson's driver is stated to support hot-plugging/unplugging and load/unload commands, so maybe similar approach can be taken.
Torinde commented

The website focused on Win3.1 drivers has some Joystick items, not sure if USB related (although it mentions Bret Johnson's driver):

And there is a Test USB mouse driver along with some other interesting programs.

I think there is source code in that - potentially useful to improve the DOS implementation? But I may be mistaken.

crazii commented

Low speed hubs connected to high speed hubs - that's mentioned as one of the TODO items for DOSUSB, along with Isochronous transfer, thus it warrants at least testing/confirmation.

I just read the document of DOSUSB, the HID on high speed hub is still in TODO. HIDs usually are low speed devices (the one I tested with is low speed, bought in recent 2 years), so both the HID & low speed hub is the same thing: low speed devices on high speed hub (at least for EHCI to use high speed hub).
I've done that and tested the HID mouse, it's working, so it's very likely that low speed hubs are working too.

  • 👍1
Torinde commented

Are GPT disks supported currently? Bret Johnsons' drivers supports those.

crazii commented

NO, that probably needs remap GPT partition info into MBR before hand it to DOS, not done.