How N64Recomp turns Nintendo 64 games into native PC ports
Static recompilation is quietly replacing traditional emulation by translating MIPS binaries directly into C code.
An addiu instruction on a Nintendo 64 adds a 32-bit value to a register and stores the 64-bit result. For decades, playing a Nintendo 64 game on a PC meant running a software emulator that read that instruction, figured out what it meant, and simulated the console's response in real time. Developer Wiseguy took a different route. He built a tool that just translates the instruction into standard C code.
The project is called N64: Recompiled. It's a static recompiler that turns compiled MIPS binaries into native source code. You feed it an N64 ROM and some metadata, and it spits out C files that compile directly for Windows, Linux, or macOS.
Wiseguy first proved the concept in May 2024 with Zelda 64: Recompiled, a fully native PC port of The Legend of Zelda: Majora's Mask. That release bypassed the traditional headaches of Nintendo 64 emulation. There were no micro-stutters from dynamic recompilation and no need for complex graphics plugins. The game just ran as a native application, supporting high framerates and modern dual-analog camera controls. Two years later, the toolchain has grown into a mature ecosystem that is steadily converting the Nintendo 64 library into PC games.
Translating MIPS without the middleman

The recompiler works by splitting the input binary into individual functions. It processes instructions one by one and emits corresponding C code. The translation is entirely literal. That addiu instruction becomes ctx->r4 = ADD32(ctx->r4, 0X20);. A jump-and-link instruction becomes a standard function call.
This literal approach keeps the complexity low, but it requires a runtime environment to handle the hardware quirks. The tool emits function lookups for virtual functions, which the runtime handles using a lookup table. It also supports relocatable overlays. The recompiler modifies instructions that possess relocation data, emitting macros that let the runtime adjust the immediate values based on where the section is loaded in memory.
I want to see how this handles the really obscure custom microcode games. The Nintendo 64's Reality Signal Processor was notoriously difficult to program, leading many developers to write their own custom microcode to squeeze more performance out of the console. N64: Recompiled currently supports recompiling RSP microcode, which removes one of the biggest historical bottlenecks in N64 preservation.
Single file output for faster patching
One of the smartest features in the toolchain is its single file output mode. When configured this way, the recompiler dumps every function from the provided ELF file into one massive output file. This exists entirely for modding and patching.
Standard linkers like MSVC's link.exe or LLD only look for symbols in a static library if they haven't already found them. By feeding patched functions to the linker before the original recompiler output, developers can seamlessly replace original game code with modified versions. You don't have to recompile the entire target binary just to test a small patch.
The open-source ecosystem around these tools moves fast. Repositories like Adam, a static recompilation PC port of the Nintendo 64 game Neon Genesis Evangelion, show how quickly developers are porting games and iterating on runtime environments. N64: Recompiled relies on a stack of existing open-source libraries to function, including rabbitizer for instruction decoding and ELFIO for parsing the binaries.
The end of the emulator plugin
The Nintendo 64 launched in 1996 with a custom 64-bit architecture that gave emulator developers headaches for two decades. Early emulators relied on high-level emulation, guessing at what the console's Reality Coprocessor was trying to do and approximating the results. This led to the infamous era of emulator plugins, where you needed a specific video plugin for GoldenEye 007 and a completely different one for Donkey Kong 64. Accuracy required low-level emulation, which demanded massive processing power.
Static recompilation bypasses that entire history. When Wiseguy launched Zelda 64: Recompiled, he picked Majora's Mask for a reason. The 2000 release was one of the few games that required the Expansion Pak memory upgrade, pushing the console to its absolute limits. Running it flawlessly as a native PC application proved the toolchain was viable.
Static recompilation isn't a new concept. The jamulator project did something similar for the Nintendo Entertainment System, and the IDO static recompilation project translates the original SGI IRIX compiler to run on modern systems. Wiseguy cites the IDO project as his main inspiration.
What makes N64: Recompiled different is the target platform. By sidestepping emulation entirely, static recompilation allows these games to run natively on relatively weak hardware. It also changes how mods work. Because the output is standard C code, developers can hook into the game engine directly. They can add ray tracing, replace textures, or build entirely new levels without fighting against an emulator's memory management.
Comments ()