Good job!

@crazii recently returned to the forum again, so he might find this interesting.

I actually happen to have a Sandy Bridge 2011 Mac Mini lying around somewhere, but I don't know when I will have time to test this.

Anyone know a good way to scan and see what USB controller is in a DOS only system?

I have this little AASTRA system (formally a VOIP PBX) which is enough PC like that I was able to get DOS to boot on it: Re: Using XT-IDE on 386 with Compact Flash larger than 512MB - My tests.

But it doesn't take cards and has virtually no I/O other that PS2 Kbd/Mouse, Network and USB ports.
It's (not quite PC) BIOS recognized USB floppies and mass-storage but not much else.

I'd like to be able to test/set/reset some input bits - possibly connect a USB parallel port or serial ... but not knowing what it actually inside the box, I don't know where to start.

DaveDDS wrote on 2026-05-13, 20:50:

Anyone know a good way to scan and see what USB controller is in a DOS only system? […]
Show full quote

Anyone know a good way to scan and see what USB controller is in a DOS only system?

I have this little AASTRA system (formally a VOIP PBX) which is enough PC like that I was able to get DOS to boot on it: Re: Using XT-IDE on 386 with Compact Flash larger than 512MB - My tests.

But it doesn't take cards and has virtually no I/O other that PS2 Kbd/Mouse, Network and USB ports.
It's (not quite PC) BIOS recognized USB floppies and mass-storage but not much else.

I'd like to be able to test/set/reset some input bits - possibly connect a USB parallel port or serial ... but not knowing what it actually inside the box, I don't know where to start.

Fastest first step: USBHOSTS.COM from Bret Johnson's USBDOS suite (https://bretjohnson.us/) — it scans PCI specifically for USB host controllers and prints type (UHCI/OHCI/EHCI/xHCI), vendor/device IDs, IRQ, and I/O or memory-mapped base. One command, you'll know.

For a full PCI inventory (NIC, video, etc.) the usual suspects:

• PCI.EXE "Merlin's PCI Hardware Sniffer" by Craig Hart. Original site is dead; mirrored at https://www.vetusware.com/manufacturer/Craig% … rt/?author=7605 and https://www.bttr-software.de/freesoft/system.htm. Grab Ray Hinchliffe's updated PCIDEVS.TXT from http://rh-software.com/ — that database has ~3x the entries Craig's last build shipped with.
• ListPCI (Mercury Thirteen, GPLv2): https://www.mercurycoding.com/downloads.html#DOS
• HWiNFO for DOS (Mumak, resurrected): https://www.hwinfo.com/download/ — thread at HWiNFO for DOS resurrected !

If you want to identify USB controllers by hand from any PCI dump: class 0C, subclass 03, prog-IF tells you which — 00=UHCI, 10=OHCI, 20=EHCI, 30=xHCI.

Heads-up: since the Aastra originally ran XP, you've probably got EHCI or xHCI with no UHCI/OHCI companion (Intel moved that direction at the P55 generation). Bret's driver is UHCI-only and won't bind to those. The realistic alternatives:

• DOSUSB (Georg Potthast) — UHCI/OHCI/EHCI + partial xHCI, demo halts after 20 min (fine for bring-up), includes LPT1USB.SYS and a USB serial driver: https://www.georgpotthast.de/usb/

Thanks guys! Please also check my other recent post. [ALPHA - testers wanted] Rescue-D2 - single-floppy GUI rescue disk for 386+, *4 MB RAM* (FreeDOS base)

The updated driver hasn't been folded into that yet. Pending hardware testing.

Very cool!
The OHCI was only tested on my NEC versa s260 laptop, and a NEC µPD PCI adapter on a i820 mobo. Thank you for debug it on more machines.

This was the first time I wrote any driver for any real HW/device, and with the massive details in the usb specs, although I was as careful as I can, some could be missing or misunderstood, besides bugs in the code.
It was a difficult project requiring more pcs for debug & test, and far from being practically usable.

Currently the usb-disk is emulated in the DOS level (DOS driver list) not the BIOS level, so the partitions in the usb disk cannot be changed by fdisk (disk not recognized), hope it does have problem for your rescue disk. I guess a rescue disk doesn't need that self-partition.

