Three machines, app-less: Mini G4, MDD G4, B&W G3 (2026-08-15)

USB 2.0 for Mac OS 9, on three machines, with no helper app.

This is the largest release since the project began. Full details and install steps are in the README; highlights:

• App-less. Activation now lives in a small system extension. Drop the ROM and the extension in, reboot, done. Nothing to launch, nothing to quit by accident.
• Three machines, fully validated on real hardware: Mac mini G4 (on-board USB 2.0), Power Mac G4 MDD (PCI card), and new this release the Power Mac G3 Blue and White (PCI card, built on the RETAIL 9.2.2 ROM). The B&W pair plausibly serves other stock-9.2.2 towers with a PCI USB 2.0 card; reports welcome.
• A memory-safety fix for surprise removal, found and fixed before any affected ROM was ever published.
• Apple System Profiler no longer crashes on Devices and Volumes.
• Disk First Aid now shows honest drive information ("USB 2.0, drive 1 (v1.0)") instead of garbage text.
• Drives connected at boot mount at Hi-Speed. The old boot-unplugged ritual is gone.

Every machine needs exactly two files, a ROM and an extension. Take the pair for your machine, decode with StuffIt Expander 6.0 or newer (older Expanders corrupt the ROM; it will refuse to boot rather than run corrupted), and follow the README's install steps. You must boot from another volume (or CD) to swap the Mac OS ROM file.

Machine	ROM	Extension
Mac mini G4	USB2_Mini_G4_ROM.hqx	Mini_G4_EHCI_Ext.bin
Power Mac G4 MDD + PCI card	USB2_MDD_G4_ROM.hqx	MDD_G4_EHCI_Ext.bin
Power Mac G3 B&W + PCI card (retail 9.2.2)	USB2_BW_G3_ROM.hqx	BW_G3_EHCI_Ext.bin

MD5 checksums:

0f9f53636585499c156d1ac903315aad  USB2_Mini_G4_ROM.hqx
2eb05b9d2583622ed3e56620cba06f71  USB2_MDD_G4_ROM.hqx
5509afe84cd0b19cdc435624667f4f3c  USB2_BW_G3_ROM.hqx
ff84d8b7cb629f2ea8a9f0bfb71b6b40  Mini_G4_EHCI_Ext.bin
f345db22764507fb3c0e1e607163d2bf  MDD_G4_EHCI_Ext.bin
ee4863df8510d444f20804b72171d2e6  BW_G3_EHCI_Ext.bin

