If you want to play an N64 game on your PC, you’ve almost certainly used an emulator at some point. Project64, mupen64plus, or maybe the N64 core in RetroArch. You drop in a ROM, the emulator reproduces the N64’s CPU, graphics, audio, and coprocessor behavior well enough for the game to run, and it just works. It’s been the standard approach for decades, and for most people, it’s still the obvious one.
But emulators aren’t the only option anymore. A growing community of reverse engineers has been reconstructing N64 games as native applications for all kinds of platforms, most notably PCs, with widescreen support, unlocked frame rates, 4K rendering, and proper controller mapping baked in. There are two main routes here: painstaking matching decompilations that produce readable source, and newer static recompilation projects that translate the original machine code without trying to recover clean source.
I’ve been playing with these ports on and off for months, mostly on my Steam Deck. They’ve held up better than I expected. Yes, they can be buggy, and yes, you have to bring your own ROM. But Ocarina of Time running natively at 90Hz on a handheld in 2026, off a project nobody got paid to build, is one of those things that most people never think of when they consider game preservation.
What game decompilation actually is
Not emulation, not remaking, something in between
Decompilation is the process of examining a game’s compiled binary and reconstructing equivalent C source code that produces the same machine code. The goal is a “matching decompilation,” which means writing source that compiles to machine code matching the original build, usually down to the byte, though it’s worth noting that reconstructed C is not necessarily the exact original files developers wrote. A PC port (or to any other platform, for that matter) then adds a platform layer on top, while static recompilation skips the readable-source goal and translates machine code into intermediate C/C++ code that can be compiled for modern platforms.
Matching matters because it gives the project a hard correctness target for the original game before anyone starts changing it. It’s also usually done against one specific ROM revision, which is why these projects care so much about regions, versions, and checksums. A North American Rev 0 dump and a Rev 1 dump from a re-release can differ in ways that completely break a match.
The way this work happens is more involved than the term might suggest. Nobody is running a decompiler and getting usable C code back. Instead, researchers start with the game’s ROM and disassemble the binary into MIPS assembly. They identify each function’s structure using tools like Ghidra or IDA Pro, then write C code by hand that produces assembly matching the original. Matching often depends on the same compiler, flags, and libraries used for the original build. For many N64 projects, that means running SGI’s old IDO toolchain through QEMU-IRIX or a similar setup.
This is why the process takes so long. Every function has to be reverse-engineered individually, and the only way to confirm your work is correct is when the compiler produces output that matches the original binary. There’s no partial credit. Either the bytes line up, or you keep going.
Super Mario 64 started the modern N64 wave
A speedrunning project that became something more
Many of the modern N64 decompilation projects trace their lineage back to Super Mario 64. The SM64 decompilation began around 2018, driven largely by speedrunners and reverse engineers who wanted to understand the game rather than build a PC port. It reached its major matching milestone after roughly two years of volunteer work.
What made SM64 a feasible first project was that the commonly targeted North American build used unoptimized code, making its assembly simpler to match than heavily optimized games like Ocarina of Time. With optimization flags enabled, equivalent C patterns can compile to similar-looking assembly, making matching a trial-and-error puzzle. Without those flags, the relationship between the C and the resulting MIPS is much more direct, and a careful reader can usually work out what the original source looked like.
That difference is why SM64 finished first, and OoT took years longer.
The SM64 project helped establish the tooling and community knowledge that later fed into ZRET’s Ocarina of Time and Majora’s Mask decompilations. Those efforts became the foundation for HarbourMasters’ Zelda ports. Their best-known project is Ship of Harkinian, the Ocarina of Time source port with a full settings menu, resolution scaling, custom controls, and an in-game debugger. 2Ship2Harkinian is the equivalent Majora’s Mask source port, and Ghostship is HarbourMasters’ modern Super Mario 64 port. Without SM64, the modern N64 decompilation scene would probably have grown much more slowly, if at all.
These ports don’t feel emulated, which is the entire point. The game code is actually running natively on your hardware, so there’s lower overhead and better performance than emulation. Instead of relying on an emulator’s interpretation or a dynamic translation layer, the port runs as a native application, just like any other PC game.
That source-port model is powerful. It also only works after the slow decompilation work is mostly done.
I don’t need the Switch 2’s Zelda: Ocarina of Time remake — I already made my own
Ship of Harkinian powers a native PC port of the N64 classic.
N64 Recompiled changed the timeline from years to weeks
Static recompilation makes ports possible at scale
That bottleneck is what N64 Recompiled tries to bypass. Mr-Wiseguy’s tool takes a game binary and translates its MIPS machine code into C code that can be compiled for modern platforms, through a process called static recompilation. The result is useful source for a compiler, not clean source for humans. If you open one of these generated files expecting tidy loops and named variables, you’re going to be disappointed.
Static recompilation moves much of the translation cost ahead of time and exposes the translated code to a normal compiler, while the port layer can map input, rendering, audio, and timing to modern APIs. Modern input features are a good example: a port can add hooks or patches that map mouse, gyro, or controller input into the game directly, instead of relying on an emulator’s input shim.
Mr-Wiseguy told Ars Technica that his tool is “the difference between weeks of work and years of work” when it comes to making a PC version of a classic N64 title, though that doesn’t mean every game becomes a weekend project. Each one still needs game-specific work around overlays, memory layouts, graphics and audio integration, input handling, timing quirks, and which ROM revisions it targets. Many of these projects also lean on RT64, the renderer Mr-Wiseguy and others have built up alongside the recompiler, to translate N64 graphics into something that looks at home on a modern GPU. What it does change is the scale; tasks that used to require multi-year volunteer commitments can now be handled by a single person in a fraction of the time.
The catalog has grown quickly as a result. N64 Recompiled-style projects now range from polished public ports like Banjo-Kazooie, which has Linux, Windows, and Steam Deck support out of the box, to in-progress work on games such as Bomberman 64, Dinosaur Planet (the unreleased N64 project that eventually evolved into Star Fox Adventures), Dr. Mario 64, and Mystical Ninja Starring Goemon. Separately, Mario Kart 64 has SpaghettiKart from HarbourMasters, which uses the source-port approach instead.
It’s not just N64, Pokemon and Sonic are in too
Decompilation is spreading across other retro platforms
The N64 has the most visibility right now, but the decompilation and recompilation movement extends well beyond Nintendo’s 1996 console. And not every project is trying to become a PC port.
With Pokemon, the reconstructed source is more important as a modding foundation than anything else, and the pret team’s pokeemerald project is the most prominent example. It’s a fully matching decompilation of Pokemon Emerald for GBA, and it’s become the basis of the modern Pokemon ROM hack ecosystem. Instead of fragile binary patching, projects like pokeemerald-expansion now add new mechanics, maps, Pokemon, abilities, and entire post-game regions by editing the actual C code. The end result is that every hack utilizing it feels less like a bunch of patches glued onto a finished game and more like alternate versions of it.
Sonic has a foothold on the Xbox 360 side. Sonic Unleashed Recompiled showed static recompilation could work on a major Xbox 360 game, turning one of the console’s more demanding titles into a native PC port with higher frame rates and resolutions than the original hardware allowed. ReXGlue, an SDK that came after, is now trying to generalize Xbox 360 static recompilation for other projects, so future ports don’t have to rebuild the entire pipeline from scratch.
Animal Crossing for GameCube is the big surprise of the bunch. It has a near-complete ac-decomp decompilation, and a developer called FlyingMeta built an early PC port on top of that work. It’s one of the first GameCube decompilation projects to make the jump to a playable PC port, with widescreen support and 4K rendering. The port is rough in places; audio, in particular, is still a work in progress, but the fact that it runs at all is the news. GameCube preservation has historically lagged behind N64, partly because the hardware is more complex and partly because Dolphin’s emulation has been good enough that nobody felt urgent pressure to do this kind of work.
The common thread isn’t any single console, but old binaries becoming editable, portable, or at least understandable again. And it’s happening on platforms ranging from the SNES and PlayStation to the Sega Genesis, Dreamcast, and more Xbox 360 titles.
How you actually play one of these
You need a ROM, but setting it up is straightforward
If you want to try one, the basic process is the same across most projects. You need a ROM or ISO of the original game, which you dump from your own copy using a flashcart or a modded console (or acquire elsewhere). The project’s release page will tell you which ROM region and revision it expects, and most verify that dump by checksum before extracting assets or launching. Depending on the port, the ROM might be used once to extract assets into a project-specific data file, rather than being read every launch, and after that initial extraction, the game works without it.
Most N64 Recompiled projects are distributed as standalone releases with their own setup instructions, commonly for Windows and Linux, with macOS support depending on the project. On Steam Deck, many mature ports now ship native Linux builds, AppImages, or Flatpaks, so setup is usually closer to adding a non-Steam game than configuring an emulator. On retro Linux handhelds, PortMaster can also simplify the install step for ports it packages.
The HarbourMasters decomp ports tend to have their own launchers with built-in settings menus, so you can tweak resolution, framerates, and controls without touching config files.
Why this matters
Preservation, with rough edges and a watchful Nintendo
Nintendo isn’t thrilled about any of this. It went after early SM64 PC port distributions in 2020 and has a long track record of pursuing projects that remix its IP. The likely legal argument is that rebuilt code can still reproduce protected expression even when the source was reconstructed by fans. Most projects try to stay on the safe side by shipping no copyrighted assets and requiring users to provide their own ROM, but that’s not a legal shield. N64 Recompiled sits a step further removed, since the tool itself contains no game-specific code, but none of this has produced a clean court-tested rule, and it probably won’t until someone builds something Nintendo decides is worth a lawsuit.
Even with that hanging over the scene, the deeper value of these projects is access and longevity. Emulation does most of the heavy lifting for preservation right now, and it’ll keep doing it. Native ports add something different: a game that exists as a normal PC application, runnable without an emulator layer, modifiable by anyone with the source, and not dependent on anyone updating a core for the next platform shift.
The source code for many games is buried inside companies, or in some cases, simply doesn’t exist anymore as backups were lost, studios closed down, or hardware died. A human-readable reconstruction means future generations can study how these games actually work, regardless of whether a port ever ships. Work on Twilight Princess, Harvest Moon 64, Paper Mario, and Street Fighter III: 3rd Strike has produced documentation and code that wouldn’t otherwise exist outside the original studios, even when no port follows.
That said, the ports themselves still have rough edges. The Animal Crossing port is early, so bugs and missing features are expected. Some N64 Recompiled projects struggle with games that use custom graphics microcodes, like the Factor 5 titles Rogue Squadron and Indiana Jones and the Infernal Machine, which never quite played by the standard N64 rules to begin with. The automatically generated C code from recompilation isn’t very readable unless you’re familiar with MIPS assembly, which limits how easy it is for other developers to contribute or modify the code.
Emulators also cover far more ground, support a wider range of consoles, and continue to improve in accuracy. For most people, dropping a ROM into Project64 or RetroArch is simpler and good enough. These ports won’t replace that, and they don’t need to. For the handful of games that do get this treatment, though, unofficial native ports feel like a preservation path that shouldn’t exist, yet somehow they do. This is volunteer work, with no corporate backing and no official blessing. The fact that these games are getting a future on modern hardware at all is what matters most.
This fan-made Banjo-Kazooie PC port does what Nintendo won’t — and it’s free
Banjo: Recompiled modernizes one of my favorite childhood N64 games in the best way possible.