wiiMac boots PowerPC Mac OS X natively on a Nintendo Wii

What the bootloader actually does on the Wii

wiiMac is described as a Mac OS X bootloader for the Nintendo Wii, and its one-line description in the README is that it enables PowerPC versions of Mac OS X to be booted natively on the Nintendo Wii.

The Nintendo Wii's processor is a 750MHz PowerPC 750-class CPU, the same architecture family that early Macintosh hardware used, which is what makes a Mac OS X boot possible at all. The Wii also has a graphics chip that sits close to what early Mac hardware used, and the console's boot chain is the part the project replaces. The result is a Macintosh interface running on a games console, which the README illustrates with a photo of Mac OS X Cheetah running natively on the Wii.

The repository is C, and the layout shows where the work sits. There is a src directory, a Makefile, a broadway.mk and a common.mk for the build, a linker script named mini.ld, an assets directory for images, and an Xcode project. The Makefile is the clearest statement of what the program does: it compiles an object list that includes realmode.o, crt0.o, exception.o, exception_target.o, ipc.o, mini_ipc.o, gecko.o, video_low.o, nandfs.o, a FAT implementation in fat.o and ff.o, an HFS+ implementation in an hfsplus directory with volume, btree, unicode and record handling, a Mach-O decoder, a device tree, APM support, a driver loader, and a kernel allocator.

That list is the architecture in miniature. The bootloader brings up the console, talks to its hardware, reads a filesystem, decodes the Mach-O kernel image that Mac OS X uses, and hands over.

Only Cheetah has a patched kernel and drivers

The support table in the README is short and unambiguous. Mac OS X 10.0 Cheetah has a patched kernel, wii-xnu-124.13, and a driver set, wii-macosx-cheetah-drivers. Puma, Jaguar, Panther, Tiger and Leopard all have dashes in both the patched kernel and drivers columns.

That is the single most important fact for anyone evaluating this project. This is not a bootloader for Mac OS X in general, it is a bootloader for one specific release, with a matching patched kernel and a matching driver repository for that release. The other versions are listed for completeness, or to record that they were considered, and their emptiness is the answer.

Patched kernel and separate driver repositories are the right shape for this work. Mac OS X on non-Apple hardware needs a kernel that has been taught about that hardware, and the drivers need to teach the kernel about the specific devices. Splitting them into two repositories means the kernel patch and the driver set can be worked on separately, and the version pairing makes it explicit which combination is known to work.

The consequence for a user is that an attempt to boot anything other than Cheetah with this bootloader is not a supported configuration, and the README gives no guidance on what would fail or how far it would get.

The hardware list the README says is not supported

The limitations section is a short list, and it is more useful than the feature list because it tells you what a successful boot looks like in practice.

Wi-Fi is not yet supported. Bluetooth is not yet supported. The optical drive is not supported, so there is no way to install from a Mac OS X disc, which is exactly why the installation guide asks you to prepare an install partition on an SD card and boot from it to run the installer. Hardware-accelerated graphics is not supported, meaning the framebuffer runs in software. Audio is not supported, so the console produces no sound from the Mac OS X side.

The optical drive omission and the installer partition are two halves of the same constraint. Because the console cannot read a disc, the Mac OS X installation media has to arrive as a partition on the SD card that the bootloader can boot from, which is why the second card needs three partitions rather than one.

For a hardware project like this the list is reasonable rather than crippling. A console with an SD card is a usable Mac OS X 10.0 environment for demonstration and for software archaeology, and the missing pieces are the ones that need drivers for chips nobody has reverse engineered. The graphics note is the one that will most affect whether the machine feels usable, since software rendering in a period-correct Mac OS X is a different experience from hardware acceleration, and the wording of the limitation is that acceleration is unsupported, not that the display is unusable at all.

Two SD cards, three partitions and a Mac partition map

The installation guide is the most detailed part of the README, and it starts from hardware you have to prepare yourself.

The prerequisites are a Wii with an SD card slot, which rules out the Wii Mini, a soft-modded Wii with BootMii installed as boot2 or as an IOS, an MBR-formatted SD card with a FAT32 partition holding the BootMii files, and a second SD card of at least 4GB for the Mac OS X system. The README's readiness test is simple: if you can open the BootMii menu, you are ready to set up wiiMac.

The BootMii card gets the wiiMac folder copied to its root, containing wiiMac.elf and config.txt, and the expected layout is:

/
└── bootmii
    ├── ppcboot.elf
    └── armboot.bin
└── wiiMac
    ├── wiiMac.elf
    └── config.txt

Then video_mode is set in /wiiMac/config.txt to match the console, with the options ntscp, ntsci, pal60 and pal50. That is the one configuration file the project ships, and it is a single key.

The second card needs three partitions: a destination partition for the installed system, an install partition to boot the installer from, and a support partition holding the patched kernel and drivers. On a macOS host the README starts by running diskutil list to find the device, then partitioning with the APM scheme:

diskutil partitionDisk diskX APM \
  HFS+ "Macintosh HD" R \
  HFS+ "Install" 1G\
  FAT32 "Support" 64M

The APM scheme is the Macintosh partition map, and the sizes are fixed in the guide: a remainder partition for the system, a 1GB install partition and a 64MB FAT32 support partition. The warning that this erases the SD card appears in the guide, and the placeholder device name is meant to be replaced by hand.