The mini ROM also carries the VBL display fix base (see the README's mini section). Users of any earlier release should re-flash: this supersedes everything before it.

ROMs as BinHex (.hqx): SysEnabler restored, both boot-verified

Both ROMs are back, and this time each one was booted on real hardware before being published.

The ROMs originally attached here did not start up. They carried a vers resource so Get Info would name the build, and that resource broke startup: a Mac OS ROM's resource fork is the System Enabler's resource fork, so a vers (1) there describes the enabler rather than our build, and the System left parts of itself uninstalled. The full explanation is kept below.

That resource is gone, the build tool now refuses to produce a ROM containing one, and both files below have started their respective machines.

Files

your machine	ROM	helper
Power Mac G4 MDD + PCI USB 2.0 card	USB2_PathA_MacOSROM_h21r.hqx	USB2_Activate_n4g.bin
Mac mini G4 (on-board USB 2.0)	USB2_MiniROM_VBLfix_m3r.hqx	USB2_Activate_n4g.bin

a68bebbb60f33b1f2d5c900d32187ae1  USB2_PathA_MacOSROM_h21r.hqx
ce926e4b2e33ef899928a6b07d3a308d  USB2_MiniROM_VBLfix_m3r.hqx
753912b5fd731bea015dfbe954b861f4  USB2_Activate_n4g.bin

The drivers inside are byte-for-byte the ones already validated as h21 and m3. Only the packaging changed: the ROM's resource fork is preserved, so the 185 KB SysEnabler that earlier .bin releases silently dropped is present.

Installing

Decode the .hqx with StuffIt Expander on the Mac, which preserves the resource fork. Do not route it through a tool or file server that drops forks.

Then boot from a CD or another volume to swap Mac OS ROM, since you cannot replace the one you are booted from. Keep your original.

Mac mini owners, read this

The mini ROM also carries an experimental fix for the mini's OS 9 startup freeze, and that fix does not work reliably. This is not a new caveat, and it was demonstrated again while verifying this very release: the ROM booted correctly and then hit a frozen cursor at startup, which the app fixed.

Install the VBLFix app from the VBL fix project in Startup Items, and treat it as required rather than optional. With it in place, a boot the ROM misses becomes a few seconds of frozen cursor that clears itself.

If you would rather not have the experimental display patch at all, run scripts/build-rom-hqx.py against your own mini ROM and you get only the USB 2.0 driver.

Identifying which ROM you have

Get Info will not tell you, and that is deliberate: the version resource that would have shown it is exactly what stopped machines booting. For now the build name lives in the filename only. Surfacing it safely is an open problem.

Building your own

python3 scripts/build-rom-hqx.py "Mac OS ROM" mybuild "Mac OS ROM (USB2).hqx"

It injects the driver, emits BinHex so your ROM's resource fork survives, refuses to write a ROM whose SysEnabler came out empty, and refuses to write one carrying a vers (1). Your input ROM needs its resource fork intact; unar on the desktop, or StuffIt/BinHex on the Mac, will preserve it.

---

The withdrawal notice and the original notes follow, kept as a record.

⚠️ The ROMs in this release have been WITHDRAWN. They did not boot.

If you flashed USB2_PathA_MacOSROM_h21r.hqx or USB2_MiniROM_VBLfix_m3r.hqx and your machine will not start up, that is our fault and it is fixable. See "Recovering" below.

Both ROM files have been removed from this release. The helper app, USB2_Activate_n4g.bin, is unaffected and is still attached.

What went wrong

These ROMs carried a vers resource so that Get Info would tell you which build you were running. That resource broke startup.

A Mac OS ROM's resource fork is the System Enabler's resource fork, and a vers (1) resource is a file's own version. Adding one told the System that the enabler was version 1.0.0, which is a statement about the enabler rather than about our build. A mis-described enabler leaves parts of the system uninstalled.

The symptom is a dialog reading "No File System Access modules could be found in your System folder. Therefore, the Foreign File Access software was not installed.", then the Starting Up screen, then a grey screen and a hang.

Nothing else about the ROM was wrong. It was verified resource by resource against a stock ROM with nothing damaged, lost or altered. The fault was entirely that one added resource, and an otherwise identical ROM built without it boots normally.

This was shipped without being booted first, which is the real mistake. The fix is already made and verified at the desk, but it will not be published until it has actually started a machine.

Recovering, if you flashed one

You cannot swap Mac OS ROM while booted from the System Folder that contains it, so:

1. Boot from an OS 9 CD, or from another volume with a System Folder.
2. Put your original Mac OS ROM back into the System Folder (the one you were told to keep).
3. Restart.

If you no longer have your original, the ROM in the m3 release will boot. It has the older packaging defect described in that release's notes (a missing SysEnabler), but it starts up normally and it is a safe place to sit until the corrected ROMs are published.

What happens next

Corrected ROMs are built and verified locally: same validated drivers, resource fork intact, and no version resource. They will be attached here once they have been boot-tested on real hardware.

Watch this release, or build your own from source in the meantime:

python3 scripts/build-rom-hqx.py "Mac OS ROM" mybuild "Mac OS ROM (USB2).hqx"

That script now refuses to produce a ROM containing the resource that caused this.

---

Original release notes follow.

Corrective release. If you flashed a ROM from n13 or m3, please re-flash from here.

What was wrong

Every Mac OS ROM released before this one was missing a 185 KB component called SysEnabler, and that was our packaging's fault rather than anything you did.

Those ROMs shipped as MacBinary .bin. The wrapper we used built its own small resource fork, which replaced the ROM's real one, and SysEnabler lives in that fork. It affects USB2_PathA_MacOSROM_n13.bin, USB2_PathA_MacOSROM_h21.bin and USB2_MiniROM_VBLfix_m3.bin.

They all boot, which is why this went unnoticed for months.

The symptom, if you have been seeing it

An intermittent frozen mouse cursor during startup, and the machine responding to keyboard and mouse only every few seconds. On our own MDD that hit roughly half of all boots. With SysEnabler restored, the same machine booted six times out of six with no freezing and no stutter.

Six clean boots is encouraging, not proof. If you were living with this and blaming your hardware, we would genuinely like to know whether this changes it.

What is different

Packaging only. ROMs are now BinHex .hqx, which carries both forks intact. The drivers are byte-for-byte the same ones already validated: the MDD ROM carries h21's driver and the mini ROM carries m3's.

Each ROM also now stamps its build name, so Get Info tells you which ROM is actually installed.

Files

your machine	ROM	helper
Power Mac G4 MDD + PCI USB 2.0 card	USB2_PathA_MacOSROM_h21r.hqx	USB2_Activate_n4g.bin
Mac mini G4 (on-board USB 2.0)	USB2_MiniROM_VBLfix_m3r.hqx	USB2_Activate_n4g.bin
anything else	build your own, see below	USB2_Activate_n4g.bin

f207fb26bae5169fd0a5a511b0445318  USB2_PathA_MacOSROM_h21r.hqx
ec29b7bf6dc323b74f5bd5cca93f595d  USB2_MiniROM_VBLfix_m3r.hqx
753912b5fd731bea015dfbe954b861f4  USB2_Activate_n4g.bin

The helper is unchanged, so if you already have n4g in Startup Items you do not need to replace it.

Installing

Decode the .hqx with StuffIt Expander on the Mac. That preserves the resource fork, which is the entire point of this release. Do not route it through a tool or a file server that drops forks, or you will recreate the original problem.

Then, as before: boot from a CD or another volume to swap Mac OS ROM, because you cannot replace the one you are booted from. Keep your original.

Building your own

If you patch your own ROM, use the new script rather than the bare injector:

python3 scripts/build-rom-hqx.py "Mac OS ROM" mybuild "Mac OS ROM (USB2).hqx"

It injects the driver, stamps the build name for Get Info, emits BinHex, and refuses to write a ROM whose SysEnabler came out empty. Your input ROM needs its resource fork intact; unar on the desktop, or StuffIt/BinHex on the Mac, will preserve it.

Mac mini owners

Unchanged from the previous release, and still important: this ROM also carries an experimental fix for the mini's OS 9 startup freeze which has been observed not to prevent that freeze reliably. Run the VBLFix app from the VBL fix project in Startup Items as well, and treat that as required. Details are in the README.

m3 + h21: USB 2.0 on the Mac mini G4

⚠️ SUPERSEDED: this ROM is missing SysEnabler

The Mac OS ROM here was packaged as MacBinary, and our wrapper replaced the ROM's real resource
fork, dropping a 185 KB component called SysEnabler. It boots, but it appears to cause an
intermittent frozen cursor at startup and input responding only every few seconds.

Please re-flash from the current release.
The driver is unchanged; only the packaging is fixed, and both ROMs there have been booted on real
hardware before publishing. Our packaging, not your machine.

USB 2.0 now works on a second kind of machine: the Mac mini G4, on its built-in ports.

Until now this stack ran on one machine, a Power Mac G4 MDD with a PCI USB 2.0 card. The Mac mini G4 has now been validated on its on-board EHCI controller, which Mac OS 9 has only ever driven at USB 1.1. A drive mounts at Hi-Speed in a rear port, copies files both directions, ejects to the Trash, and mounts again behind an Apple Cinema Display's built-in hub. The keyboard and mouse keep working throughout, on the same controller.

This release also promotes the h21 MDD ROM, which supersedes n13: up to four drives at once, and drives behind an external Hi-Speed hub.

Which files do I need?

The ROM and the helper are a matched pair. Install them together. The helper reaches into a structure inside the driver, so mixing versions across releases will not work. In particular, do not pair these ROMs with the older USB2_Activate_n4f.bin from the n13 release.

Your machine	ROM	Helper
Power Mac G4 MDD (boots OS 9 on its stock ROM) + PCI USB 2.0 card	USB2_PathA_MacOSROM_h21.bin	USB2_Activate_n4g.bin
Mac mini G4 (on-board USB 2.0)	USB2_MiniROM_VBLfix_m3.bin	USB2_Activate_n4g.bin
Anything else	build your own with rom/usb_rom_inject.py	USB2_Activate_n4g.bin

A complete Mac OS ROM is machine-specific, so neither prebuilt ROM suits a model it was not built for. The injector in the repo is the portability mechanism: it appends a parcel to your own ROM rather than replacing it, so it composes with a ROM that has already been patched to make OS 9 boot.

You must boot from a CD or another volume to swap Mac OS ROM. You cannot replace the one you are booted from. Keep your original.

Checksums (md5)

09107cdcac28d28dbc6e2efcdf52cbb3  USB2_PathA_MacOSROM_h21.bin
271eb45b9165f1caf3c93d68120857cb  USB2_MiniROM_VBLfix_m3.bin
753912b5fd731bea015dfbe954b861f4  USB2_Activate_n4g.bin

Mac mini owners, please read this before you flash

The mini ROM is built on the MacOS9Lives mini ROM, so it keeps the patches that make a mini boot OS 9 at all. That base also carries a second, unrelated patch: an attempted fix for the mini's OS 9 startup freeze, where the mouse cursor freezes during boot at a scaled screen resolution. That is a display-driver bug and has nothing to do with USB. It belongs to a separate project.

You are entitled to know how well that part works, because it is bundled into the ROM you are about to install:

• The ROM-integrated VBL fix is experimental and does NOT reliably fix the freeze. In testing after it was first published, boots still froze with it installed, roughly 2 frozen-cursor boots in about 25. Unpatched, the freeze rate is around 5% of boots, higher on warm restarts. Those figures are statistically indistinguishable, so there is currently no evidence that the ROM part of the VBL fix helps at all. It rides along here as an experiment, not as a working fix.
• The fix that does work is the app, VBLFix, from that project's releases. It is proven, including independent confirmation from other people on other minis.
• So install VBLFix in your Startup Items as well, and treat that as required rather than optional. With the app in place, a boot the ROM misses becomes a brief freeze that clears itself a few seconds later instead of a frozen machine.

The leading explanation for the difference is timing: the ROM re-arms the interrupt inside the display driver's mode switch, deep in the fragile early-boot window where the re-enable often does not latch, while the app fires later, after everything has settled. That is a well-supported hypothesis, not a proven mechanism.

None of this affects USB 2.0. The USB half of this ROM is what was validated. If you would rather not take the experimental display patch, run the injector against your own mini ROM and you will get the USB 2.0 driver on your own base.

Honest status

• The PCI card path has months of use behind it and is the reliable one.
• The Mac mini path rests on one validation session, one machine, one drive. It is newer and less proven. Please report what happens on yours.
• One thing seen on the mini and not yet explained: on an earlier build the machine paused for about ten seconds around a drive being inserted, then carried on. The driver now rides that out instead of giving up on the drive, but the pause itself is not understood, and the on-board controller's shared interrupt line is the leading suspect.
• A drive attached at boot still mounts at 1.1. Boot with it unplugged, then insert it.
• Keyboards and mice behind a Hi-Speed hub still do not work. Drives do.
• Four drives is the ceiling, and mounting a drive during a copy still fails.

Keep backups. This is new low-level code touching your disks.

n13: prebuilt MDD ROM, hot-plug, OS-performed mount

⚠️ SUPERSEDED: this ROM is missing SysEnabler

The Mac OS ROM here was packaged as MacBinary, and our wrapper replaced the ROM's real resource
fork, dropping a 185 KB component called SysEnabler. It boots, but it appears to cause an
intermittent frozen cursor at startup and input responding only every few seconds.

Please re-flash from the current release.
The driver is unchanged; only the packaging is fixed, and both ROMs there have been booted on real
hardware before publishing. Our packaging, not your machine.

First release with a prebuilt ROM, so a Power Mac G4 MDD needs no toolchain at all.

Install these two together

They are a matched pair. The helper reaches into the driver's service structure, so a mismatched pair
will not work.

file	md5
USB2_PathA_MacOSROM_n13.bin	45072075790082cad40351f6c9becbe8
USB2_Activate_n4f.bin	09711b572b24cfe274de3dffc54f3162

Both are MacBinary. Decode them on the Mac so the resource forks survive. Get Info on the decoded ROM
should show version n13.

Back up your existing Mac OS ROM first, and make sure you can boot from something else. This is a
ROM patch. Fully reversible, but only if you kept the original.

1. Boot from a CD or another volume. You cannot replace the Mac OS ROM you are currently booted from.
2. Put the decoded ROM into the System Folder in place of Mac OS ROM.
3. Put USB2_Activate_n4f.bin, decoded, into System Folder > Startup Items.
4. Boot normally with no USB drive attached, then plug one in. It mounts at Hi-Speed.

Which machines this ROM suits

Power Mac G4 MDD that boots OS 9 on its own stock ROM. The ROM here is built from an MDD's own
Mac OS ROM, so it carries that machine's drivers and not another model's. It has no ATY,RockHopper2,
for example, so it is not suitable for a Mac mini G4.

⚠ Do not use this file if your machine only boots OS 9 because of a community ROM patch. That covers
the unsupported-machine setups: an FW800 MDD, a Mac mini G4, an aluminium PowerBook and similar. Your
Mac OS ROM has already been modified to make OS 9 boot at all, and this file does not contain that work,
so installing it would take away the thing making your machine boot. Use the injector on your own patched
ROM instead: it appends a parcel rather than replacing anything, so it composes with the boot patch. Apply
the boot patch first, then this.

Any other NewWorld Mac, so a B&W G3 or later, should patch its own ROM instead, using
rom/usb_rom_inject.py in the repo. See the README. That path is machine-agnostic, which is the reason
it exists.

OldWorld Macs are out of scope. A beige G3, 8600 or 9600 has no Mac OS ROM file for this to patch,
so the injector stops with "no Parcelfile found in the dump". That is not the same question as whether
the machine has PCI slots: a beige G3 has slots and is still out of scope, while a Mac mini G4 has none
and is in scope.

What works

• High-speed mount with no application involved in discovery. Mac OS 9 performs the mount itself.
• Reads about 20 MB/s, roughly 20x USB 1.1. Writes about 2 to 3 MB/s in the Finder.
• Hot-plug: insert, eject, unplug, re-insert, or swap in a different drive.
• Un-ejected removal unmounts cleanly rather than leaving a damaged disk.
• Restart with the driver active is safe.

What does not work yet

• One drive at a time. A second drive inserted while one is mounted is ignored. Multi-device is in
  progress, and it will ship as a new ROM and helper pair.
• External hubs are not driven, including the hub built into an Apple Cinema Display.
• A drive attached at boot mounts at 1.1, not 2.0. Plug it in after booting.
• Only tested on a G4 MDD with a NEC based PCI card. Other EHCI chipsets should bind, since the driver
  matches on the EHCI class code and reads the card geometry at runtime, but none have been tried.
• On board USB 2.0, for example a Mac mini G4, is experimental and can hang.

Treat this as a beta. Do not put anything irreplaceable on it yet.

Expected log output

EHCIUIM_init.log will contain many lines like !! v47 STALL - self-probe transfer not completing:.
These are not errors. That diagnostic fires whenever a transfer is in flight, which during a copy is
almost constant. A clean soak run here logged 174 of them alongside 18,223 completed transfers with zero
errors. If something is genuinely wrong, gDownErr or gDownTimeouts will be above zero in the same
dump and gDownDone will stop advancing.

The driver appends to that log across loads, so delete it before a test run and read from the last banner.

Reporting problems

Most useful of all is a report from a card that is not the one this was developed on. Please say which
Mac, which card and chipset, and which OS 9 version, and attach EHCIUIM_init.log from the boot where it
went wrong.