Glonce

Classic Mac OS port to ArtX-chipset PowerPC machines reaches the desktop

miscThe Glonce editorsHacker News🔥63Glonce rating63Impact35Novelty55Relevance65Surprise60Players15Credibility85

Rairii, writing a guest post on virtuallyfun.com, reports a milestone in a personal project: classic Mac OS, ported to PowerPC systems built on what the author calls ArtX chipsets, has reached the desktop for the first time. The targets are the Nintendo GameCube, the Wii and eventually the Wii U. The author explains that the GameCube's Flipper chipset was designed by ArtX and was effectively finished when ATI acquired the company, and that the Wii's Vegas (and its later revision Bollywood) and the Wii U's Latte are effectively straight successors. The author says this is most likely the first time since the CHRP clone era that someone outside Apple has brought up classic Mac OS on a new system to the desktop, and adds that the project is still nowhere near ready for a public release.

The motivation: the author had already ported Windows NT to this hardware, and along the way acquired some PowerPC Mac laptops and ported NT to those too. That work introduced the author to classic Mac OS, and the author came to love its "jank", hacks upon hacks going back to the 1980s. The author also notes that the m68k part of the PowerPC-era ROM image (the TBXI) is called "SuperMario". The project started on 2025-06-22, when the author forked upstream OpenBIOS. The author states that no coding agent or LLM was used and that all coding, reversing and debugging was done by hand, because the projects are for fun and learning.

