Mac OS 9 boots on a Nintendo Wii. Here's how the Wii pretends to be a Mac

What this project is, and what it is not

Rairii is porting classic Mac OS, the Mac operating system before Mac OS X, to Nintendo's PowerPC consoles: the GameCube and the Wii now, and the Wii U later. Rairii groups them as "ArtX chipsets", because the GameCube's Flipper chipset was designed by ArtX, a company ATI bought, and the Wii and Wii U chipsets are its direct successors.

In late October 2026 the port reached the desktop for the first time. Mac OS 7.6 booted to the desktop on a real Wii, and Mac OS 9.2.2 booted too. Rairii believes this is probably the first time since the 1990s Mac clone era that anyone outside Apple has brought classic Mac OS up on a new kind of machine.

It is not an emulator. Mac OS runs directly on the Wii's own PowerPC processor. It is also not released: Rairii says it is nowhere near ready for a public release, so there is nothing to download, and the project would not supply Mac OS install media in any case.

Rairii has done this kind of work before, with an earlier port of Windows NT to the same consoles and to some PowerPC Mac laptops. That work is where the interest in classic Mac OS came from. Rairii also states that no coding agent or LLM was used: all of the coding, reverse engineering and debugging was done by hand, because the point of the project is to have fun and learn.

Why the processor was never the problem

The Wii's CPU belongs to the same PowerPC family as the G3 Macs of the late 1990s. That comparison is ours, not the post's, but it is why Mac OS code can execute on the console at all.

What differs is everything around the processor. An operating system is written against a particular set of hardware: an interrupt controller at a known address, a power management chip it can talk to, timers, serial ports, a display and disks. It also asks the firmware what is plugged in, through a structure called the device tree. On a Wii, almost none of those answers match what a Mac would give.

So the port has two halves. One is writing drivers for hardware Mac OS has never seen, such as the display, the disks and the controller ports. The other, the subject of the video, is changing what the Wii says about itself so that Mac OS's existing code finds what it expects.

How a classic Mac boots, and where the port starts

Later PowerPC Macs, the "New World" machines, boot classic Mac OS in stages:

• Open Firmware is the machine's firmware. It builds the device tree and loads a boot file.
• The Trampoline is Apple's bootloader. It runs on top of Open Firmware, reads the device tree, sets up memory and the kernel's mappings, and hands over to the kernel.
• The Mac OS ROM file (Rairii calls it the TBXI) contains the rest: the PowerPC kernel and a large body of older 68k code that Mac OS still runs through an emulator. Inside Apple, that 68k part carried the codename "SuperMario" for the whole PowerPC era.

Consoles have no Open Firmware, so the first step was porting OpenBIOS, an open source implementation of it. Rairii borrowed some drivers from Goldfish64's OpenBIOS port, which was built for a Mac OS X port to the Wii, but kept a separate port so the GameCube could be supported too. Rairii also reused an existing firmware loader from the Windows NT port, changed to load a big-endian ELF.

For the first tests there was no disk format yet, so the Mac OS ROM file was simply placed on a FAT filesystem where OpenBIOS would load it at boot. From there, Rairii's rule for every patch was to apply it as late in the boot as possible, so that a mostly untouched Mac OS install disc could eventually be used as it is.

The memory map: pointing the kernel at the Wii's hardware

The first problem was the Trampoline's assumptions about the physical address space.

• It assumes everything from address 0x8000_0000 upward, the top half of a 32-bit address space, is memory-mapped hardware. On real Macs that is where the PCI bus sits. On the Wii nothing is there, and on the Wii U that range is RAM.
• It assumes RAM is laid out without holes. On these consoles there are gaps between areas of RAM, and some of the gaps hold hardware registers.
• It calculates the physical address of a buffer in a way that comes out invalid on these machines.

The fix for the first is a single changed mapping. The kernel keeps a list of memory chunks and how they map. Rairii patched the entry that maps hardware so that physical `0x0100_0000` maps to virtual `0xE000_0000`, with length `0x1000_0000` (256 MB). That one window covers all of the console's memory-mapped hardware, plus the end of one RAM area and, on the Wii and later, the start of another. The buffer address was patched to one guaranteed to be valid.

