USB driver stack for DOS
USBDDOS was originally named RWDDOS before released to public, which is only a driver for RetroWave OPL3, and later more drviers added (mouse, keyboard, disk) and renamed to USBDDOS.
USBDDOS is tested working on following PCs/VMs:
There might be bugs for other PCs, test & feedback is appreiated.
USBDDOS uses DPMI to perform PCI bus master DMA (MMIO), and also save conventional memory for other DOS programs, it uses little conventional memory (USBDDOS uses ~12K, USBDDOSP uses almost 0).
The Borland++3.1/Open Watcom build (USBDDOS.EXE) can run without a DPMI host,
it has a builtin 16 bit protected mode functions which will enter protected mode directly or with a EMM manager.
~~It's not compatible with many games.
To play games with a USB mouse, USBDDOSP.EXE is recommended, which also need a DIMI host (i.e. HDPMI.exe).~~ Latest tests with 1.0fix2 shows that USBDDOS is more stable than USBDDOSP.
Like Bret Johnson's driver, USBDDOSP/USBDDOS need CuteMouse to work for USB mouse.
USBDDOSP doesn't need HDPMI32i unless you want Retrowave support, normal HDPMI32/CWSDPMI is recommended, unless you want it cope with SBEMU.
If you get problems with the mouse/keyboard driver, make sure those settings in your BIOS settings:
If you're using USB boot disk to boot the system, then /disk parameter is mandatory, because USBDDOS will take over from BIOS and make the BIOS's USB disk emulation unavailable, so the disk support need to be taken over too, otherwise the system drive will not function.
Do not use LH/LOADHIGH for USBDDOS - A DPMI (or a DOS Extender) program is executed above 1M, so no need to do that. Actually if LH is used, then after TSR the PSP segment will resident in high memory with its' real mode data/code freed, which may generate fragmentations. A DPMI TSR also doesn't need to use assembly to strictly control/optimize the memory layout for TSR, as a common real mode program does.
| The build scripts support multiple hosts: Linux, Windows(WSL/MinGW), DOS/FreeDOS. Three set of toolchians are supported: DJGPP, Borland C++ 3.1, Open Watcom v2. Basically the Borland C++3.1 built executable has the same features as the Open Watcom build. Here's a quick comparison of different toolchains and its generated executables: |
DJGPP | Borland C++3.1 | Open Watcom | |
|---|---|---|---|---|
| Linux Host | Yes | No | Yes | |
| Windows Host | Yes (WSL/MinGW) | No | Yes | |
| DOS Host | Yes | Yes | Yes | |
| Makefile | Makefile | Makefile.BC | Makefile.WC | |
| Debug Build | DEBUG=1 | -DDEBUG |DEBUG=1 |
|||
| Output Name | usbddosp.exe | usbddos.exe | usbddos.exe | |
| Executable | ||||
| DPMI Host Required | Yes | No | No | |
| Instruction Set | 32-bit | 16-bit | 16-bit | |
| Conventional Mem Usage | 0K[1] | 12K[2] | 12K[2] |
USBDDOSP itself uses almost 0K (around 1K), but it depends on the DPMI host used, for HPDMI it is actually around 1K, and for CWSDPMI, the total usage is about 200K, most of them are used by CWSDPMI itself, after TSR.
USBDDOS uses 4K memory if in real mode (without VCPI/EMM), 12K if in Virtual 8086 mode.
. /djgpp/setenv or source /djgpp/setenv make For DOS host, download from here: https://www.delorie.com/djgpp/ and set the envs: set PATH=%PATH%;C:\DJGPP\BIN, set DJGPP=C:\DJGPP\DJGPP.ENV
The Makefile will try to auto-detect DOS host, but may fail on FreeDOS, use make DOS=1 to force DOS build.
The makefile uses default BC path: C:\BORLANDC for includes and libs.
set PATH=%PATH%;C:\BORLANDC\BIN make -f Makefile.BCset PATH=%PATH%;C:\BC31\BIN and make -f Makefile.BC -DBCDIR=C:\BC31. /watcom/owsetenv.sh or source /watcom/owsetenv.sh wmake -f Makefile.WCDOS setup: set PATH=%PATH%;C:\OW2\BINW, set WATCOM=C:\OW2,
set INCLUDE=C:\OW2\H
Add DEBUG=1 on make commandline, i.e.
make DEBUG=1 for DJGPP,
wmake -f Makefile.WC DEBUG=1 for Open Watcom,
the built executable will have its logs/assertion enabled.
Use -DDEBUG for Borland C++'s make file.
The following drivers are added/planned:
USBDDOSP /hid to enableUSBDDOSP /disk to enableUSBDDOSP /RW to enable