Developer Bryan Keller just accomplished what Reddit skeptics called “a zero percent chance”: Mac OS X 10.0 (Cheetah) running natively on the Nintendo Wii. Published April 8, 2026, the project rocketed to #2 on Hacker News with 1,419 points, joining Linux, NetBSD, and Windows NT as operating systems successfully ported to the 2007 gaming console. The detailed technical writeup reveals a journey through bootloader development, kernel patching, and creative driver hacks that overcame the Wii’s unconventional hardware architecture.
The Hardware Made It Possible (Barely)
The Wii’s PowerPC 750CL processor descends directly from the PowerPC 750CXe used in G3 Macs, providing the CPU-level compatibility that makes this port feasible. But compatibility doesn’t mean easy. The Wii’s 88 MB of RAM (split between 24 MB of fast SRAM and 64 MB of slower GDDR3) falls well short of Mac OS X’s official 128 MB requirement. Keller’s QEMU testing proved Cheetah could boot with just 64 MB, making the port technically viable.
The real challenge? The Wii’s Hollywood system-on-chip replaces the standard PCI bus Mac OS X expects. Instead of PCI devices, the Wii uses a dedicated ARM Starlet coprocessor to communicate with hardware components. This architectural mismatch would become the project’s defining obstacle.
As one Hacker News commenter put it: “Programmers of that era really knew how to make a lot from a little.” The contrast between the Wii’s 88 MB and modern software bloat is stark.
USB Implementation: Three Roadblocks and a CVS Repository
The USB driver implementation nearly killed the project. Three separate roadblocks stacked up:
First: Apple never publicly released the IOUSBFamily source code for Mac OS X Cheetah. Without it, debugging the AppleUSBOHCI driver failures was nearly impossible.
Second: The USB driver expected IOPCIDevice nubs (attachment points) that don’t exist on the Wii. Keller’s solution: create a fake NintendoWiiHollywoodPCIDevice subclass that intercepts PCI register queries and returns Wii-appropriate values. The drivers never knew they weren’t talking to real PCI hardware.
Third: Endianness hell. OHCI USB hardware uses little-endian registers. The Wii’s reversed-little-endian system performs byte-swapping in hardware. Mac OS X performs software byte-swapping. The result? Double swaps that broke everything. Initial attempts to patch the binary with Ghidra proved fragile.
Then came the breakthrough: an IRC contact provided the complete CVS repository containing the IOUSBFamily source code. With access to the actual code, Keller could properly remove the software byte-swapping and resolve the architecture-specific issues. USB finally worked.
This is the moment that resonates with every systems programmer: when a seemingly insurmountable problem cracks open because someone in the community shares knowledge. The IRC contact became the project’s unsung hero.
When Standard Debugging Fails, Blink the LEDs
Serial debugging stops working once the Mac OS X kernel starts. How do you track boot progress when you can’t see console output? Keller’s answer: turn the Wii’s front panel LED into a progress indicator.
Using the Hopper disassembler, he mapped source function names to binary offsets in the kernel. Then he patched specific execution points with memory-write instructions that toggle the LED. If the LED blinks, that function executed. It’s cave-painting-level debugging for the modern age—and it worked.
The video display presented a different creative challenge. The Wii’s video encoder expects YUV pixel data while Mac OS X renders to an RGB framebuffer. Keller’s solution: maintain two framebuffers with 60 Hz color-space conversion between them. One for Mac OS X’s RGB compositing, another for the Wii’s YUV hardware output.
One Hacker News systems programmer captured the spirit: “Would have won MacHack back in the day.” These aren’t just workarounds—they’re examples of the hacker mindset that treats constraints as puzzles rather than roadblocks.
Minimal Changes, Maximum Impact
Here’s what separates good engineering from brute-force hacking: Keller modified the Mac OS X kernel in exactly three places. BAT (Block Address Translation) reconfiguration for memory mapping. Hollywood node detection to retrieve the I/O base address. Cache coherency fixes for framebuffer operations.
That’s it. Three focused modifications instead of thousands of scattered patches. The payoff? The system boots unmodified Mac OS X partitions. The custom bootloader (based on ppcskel) handles the Wii-specific boot process, Mach-O kernel loading, and device tree construction, but the OS itself remains largely untouched.
This approach demonstrates deep understanding of the system architecture rather than superficial hacking. Fewer modifications mean better maintainability and clearer documentation for anyone who follows this path.
“Zero Percent Chance” Becomes Reality
When Keller mentioned the project on Reddit, someone replied: “There is a zero percent chance of this ever happening.” In his blog post, Keller explicitly acknowledges this comment as encouragement. Nothing motivates a hacker quite like someone declaring something impossible.
The Hacker News community delivered its verdict: 1,419 points and 242 comments of overwhelmingly positive reactions. Systems programmers shared technical admiration. The NetBSD Wii port contributor offered congratulations. Developers debated practicality versus novelty—but even the skeptics acknowledged the engineering achievement.
This project joins a tradition of Wii hacking that includes Linux, NetBSD, and Windows NT ports. The fail0verflow security research, the Homebrew Channel, and the WiiBrew documentation community all enabled projects like this. It’s a reminder that “because we can” engineering often teaches more than commercially viable projects.
Does running Mac OS X on 88 MB of RAM with YUV color conversion serve a practical purpose? Not really. But it demonstrates OS porting techniques, driver development challenges, and bootloader construction in ways that theoretical documentation never could.
For aspiring systems programmers, Keller’s detailed blog post offers real-world education you can’t get from ChatGPT. The USB implementation breakthrough, the LED debugging technique, the fake PCI device workaround—these are lessons that only come from attempting the impossible and documenting the journey.