Are you interested in creating a PR? Sorry I was busy during the past 2 years and failed to note any changes related on the projects on github. Thank God who blesses with a good timing. 😁

I checked github just now and saw your issue. Thank you again for the PR.
There is another PR that's CI related, I believe there isn't many conflict.

i can test on the following hardware:

- via kt133a system with uhci 1.1 controller
- intel 440bx laptop with uhci 1.1 controller
- nec pci card with ehci/ohci 2.0 controller
- renesas pci card with xhci 3.2 controller
- via cardbus card with ehci/ohci 2.0 controller

my primary interest is getting a usb 2.0 hub (keyboard) working under dos with an ohci controller. the bret johnson driver seems to work flawlessly in this scenario, but is limited to uhci. compiling the current usbddos code on github results in an instant lockup when connecting thru a hub.

stanwebber wrote on 2026-05-14, 10:41:

i can test on the following hardware: […]
Show full quote

i can test on the following hardware:

- via kt133a system with uhci 1.1 controller
- intel 440bx laptop with uhci 1.1 controller
- nec pci card with ehci/ohci 2.0 controller
- renesas pci card with xhci 3.2 controller
- via cardbus card with ehci/ohci 2.0 controller

my primary interest is getting a usb 2.0 hub (keyboard) working under dos with an ohci controller. the bret johnson driver seems to work flawlessly in this scenario, but is limited to uhci. compiling the current usbddos code on github results in an instant lockup when connecting thru a hub.

This is for FreeDOS. If you're using MS-DOS, you may want to compile. https://github.com/netrunner01/USBDDOS/releas … .1-binaries.zip

so far i'm not having any luck with your v1.0.0 alpha build. on a kt133a system with a 4-port usb 2.0 hub plughed into an nec µPD720101 pci card, usbddos /hid is locking up while detecting (or immediately after) the devices on the hub. i have a usb microphone, bluetooth dongle, trackball (detected as keyboard + mouse) and a keyboard/trackpad combo plugged into the hub. it detects both trackball devices and both keyboard/trackpad combo devices before freezing. there are no issues with the functioning of any of the hub devices under win98se or linux q4os.

i also compiled a usbddos debug build from commit afb2b84 of https://github.com/netrunner01/USBDDOS.git, but i'm not sure where to start.

fsck100 wrote on 2026-05-14, 17:04:

This is for FreeDOS. If you're using MS-DOS, you may want to compile. https://github.com/netrunner01/USBDDOS/releas … .1-binaries.zip

Is there any special handling for FreeDOS? is it possible to include the special code in the MS-DOS build and do switch it in runtime?

crazii wrote on 2026-05-15, 08:49:

fsck100 wrote on 2026-05-14, 17:04:

This is for FreeDOS. If you're using MS-DOS, you may want to compile. https://github.com/netrunner01/USBDDOS/releas … .1-binaries.zip

Is there any special handling for FreeDOS? is it possible to include the special code in the MS-DOS build and do switch it in runtime?

In theory, it shouldn't matter. As to your other question, I wish I knew. I am a noob on all of this.

New release with additional patches.

https://github.com/netrunner01/USBDDOS/releas … 1.0.0-alpha.2.1

https://github.com/netrunner01/USBDDOS/releas … .2.1-bundle.zip

Please send bug reports and success stories with hardware details to: bugs@tekguru.us .

Also opening an issue is greatly appreciated:
https://github.com/Netrunner01/USBDDOS/issues

New interim release. Multiple bugs fixed.

https://github.com/netrunner01/USBDDOS/blob/m … 0.0-alpha.3.zip

## [1.0.0-alpha.3] — 2026-05-26

First fork-side release with substantive code changes since alpha.1 (the
intervening alpha.2 was a housekeeping refresh of build provenance after
upstream merged the alpha.1 patch series). Covers three buckets:

