Running Windows NT on a GameCube is a feat of emulation archaeology with lessons for AI

A developer known as Wack0 has done something that sounds like a joke from 2005: they ported Windows NT to the Nintendo GameCube and Wii. The project, called “entii-for-workcubes,” runs NT 3.51 and NT 4.0 on the PowerPC-based consoles. It is not a toy. It is a methodical piece of systems engineering that required rewriting a Hardware Abstraction Layer, building a custom ARC firmware bootloader, and writing drivers for the Flipper GPU, the GameCube controller ports, and the Wii’s USB stack via IOS.

The project supports GameCube, Wii, Wii Mini (with an SD card hardmod), and Wii U in vWii mode. It will never support early Dolphin development hardware with only 4 MB of usable RAM. The README lists 12 distinct driver subsystems, from the Flipper interrupt controller to the Vegas SDMC controller. The GDI driver copies from a bitmap buffer to the GPU texture buffer using “slow unoptimised code,” as the author candidly notes. The EXI bus is slow enough that installing NT on a GameCube is a visibly tedious process.

This is the kind of project that most coverage will file under “retrocomputing curiosity.” That framing is too narrow. What Wack0 built is a case study in a problem that AI research faces every day: how to run modern software on hardware that was never designed for it, with incomplete documentation, and with no vendor support.

The parallels are direct. AI labs routinely run inference on hardware that was not designed for their models. The H100 was not built for transformer inference. The MI300X was not built for sparse attention. The Groq LPU was not built for anything except a specific class of neural network. Every AI deployment is a porting effort, complete with custom kernels, hand-tuned assembly, and workarounds for undocumented hardware behavior.

Wack0’s approach mirrors how AI researchers handle legacy model compatibility. The project uses a custom ARC firmware bootloader adapted from The Homebrew Channel. It uses a little-endian libc compiled from baselibc. It uses a modified Petit FatFs for filesystem access. The HAL and drivers are built with a toolchain that includes a VC6 PowerPC CE cross compiler for the C preprocessor, PASM.EXE from MSVC 4.2, and SPLITSYM.EXE from the NT 3.51 DDK. This is a stack of software from 1996 to 2024, all glued together to make one OS boot on hardware from 2001.

AI researchers do the same thing. They compile PyTorch 1.13 against a custom CUDA 11.8 runtime on a kernel that Ubuntu stopped supporting in 2023. They patch FlashAttention to work on a compute capability that NVIDIA marked as deprecated. They write custom NCCL hooks because the collective communication library does not support their topology. The skill set is the same: read the hardware manual, read the OS source, write the glue, test on real silicon.

The project also demonstrates the value of simulation and emulation for AI training. Wack0’s ARC firmware includes a USB Gecko driver for kernel debugging, an N64 Randnet keyboard driver (completely untested), and an N64 mouse driver. The author acknowledges that some devices have not been tested on real hardware. This is exactly how AI safety researchers approach red-teaming: they simulate environments that do not exist yet, test against emulated hardware, and document failure modes before real deployment.

The GameCube controller port driver is a small masterpiece of input mapping. Under NT text setup, the left analog stick maps to up/down, the c-stick maps to page up/page down, the A button maps to enter, the B button maps to escape, the X button maps to F8, the Y button maps to C, and the Z button maps to L. Under NT GDI, the left analog stick moves the mouse, and L+R together maps to ctrl+alt+del. The c-stick allows choosing a keyboard scancode from 1-9, 0, and a-z, with numbers first in the list so numeric-only text boxes like entering a CD key still work. This is the kind of UX design that only emerges when someone has actually tried to type a product key with a controller.

The AI industry needs more of this thinking. The dominant approach to AI infrastructure is to buy the newest GPU, install the latest CUDA version, and hope the model compiles. That works until it does not. When a lab needs to run a model on a chip that is no longer supported by the vendor, or on a cluster with a custom interconnect, or on a node with a different memory architecture, the Wack0 approach becomes the only option: read the hardware documentation, write the driver, test on real silicon, and accept that some features will be slow or broken.

The project also has implications for AI policy. The ability to run a 30-year-old operating system on a discontinued console is a form of digital preservation. The ability to run a model on hardware that the vendor has abandoned is a form of AI sovereignty. If a lab in a jurisdiction with export controls wants to run inference on hardware that is not on the approved list, they need exactly this kind of reverse engineering. The entii-for-workcubes project is a proof of concept that the skill exists.

There is a practical lesson for AI builders here. The README notes that NT 3.5 will never be compatible because it only supports PowerPC 601. The developer made a hard cut: some hardware is too old, some software is too incompatible, and some combinations are not worth the effort. AI labs should do the same. Not every model needs to run on every GPU. Not every framework needs to support every architecture. The discipline to say “this will never be supported” is as important as the ingenuity to make the improbable work.

The most telling detail in the project is the list of acknowledgements. Wack0 credits The Homebrew Channel, devkitPro, libogc, Swiss, Petit FatFs, and the NT4 DDK example framebuf driver. Every line of code in entii-for-workcubes stands on a stack of open-source projects that were themselves acts of reverse engineering. The AI industry runs on the same stack: CUDA, PyTorch, TensorFlow, ONNX, Triton, vLLM, and a hundred other projects that are, at their core, ports of software to hardware that was never designed for it.

The project is not a joke. It is a manual for how to make software run where it was never meant to. AI researchers should read it.