UK folks: scan’s got a combo usb2 & FireWire card, WITH an internal header AND comes with a 3.5” front panel for it!

What’s the price, I hear you clamour? Not even 50p!
https://www.scan.co.uk/products/scan-2x ... ternal-hub

Can’t vouch for anyone else’s compatibility , but it’s fine on my 440Bx board, 3dmark figures are nigh-identical and it happily hosted a usbode to install VB6. If it doesn’t work, at least it’s cheap!

Which chip is on it? If looks like the via USB controller in the photo but it's hard to tell.

From what I gathered from an AI conversation, there might actually be a good reason to skip USB 2.0 and go straight to USB 3.0 for older motherboards.

The reason for that is that the xHCI controller in USB 3.0 cards is more intelligent than the EHCI controller in USB 2.0 cards and effectively offloads the CPU and does a lot more of the processing independently from the CPU.

That is the case, regardless of the generation of the USB device that you plug into such a card (USB 1.0, USB 1.1, USB 2.0, USB 3.0). All such devices are handled by the xHCI controller. This is different from USB 2.0, where the card would have an EHCI controller just for USB 2.0 devices, plus a OHCI or UHCI controller for USB 1.x devices.

There are USB 3.0 cards for conventional PCI slots, although those are always built around a PCIe-to-PCI bridge chip, since no USB 3.0 (xHCI) controllers were ever designed with integrated conventional PCI interfaces.

Because of the improved way how xHCI works, it shouldn't degrade the performance of older host systems, at least not as much as USB 2.0 (EHCI) cards do, even if you'll never be able to utilize the maximum bandwidth of USB 3.0, due to the limitations of the conventional PCI bus.

Of course this is theoretical. I have purchased such a conventional PCI card with a USB 3.0 (xHCI) controller and intend to test it on an older system soon.

I don't think that any of these 3.0 cards would have Windows 9x drivers?

Kahenraz wrote on 2026-08-10, 15:07:

I don't think that any of these 3.0 cards would have Windows 9x drivers?

True. This would be a solution only when running something like Linux or NetBSD.

Unless somebody takes a stab at writing an xHCI driver for Windows 9x. I mean, @onethirdxcubed wrote an HDA driver for Windows 9x with help from an LLM, so this might not be all that crazier. 🙂

I can't really see why xHCI would behave any better than EHCI; at the register level there's not really that much difference between them. They both use the same memory structures (accessed via bus mastering) and the same hardware interrupts.

EHCI can support low/full speed devices without an OHCI/UHCI companion, if they have a built-in transaction translator - this was made mandatory for xHCI, simplifying both host controllers and hubs (EHCI hubs have to include transaction translators since the hosts may not...)

I don't think I'll get around to making a xHCI driver for Windows 98 any time soon; first I'm trying to figure out the "Crazy Mouse" problem when using legacy USB mouse emulation on the newest motherboard I can get Win98 Quick Install to work on. That system is a Lenovo Ideacentre with an i3 7100.

Being able to avoid using the UHCI controller would be nice to save resources though, since UHCI uses up one IRQ for every pair of USB ports and this can't always be shared with other devices when in legacy PIC mode.

An APIC and more modern ACPI driver for 9x would also be nice but is probably impossible because of the DOS underpinnings.

onethirdxcubed wrote on 2026-08-12, 00:55:

An APIC and more modern ACPI driver for 9x would also be nice but is probably impossible because of the DOS underpinnings.

I think people get confused by 9x's relationship with dos.
Dos is absolutely used as a boot loader. Think Grub.
Dos is absolutely supported in a VM. Think dosbox.
Dos drivers/interfaces are supported. Think extended BIOS function calls/interfaces.

9x is not running on top of dos despite the appearances. It is its own kernel with its own control over everything.
The big problem with modern ACPI is a lack of people with the ancient wisdom of writing VXDs

myne wrote on 2026-08-12, 01:03:

I think people get confused by 9x's relationship with dos. Dos is absolutely used as a boot loader. Think Grub. Dos is absolutel […]
Show full quote

onethirdxcubed wrote on 2026-08-12, 00:55:

An APIC and more modern ACPI driver for 9x would also be nice but is probably impossible because of the DOS underpinnings.

I think people get confused by 9x's relationship with dos.
Dos is absolutely used as a boot loader. Think Grub.
Dos is absolutely supported in a VM. Think dosbox.
Dos drivers/interfaces are supported. Think extended BIOS function calls/interfaces.

9x is not running on top of dos despite the appearances. It is its own kernel with its own control over everything.
The big problem with modern ACPI is a lack of people with the ancient wisdom of writing VXDs

DOS is absolutely always around in Win9x, it's the first thing that is loaded into the System VM and any system calls that the upper layers don't handle will eventually make their way down to good old 16 bit DOS. (File system calls sometimes make it all the way down and then back up for compatibility reasons.) Various parts of the VxD layer and Windows kernel manipulate the internal DOS data structures in the system VM, again for compatibility. Even Windows ME doesn't fully get rid of the DOS layer though it does block the ability to boot into bare DOS or load 16-bit drivers all the infrastructure is still there.

Because of this, there are always going to be real limits on 9x compatibility that are inherited from DOS. The relevant limitation here is that IRQs have to be reflected into real mode for the system VM and there's no existing way to remap a larger number of IRQs to the legacy 15. To support the APIC you would have to rewrite VPICD, the PCI bus, Plug & Play, and find every assumption in every existing VxD driver based on never having more than 15 IRQs as well as every place anything acknowledges an IRQ by writing to the PIC. There is no such thing as a Hardware Abstraction layer here so writes directly to hardware registers are scattered all over the place. Some even get trapped and modified by other layers of the system.
Maybe someone with a lot of dedication and a Claude Code Max subscription could get it working but I have better things to do.

(Here's a relevant article from Microsoft.)

In comparison, a xHCI controller driver could be written only to the WDM layer and wouldn't have to touch the entire rest of the OS.

I was responding to the ACPI part.
Power management shouldn't be impossible.

I suppose it's neither of our faults the two acronyms are so similar.