* **Defensive hardening absorbed from the alpha.2.1 release branch**:
graceful-skip handling for unsupported device classes during
enumeration (Gap I), and DPMI page-boundary correctness for OHCI DMA
structures under HDPMI32 (Gap H). Both shipped as `v1.0.0-alpha.2.1`
on a dedicated release branch in May 2026 with limited distribution;
this release brings them onto master and into the standard release
bundle.
* **EHCI bug fixes uncovered by real-hardware diagnostic work**:
full-speed/low-speed `bInterval` was treated as a log-scale exponent
(Gap H5) causing HID devices behind a USB 2.0 hub to be polled at
128 ms when they requested 10 ms, manifesting as 1-2 second per
keystroke on the affected silicon. Independent of that, the HID class
driver dispatched asynchronous control transfers from interrupt
context (Gap-K), violating EHCI_ControlTransfer's "no pending
transfers" precondition and aborting under sustained typing; the
Workaround-A patch in this release removes the trigger surface
entirely.
* **Packaging hygiene for DOS environments without working LFN**:
release bundles now use a directory-based variant taxonomy
(`RELEASE\USBDDOS.EXE`, `DEBUG\USBDDOS.EXE`) instead of suffixed
filenames (`USBDDOS-DEBUG-GAPJK.EXE`), so every file and directory
fits the 8.3 short-filename format cleanly. A new `make release`
target orchestrates the full build-and-package flow.

**Alpha designation**: real-hardware verification has been received for
the Gap-J/Gap-K investigation that motivated H5 and Workaround A
(tester reports `debugd2.TXT` and `debuge2_1_.TXT`, May 2026, on a
USB 2.0 hub topology with a Logitech HID composite). Promotion to beta
remains contingent on independent verification of the H5+Workaround-A
behavior across additional hardware.

### Added

* **`scripts/release.sh`**: orchestrator for `make release`. Builds
DJGPP release+DEBUG and Watcom release+DEBUG, extracts the latest
changelog section into `RELNOTES.TXT`, stages the bundle directory
layout, validates every file and directory for 8.3 SFN compliance,
and produces `dist/usbddos-vX.Y.Z.zip`. Refuses to run if the
requested VERSION doesn't match `CHANGELOG.md`'s latest `## [...]`
header, preventing accidental release of an undocumented version.
* **`scripts/bundle-templates/`**: in-bundle `README.TXT` (user-facing
quick-start and switch reference) and `COM1LOG.TXT` (COM1 capture
setup for DEBUG builds).
* **`make release` target** in `Make/Makefile`: invokes
`scripts/release.sh`.

### Fixed

* **Gap I — graceful skip hardening** (PR #31, originally on the
`release/v1.0.0-alpha.2.1` branch): malformed or unsupported
interface descriptors during enumeration no longer abort the whole
device. Adds Interface Association Descriptor (IAD) recognition,
`bNumInterfaces` cap, and zero-length descriptor defense. Surfaced
by tester report of audio-class composite devices freezing the host
during HID-only enumeration.
* **Gap H — DPMI page-boundary correctness** (PR #32, originally on
the `release/v1.0.0-alpha.2.1` branch): `DPMI_DMAMallocNCPB` in
`dpmi_dj2.c` was checking C-pointer-space page boundaries instead of
linear-address-space boundaries. Under HDPMI32 with a non-page-aligned
DS base, this gave OHCI DMA structures that straddled physical page
boundaries, corrupting transfers. Watcom build was unaffected
(`dpmi_bc.cpp` was already using linear addresses correctly).
* **Gap H5 — full-speed/low-speed `bInterval` log-scale conversion**:
EHCI's `EHCI_CreateEndpoint` treated the device-reported `bInterval`
(which is a linear millisecond period per USB 2.0 § 9.6.6 for
FS/LS endpoints) as if it were a log-scale exponent — the same way
the high-speed branch correctly does for high-speed endpoints. A
typical HID keyboard with `bInterval = 10` (10 ms requested) was
placed on slot 7 (128 ms polling) — a 12.8× under-sampling that
manifested as 1-2 seconds per keystroke on the affected setup. The
fix computes `floor(log2(bInterval)) + 1` and uses that as the
periodic-schedule slot index, putting `bInterval = 10` on slot 3
(8 ms polling — closest power-of-2 not exceeding 10 ms). High-speed
handling is unchanged.
* **Gap-K Workaround A — remove async control transfer from HID
interrupt callback**: `USB_HID_InputKeyboard` was dispatching
asynchronous `SET_IDLE` requests via `USB_SendRequest` from
interrupt context to toggle the device's idle state on key
transitions. This violated the explicit assumption in
`EHCI_ControlTransfer` (documented in a source-code comment next
to the relevant assertion) that "control transfers are synced
(from USBD), and there's no pending transfers". Under sustained
typing, a second async control transfer could arrive before the
first's qTD chain had fully cleaned up, tripping the assertion and
aborting USBDDOS. The H5 fix mitigates this in practice by closing
the timing window (16× faster polling = much narrower overlap
window) but doesn't fix it architecturally. Workaround A programs
`SET_IDLE(MINIMAL = 4 ms)` once at install time via the existing
synchronous path and removes the toggle entirely. Bandwidth cost:
~1 KB/sec per HID device on USB 1.1, under 0.1% of the bus.
Residual exposure: `USB_HID_Keyboard_SetupLED` still dispatches an
async `SET_REPORT` for LED state on Caps/Num/Scroll Lock keypresses,
but at human-rate trigger probability is dramatically lower. Tracked
for future Workaround B or proper-fix in alpha.4 scope.