Booting starts with the "Trampoline", the bootloader of "New World" classic Mac OS, which runs on an Open Firmware environment, so OpenBIOS had to be ported. Goldfish64 had begun his own port of Mac OS X to the Wii and made an OpenBIOS port whose drivers the author could draw on, but the author did not use it directly, partly because it targeted only Wii and Wii U and the author wanted the GameCube too. To reuse existing code, in particular the display driver, the author changed an existing NT ARC firmware loader to load a big-endian ELF. For early disk access the author ported two EXI-bus drivers (EXI is Nintendo and Macronix's name for SPI): the SD Gecko, a pass-through adapter for a GameCube memory card slot that allows SD over SPI, and EXI-IDE, which matches the author's own inexact emulation in a Dolphin tree rather than real hardware. For first tests, the Mac OS ROM TBXI file was placed on a FAT filesystem as \ppc\bootinfo.txt for OpenBIOS to load. The earlier NT-port approach of running from disk images on FAT would cap images at 4GB, too small for later classic Mac OS versions, so the author wanted a different disk format.

The author applies as many patches as possible as close to run-time as possible, so that mostly untouched existing CD images could eventually be used. The first problems were address-space assumptions in the Trampoline. A buffer's physical address was computed as invalid, so it was patched to a guaranteed-valid address, along with the code that sets up the kernel's memory chunk list and page table entries. The Trampoline also expects physical addresses from 0x8000_0000 upward to be memory-mapped I/O (PCI-bus space on the machines it was written for), but on the Wii U that range is part of RAM, and there are holes between RAM areas, some partly filled by MMIO. The fix was to patch the MMIO mapping in the kernel memory chunk list to map physical 0x0100_0000 (partway through one RAM area) to virtual 0xE000_0000, with length 0x1000_0000. That covers all the MMIO plus the end of one RAM area and, on post-GameCube systems, the start of another. The author may change this later, because on the Wii U the range 0xD000_0000 to 0xEFFF_FFFF maps to the HDP part of the Radeon R7xx GPU. The mapping-initialisation function changed between Trampoline versions (16-bit page count earlier, 32-bit later), so the author detects the older one and hooks it. Older Trampolines also set up unconditional 1:1 mappings above 0x8000_0000, which are removed because they conflict.

More patches deal with hardware these machines lack: flags for the microcontroller found on all PowerPC Macs, bus-frequency recalculation using a specific hardware timer, and register writes for a little-endian PCI interrupt controller. The jump into the loaded kernel is hooked so later patches can be applied once everything is in memory. The device tree is also altered. The interrupt controller is faked as the recognised little-endian one, since at register level it is closest to the Flipper interrupt controller (on the Wii U it was changed somewhat to support the extra PowerPC cores). The frame buffer address is changed to the uncached virtual address in the 0xExxx_xxxx mapping, and a fake Mac99-compatible power management device is added so the Trampoline prepares a driver that can be replaced later.

In the kernel there is one patch: the chosen interrupt controller driver is rewritten to match the Flipper controller, sacrificing an unused driver for space. The expected controller has a legacy mode that raises a PowerPC interrupt whenever the interrupts change, not only when they are raised, so the kernel masks raised interrupts and drivers unmask them in their handlers. In the SuperMario m68k code, paths that touch interrupt controller registers are patched, the audio-interrupt enable and disable pointers are stubbed, and an early ADB and power-management init function that never checks the hardware exists, and so clobbers low memory, is fixed. A hardware-interrupt init function has a copy-paste bug: the jump label to skip serial port 2 setup was not changed when the code was copied from serial port 1, causing an infinite loop if serial port 2 is absent. In native code, more interrupt register access is patched, the USBShimKeyboard init fails to handle having no USB controller and calls a NULL pointer inside the m68k emulator, and the power management driver is replaced with the stub from BlueBox, with a proper driver planned for shutdown and restart.

These patches got the TBXI to boot to the blinking floppy icon. The author then wrote a display driver, helped by Elliott Nunn's virtio driver, and a driver for the GameCube controller ports (ported from the NT driver) so the mouse cursor could move without USB.

A block IO driver for EXI devices stalled over questions of disk layout. Then Mac OS for CHRP was dumped, and the author got sidetracked patching later TBXI images to boot it, thinking Mac OS 7.x would suit a GameCube that lacks the RAM for 8.0's minimum requirements, and then moved to other projects. Almost a year later the author returned, implemented the preferred disk format in OpenBIOS and wrote a driver that fakes SCSI, as some classic Mac OS SATA controller drivers do. Two issues came up. The disk driver, loaded from the disk itself, had to be forced by an m68k patch to load as the newer driver type rather than the older, obsolete one; the fake SCSI driver does not support old-style calls, which probably explains the crash. And the optical disc driver emulates 512-byte sectors on 2048- or 2352-byte sector devices by issuing a read with 3 scatter-gather buffers without checking that the underlying SCSI driver supports it, so the author implemented scatter-gather on reads.

The blinking floppy persisted. Debugging showed that StartLib!GetStartupDevice, a PowerPC function that finds the boot device, assumed things about the device tree and about a built-in SCSI device needing separate handling. The device tree was fixed in the driver's init code; for the SCSI assumption the author had to dig into internal structures and fix an index in 3 places, including the device tree, so it was non-zero and the right code path ran. That produced a happy Mac icon for the first time, followed by rejection from the HFS boot sector. The available text breaks off there, so how that was solved and how the desktop was finally reached is not covered here.

Key facts

  • Guest author Rairii says classic Mac OS ported to ArtX-chipset PowerPC systems (GameCube, Wii, eventually Wii U) has reached the desktop for the first time; the project is nowhere near ready for public release.
  • The author started on 2025-06-22 by forking upstream OpenBIOS, and says no coding agent or LLM was used.
  • Booting needed a ported OpenBIOS plus patches to the Trampoline bootloader, including a replacement MMIO mapping of physical 0x0100_0000 to virtual 0xE000_0000 with length 0x1000_0000.
  • Further patches cover a faked interrupt controller, a fake Mac99 power management device, a serial port 2 infinite-loop bug and a USBShimKeyboard NULL pointer call in the m68k emulator.
  • Later work added a display driver, a GameCube controller port driver, a fake-SCSI disk driver and scatter-gather read support, which led to a happy Mac icon and then a rejection by the HFS boot sector.

Why it matters

The author claims this is most likely the first time since the CHRP clone era that someone outside Apple has brought up classic Mac OS on a new system to the desktop. The post is also a detailed record of what classic Mac OS assumes about its hardware: address-space layout, interrupt controllers, ADB and power management microcontrollers, and boot-device lookup. It is a retro-computing milestone, not a product.

Who it affects

Mainly hobbyists in classic Mac OS, console homebrew and low-level porting. The post names Goldfish64, who began a Mac OS X port to the Wii and made an OpenBIOS port the author drew drivers from, and Elliott Nunn, whose virtio driver helped with the display driver.

How to use it

There is nothing to download yet: the author says the project is nowhere near ready for a public release. The post is useful as a walkthrough for anyone attempting a similar port, covering Trampoline patches, device-tree edits, a fake-SCSI disk driver and scatter-gather support.

How solid is it

This is the author's own first-hand account, and the desktop milestone is the author's claim. The "first since the CHRP clone era" line is qualified as "most likely". The available text of the post is cut off mid-explanation of the HFS boot sector problem, so the final steps to the desktop are not visible, and the text does not say which Mac OS version or which console reached the desktop.

Risks and caveats

The work is unfinished and unreleased. Some choices may change: the MMIO mapping could be revised because of the Wii U's GPU address range, and the power management driver is currently a BlueBox stub with proper shutdown and restart support still to be written. The author also notes the EXI-IDE driver matches an inexact emulator rather than real hardware.

“I do these projects for fun and to learn, if I used “AI” it wouldn’t be fun and I wouldn’t learn anything.”

— Rairii, guest post on virtuallyfun.com