Preparing the card from Linux or from WSL

The Linux path uses parted with a mac label, which is how a Mac partition map is created on a machine that is not a Mac, and then the volumes are formatted with hfsprogs:

# Replace sdX with the correct device for the SD card
sudo parted /dev/sdX --script \
  mklabel mac \
  mkpart primary hfs+ 1MiB -1088MiB \
  mkpart primary hfs+ -1088MiB -64MiB \
  mkpart primary fat32 -64MiB 100%

The three partitions are carved at fixed offsets, with the boundaries at 1MiB, minus 1088MiB, minus 64MiB and 100 percent, which mirror the sizes the macOS path produces. The formatting step then names the volumes the same way the Mac path does:

# Replace sdX with the correct device for the SD card
sudo mkfs.hfsplus -v "Macintosh HD" /dev/sdX2
sudo mkfs.hfsplus -v "Install" /dev/sdX3
sudo mkfs.vfat -F 32 -n "Support" /dev/sdX4

The volume names matter, because the bootloader has to find the install and support volumes later. The README also gives the three distribution commands for hfsprogs, with a different package name on Fedora, where the tool ships as hfsplus-tools.

The Windows path is the most involved, and it goes through the Windows Subsystem for Linux because SD card readers are USB devices that WSL does not expose by default. The guide starts by installing usbipd-win through winget, then lists USB devices before and after inserting the card so you can identify its bus id, binds that device, and attaches it to WSL:

usbipd bind --busid 7-1

usbipd attach --wsl --busid 7-1

After that, lsblk -f inside WSL shows the attached card, and the Linux instructions above can be run against it. The 7-1 in these examples is the bus id from the README's own sample output, so it has to be read from your own listing.

Building the bootloader from source

A precompiled bootloader executable is published in the repository releases, and the README points there first for anyone who just wants to run it. The build system is nonetheless documented by its artifacts.

The Makefile includes an.env file, then broadway.mk, and defines the compile-time feature macros, the linker script, and the libraries to link. The defines are a long list of LACKS_ flags, which tell the C library headers not to declare the system interfaces the console does not have, along with flags that declare the presence of long long, unsigned long long and IRQ support. The linker script is mini.ld, and the only library linked is the compiler runtime.

The object list is the interesting part, because it is the feature list of the bootloader written in filenames. There is a real mode object and a crt0, an exception handler and an exception_target handler, the Gekko and IPC modules, a low-level video object, NAND and FAT filesystem code, a font and console module, an IRQ handler, a SHA-1 object, a Mach-O decoder for the kernel image, a boot_args object, a device tree object, an APM object for the Apple Partition Map, a driver_loader, an fs module and a kernel allocator, plus a directory of HFS+ sources handling block iteration, B-trees, records, Unicode, volumes and the file system itself.

The Makefile also has an install target that invokes the DEVKITAMATEUR bootmii tool to push the built ELF onto the console, and an xcoderun target that chains clean, build and install for the Xcode workflow the project directory suggests. The release history shows v1.0.1 on 2026-04-08 and both v1.0.2 and v1.0.3 on 2026-04-29, and the last push was on 2026-07-22, so the repository is still being worked on.

Where this stops being the right project

The honest limits are visible in the structure of the support table and in the fact that only one operating system version has a patched kernel. If your goal is a usable Mac OS X environment with networking, sound or a disc drive, this project does not provide it, and the README says so rather than leaving you to discover it.

It is also a hobby project with an unusual dependency chain. To use it you need a console that has already been soft-modded with BootMii, which is itself a separate procedure with its own documentation, and the two SD cards carry a fixed partition layout that has to be reproduced exactly. The advanced note in the README even suggests a hybrid partitioning scheme with MBR data at sector 0 and APM data at sector 1 to keep everything on one card, but it says the details are left as an exercise for advanced users, which is a fair signal about the intended audience.

The licence situation is worth flagging for a project that ships a bootloader and a modified Apple kernel. The repository facts available here do not state a licence for wiiMac, and the release artefact is a precompiled binary that boots a patched Apple operating system, so a reviewer who intends to redistribute the bootloader or the patched kernel should establish the licensing position before doing anything with the artefact.

The alternative approach, for anyone with a similar itch, is not another bootloader but a different console. The real contrast is with emulation, where an emulator gives you Mac OS X on a modern machine with no hardware modification at all, at the cost of not being native. wiiMac's distinguishing claim is precisely the native part, and its price is the missing hardware support and the single supported OS version.

Editorial conclusion

Adopt wiiMac if you own a soft-modded Wii with BootMii installed and you want to run Mac OS X 10.0 Cheetah on real PowerPC hardware, because the patched kernel and driver set exist for that version only and the project says so plainly. Do not adopt it for a general computing platform, since Wi-Fi, Bluetooth, the optical drive, hardware-accelerated graphics and audio are all listed as unsupported and the only supported system version is Cheetah, and do not attempt it on a Wii Mini, which the README excludes because it lacks an SD card slot. Verify first that you can open the BootMii menu, that the SD card carries the ppcboot.elf and armboot.bin files in a bootmii folder, that your video_mode matches your console region, and that you accept that a second SD card of at least 4GB is required for the system itself.

Frequently asked questions

Official sources

1. bryankeller/wiiMac on GitHub
2. Issues
3. README
4. Releases