### Changed

* **Bundle layout** is now 8.3 SFN-compliant throughout. Previous
bundles shipped names like `USBDDOSP-DEBUG-GAPJK.EXE` (20-character
base) that depended on a working LFN driver to be visible at their
full name. The new layout keeps the canonical binary names
`USBDDOS.EXE` and `USBDDOSP.EXE` at every level and moves the variant
taxonomy into the directory hierarchy:
* `RELEASE\USBDDOS.EXE` / `RELEASE\USBDDOSP.EXE`
* `DEBUG\USBDDOS.EXE` / `DEBUG\USBDDOSP.EXE`
* **Text file names** in the bundle were also brought into 8.3
compliance: `RELEASE-NOTES.txt` → `RELNOTES.TXT`,
`COM1-LOGGING.txt` → `COM1LOG.TXT`, `CHANGELOG.md` → `CHANGES.TXT`
(the repo's `CHANGELOG.md` is unchanged; the script copies it as
`CHANGES.TXT` into the bundle). `COPYING` → `COPYING.TXT`.

### Not changed

* The build system itself. `Make/Makefile`, `Make/Makefile.WC`, and
`Make/Makefile.BC` already produced 8.3-compliant binary names
(`output/usbddos.exe` and `output/usbddosp.exe`); only the
packaging step was renaming them to introduce the LFN-dependent
variants. The build's compile-and-link commands are unchanged.
* Upstream-merged code. The fork's master remains synced to
`crazii/USBDDOS:master` (rebased after the H5 fix landed) with
the fork-side commits as a clean linear delta on top.

### Field-validation status (real-hardware reports)

* **Gap I**: tester confirmation on KT133A + NEC µPD720101 chipset
(May 2026, alpha.2.1 binary).
* **Gap H**: tester confirmation on Intel ICH-style southbridge + USB
2.0 hub topology (May 2026, alpha.2.1 binary).
* **Gap H5**: tester confirmation on Intel ICH + dual-OHCI/EHCI bridge
with USB 2.0 hub + Logitech HID composite. Pre-H5: 128 ms polling
measured (assertion abort under typing). Post-H5: 8 ms polling
measured (slot=3), typing speed restored, no abort.
* **Gap-K Workaround A**: assertion was captured firing in
`debugd2.TXT` (May 2026) and verified not firing in `debuge2_1_.TXT`
with H5 in place. Workaround A removes the trigger surface
entirely so the failure mode can no longer be reproduced by code
inspection; runtime reverification is included as the standard
alpha.3 acceptance criterion.

### Reference upstream commit

Master is rebased onto upstream `crazii/USBDDOS:master` as of the
fetch immediately preceding this release. The H5, Gap-K Workaround A,
and packaging commits are the fork-side delta on top of that
upstream tip. Run `git log --oneline upstream/master..HEAD` on the
fork to see the exact three commits.

### Note on the alpha.2.1 release branch

The `release/v1.0.0-alpha.2.1` branch and the `v1.0.0-alpha.2.1` tag
remain published as historical references — they contain the
PR #31 (Gap I) + PR #32 (Gap H) patches in their original packaging
(suffixed filenames pre-dating the SFN refactor). The functionally
equivalent fixes are now on master and ship in this alpha.3 bundle
under the new layout. Anyone tracking the fork via master will get
the alpha.3 contents naturally; the alpha.2.1 release is preserved for
reproducibility of anything previously distributed against that tag.