Two details show how much version-specific work hides behind that one sentence:

• The Trampoline's function for creating a mapping changed between versions, from a 16-bit page count to a 32-bit one. The port detects the older version and hooks the function to work around it.
• Older Trampolines also set up unconditional one-to-one mappings for everything above 0x8000_0000, which collide with the new mapping, so those have to be removed.

Rairii notes the window may change for the Wii U, where part of that virtual range lines up with a block of the GPU that can present memory with different layouts, and could be useful later.

The device tree: introducing the Wii as a Mac

The device tree is edited so that the Trampoline accepts it:

• The interrupt controller is listed as one of the Apple controllers the Trampoline recognises. Rairii chose a little-endian one that sits on the PCI bus in real Macs, because at the register level it is the closest match to the Flipper interrupt controller found in all of these consoles.
• The framebuffer, the memory the screen is drawn from, gets its address changed to the uncached virtual address inside the new 0xE000_0000 window.
• A fake power management device, compatible with the "Mac99" Macs, is added. Every PowerPC Mac has a power management microcontroller, and with the fake entry present the Trampoline prepares a power management driver for it. That driver is replaced later: for now with a stub driver from BlueBox, with Rairii's own planned to add proper shutdown and restart.

Separately, the Trampoline itself is patched where it assumes Mac hardware. It sets flags saying the power management microcontroller is present, tries to recalculate the bus frequency with a specific hardware timer, and writes to the real interrupt controller's registers. Each of those is patched out or adjusted. Finally, the Trampoline's last jump into the kernel is hooked, so more patches can be applied once everything is in memory.

The kernel's interrupt driver

The kernel needs only one patch. It contains several interrupt controller drivers. The one Mac OS picks is patched to drive the Flipper controller instead, and an unused driver is sacrificed to make room for the extra code.

The important difference is behavioural. The Apple controller being imitated has a legacy mode where it raises a PowerPC interrupt whenever the set of pending interrupts changes, not only when one is raised. Code written for that behaviour would misbehave on Flipper, so the kernel masks the raised interrupts and the individual drivers' interrupt handlers unmask them later.

Apple's old bugs, found by missing hardware

Running Mac OS on a machine that lacks Mac hardware exposes code that was never tested without it. Rairii lists several:

• The serial port 2 loop. The routine that sets up hardware interrupts is meant to skip serial port 2 when that port does not exist. The code was copy-pasted from the serial port 1 version, and the jump label was never changed, so the skip jumps back to port 1's label. On a machine with no serial port 2, that check runs again and again, forever.
• Power management that never checks. A function called early in boot initialises the ADB and power management microcontroller without checking that it exists. When it does not, the function overwrites parts of low memory.
• A keyboard shim with no USB. The USBShimKeyboard driver does not handle the case where there is no USB controller at all, and calls a null pointer inside the 68k emulator.
• Direct register access. Both the 68k code and native PowerPC code read and write interrupt controller registers directly, so those places are patched to match. The function pointers that enable and disable audio interrupts are pointed at a stub that already exists in the same table.

From blinking floppy to the desktop

With those patches the boot reaches the blinking floppy, the icon Mac OS shows when it cannot find a disk to start from. Getting past it took drivers and some unexpected detours.

• Display and input. Rairii wrote a display driver, helped by Elliott Nunn's virtio driver, and ported the GameCube controller port driver from the Windows NT port, so the mouse cursor moves with a GameCube controller instead of USB.
• Disks. These consoles talk to memory cards over EXI, which is Nintendo and Macronix's name for SPI. Rairii ported two drivers: one for the SD Gecko, an adapter that lets an SD card plug into a GameCube memory-card slot, and one for EXI-IDE, which Rairii emulates in a personal build of the Dolphin emulator for low-level debugging.
• A disk driver that pretends to be SCSI. After a long pause, Rairii settled on a disk format inside OpenBIOS and a driver that presents the disk to Mac OS as SCSI, which some classic Mac OS SATA drivers also do. Mac OS had to be patched to load the disk's own driver as the newer driver type, and the CD driver turned out to issue reads with three scatter-gather buffers without checking support, so the fake SCSI driver had to implement scatter-gather reads.
• Choosing the startup disk. Boot still failed, because a function in StartLib that finds the startup device assumed a built-in SCSI device. Rairii fixed an index in three places, the device tree among them, so the right code path ran.

