Skip to content

m3 + h21: USB 2.0 on the Mac mini G4

Choose a tag to compare

View all tags
@UnexpectedBomb UnexpectedBomb released this 06 Aug 23:09
· 11 commits to main since this release
m3
c6b1cb5

⚠️ 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.

Assets 5
Loading