That produced the happy Mac for the first time, followed by one more failure that was Rairii's own: the driver did not expect a buffer at an odd address, and a single byte went missing, shifting everything after it. Checks on a resource fork caught it.

In the Dolphin build, Mac OS 9.2.2 then booted very slowly and crashed after about an hour. Mac OS 7.6 crashed sooner, apparently while loading the MacsBug debugger. With MacsBug removed, 7.6 reached the desktop after about 20 minutes in emulation. The next morning, on a real Wii booting over the SD Gecko, 7.6 reached the desktop in about 40 seconds. Rairii expected that SPI mode to be the slow one; the reason it is not is that Mac OS lets the driver use the whole CPU during a transfer, and even an asynchronous transfer just has the caller busy-wait until it finishes.

Two last findings: the MacsBug crash was a bug in the emulation, not on real hardware, and Mac OS 9.2.2's crash on real hardware came from Open Transport, its networking stack. With Open Transport removed from the Extensions folder, 9.2.2 boots. Rairii's guess is that Open Transport cannot cope with a machine that has no serial or network device at all.

What is not done yet

As of 29 October 2026:

• The port is not released.
• It boots over the memory-card slot; the Wii's own SD card controller is next, then its USB controller.
• The Wii U is after that.
• The GameCube does not have enough RAM for the minimum requirements of Mac OS 8.0, which is part of why getting Mac OS 7.x to boot mattered. Rairii also wants to work around some of the RAM limits later.

Terms

Classic Mac OS

Apple's operating system for Macs before Mac OS X, up to Mac OS 9.2.2.

PowerPC

The processor family used in Macs from 1994 to 2006 and in the GameCube, Wii and Wii U.

Open Firmware

The firmware standard later PowerPC Macs boot from. It describes the hardware and loads the operating system.

OpenBIOS

An open source implementation of Open Firmware, ported to the consoles for this project.

Device tree

The structured list of hardware the firmware hands to the operating system at boot: each device, its type and its addresses.

Trampoline

Apple's classic Mac OS bootloader on New World Macs. It reads the device tree, sets up memory and starts the kernel.

Memory-mapped I/O (MMIO)

Hardware registers that appear at memory addresses, so software reads and writes them like memory.

Virtual address

The address software uses. The kernel's page tables map it to a physical address in RAM or hardware.

Interrupt controller

The chip that collects signals from devices that need attention and tells the processor which one.

Power management microcontroller (PMU)

A small chip in every PowerPC Mac that handles power, sleep, and on older models the keyboard and mouse bus (ADB).

EXI

Nintendo's name for the SPI bus the GameCube and Wii use for memory cards and similar devices.

SD Gecko

An adapter that plugs an SD card into a GameCube memory-card slot.

Dolphin

An open source GameCube and Wii emulator, used here for debugging.

MacsBug

Apple's low-level debugger for classic Mac OS.

Open Transport

The networking stack of classic Mac OS.

Happy Mac and blinking floppy

The boot icons classic Mac OS shows when it has found a startup disk, and when it has not.

Questions

// further reading

• My favourite PowerMac is a Nintendo Wii ↗: Rairii's own account of the port, with screenshots of 7.6 and 9.2.2.
• entii-for-workcubes ↗: Rairii's earlier port of PowerPC Windows NT to the GameCube, Wii and Wii U.
• OpenBIOS ↗: the open source Open Firmware implementation the port's firmware is built on.
• Dolphin ↗: the GameCube and Wii emulator used for debugging.