Back

Nearly all Nintendo 64 games can now be recompiled into native PC ports

213 points6 hourstomshardware.com
skrrtww4 hours ago

To operate this tool, you still need to disassemble the ROM up front and annotate it heavily before it can be recompiled. This tool is very nice, to be sure, but the hyperbole about anything close to one-click generation of standalone executables for an arbitrary ROM is getting out of hand.

slongfield2 hours ago

To be fair, N64 is not the PS2 or Gameboy--there are only 388 games that were released for it. Going through all of the games that were released and shepherding them through this process is feasible.

speps3 hours ago

Except this work can be done once, stored somewhere and shared. Take a ROM (it means read-only after all) and get native port out...

Hamuko12 minutes ago

Shared legally?

doublepg232 hours ago

I don't think that's true. The video in the post shows a no-name n64 game being recompiled and running fine. No annotation needed.

amlib1 hour ago

The video also makes it clear that only games using a certain microcode works for now. I imagine there are many parts of HLE emulation that gets added to the recompiled software as wrappers and compatibility code to make it all work, so in a sense this may be more akin to an embedded emulator into a native binary (recompiled code), which can overtime be worked on to add new features, fix shortcomings of the original software and make it more "ergonomic"/compatible with it's new target platform. But such work can only feasibly be achieved by reverse engineering the software and giving it human readable symbols. In a sense there is almost as much work to do as on the previous decompilation projects, but you can get results (run the game) right away (or at least much faster than traditionally), assuming of course the game uses a compatible microcode and isn't doing anything fancy that depends on the intrinsics of the n64 architecture.

DaiPlusPlus1 hour ago

There’s also inevitably going to be timing/performance-related bugs - the N64’s devkit docs say it runs games under a thin OS for multi-threading[1] so that’s another opportunity for things to go wrong.

Also, after conversion these games are still designed and hardcoded for an N64 controller and 4:3 aspect-ratio - that’s hardly “native” as far as PC gamers are concerned.

[1] https://ultra64.ca/files/documentation/online-manuals/man/pr...

christkv1 hour ago

I’m guessing it works for the standard Nintendo provided microcodes.

darby_eight2 hours ago

> you still need to disassemble the ROM up front and annotate it heavily before it can be recompiled.

Why? Surely it's more straightforward to do binary-to-binary translation. No human input needed!

keb_3 hours ago

Very true. There is nothing special about this tool at all. Nothing to see here folks.

lcnmrn46 minutes ago

I wish all game executables would be OS agnostic, something similar to WebAssembly: GameAssembly. For example you can no longer play 32-bit games on new macOS version, neither 32-bit Windows games under Wine. It's almost impossible to find 64-bit .exe files so they can run under fine under Wine/Crossover.

hot_gril33 minutes ago

I was able to run 32-bit Windows games on Mac, even on Apple Silicon. GTA IV on my M1 mini. There's some kind of "32 on 64" translation built into whatever version of the 32-bit Wine that PlayOnMac installs. Impossible to Google so idk how it really works.

It's funny how the Mac is more compatible with old Windows programs than old Mac programs.

lambertsimnel32 minutes ago

I agree with your sentiment, but I've had satisfactory results running 32-bit Windows games on x86_64 Linux

On Debian, I found I had to run

  dpkg --add-architecture i386 && apt-get update
and then install the wine32 package
treyd36 minutes ago

CIL is kinda like this for games implemented heavily in C#.

lupusreal40 minutes ago

The JVM does this pretty well for Minecraft. I doubt Minecraft would support Linux, the BSDs, etc without it. Bedrock edition (the not-JVM version which supports Windows and consoles/phones) doesn't even support MacOS even though it obviously could.

hot_gril27 minutes ago

If Minecraft were a Microsoft product from the start, they probably wouldn't have made the Java version compatible with Mac or Linux (even though it uses JVM, there are some natives included), or wouldn't have made a Java version to begin with.

jonhohle5 hours ago

This is really cool. Many of the foundational tools created for N64 decomp are finding their way into other system decomp packages. I recently came across https://decomp.me/ which allows collaborative decompilarion for a bunch of systems with presets for their relevant SDKs and hardware. I’d imagine this happening several more systems in the coming years.

tombert19 minutes ago

This is pretty neat; can someone tell me if this could lead to a proper working version of Conker on the MiSTer? E.g. could this be used to assist in a decompilation and then someone could make a fix?

kkukshtel4 hours ago

I saw this when it came out, and as someone that doesn't follow the ROM hacking scene, I'm wondering - why did this approach take so long to come up with? Translating the assembly instructions to C and then recompiling them seems like an obvious method to try early on, but I'm wondering if there was some other breakthrough that made this possible in a way it wasn't before?

slongfield2 hours ago

The N64 has a GPU, which is not the same as modern GPUs, and you need that GPU to render graphics.

Skimming the Github repo, looks like this uses rt64 under the hood for the raytracing support ( https://github.com/rt64/rt64 ), and that uses the ubershader technique to emulate the GPU. This excellent article talks about the what, why, and insanity that are ubershaders: https://dolphin-emu.org/blog/2017/07/30/ubershaders/

kkukshtel43 minutes ago

Was raytracing support necessary to get the compilation working to circumvent "normal" GPU calls?

DCKing54 minutes ago

Other emulators want to solve the problem generically, and this solution doesn't quite.

Static recompilation from one machine language to one other language is somewhere between extremely difficult to not being generally possible in practice [1]. To make recompiling something like this properly, you need some help from the binaries that make recompilation easier [2] and on top of that you need to patch certain things to make this work [3].

Dynamic recompilation doesn't have this problem. It allows you to create software you can dump the original binaries+assets ("ROMs") in and it will generally emulate it.

There's a lot of confusion about how generic this solution it. It's extremely impressive in how much work it saves making recompilations/"ports" much easier, and it will be very valuable. But it is not able to replace the need for traditional emulators.

[1]: https://cs.stackexchange.com/questions/155511/why-is-static-...

[2]: N64 game binaries may happen to avoid a bunch of things that make general static recompilation hard that help this approach, but I don't actually know.

[3]: The Majora's Mask recompilation repository contains a lot of handcrafted patches to make it work: https://github.com/Mr-Wiseguy/Zelda64Recomp

pjc504 hours ago

Emulating the hardware usually requires cycle-accurate emulation of things running in parallel, so it's not quite so simple as just the program in the ROM.

whizzter3 hours ago

Yes and no, with the 8bits and probably 16bits like the C64, NES, etc you really want cycle accuracy and emulating something like the PS2 really well would probably need a fair bit of accuracy.

HOWEVER.. writing an recompiler (not feasible for 8bits due to the amount of self-mod code) you could probably insert pattern checks to detect writes to DMA-starting locations,etc (thinking back to our PS2 games) and transform it to safe sequences without accurate timing for most games that really only would be happy with some extra cycles.

OnlyMortal3 hours ago

Good point about 8bit self modifying code.

The UK C64 disk for “Skate or Die” had copy protection that did exactly that, as an example.

kkukshtel3 hours ago

Watching the video, it seems like the explanation is mostly "tag the code and transpile to C" - im assuming the tags are acting as the hardware-aware part?

bluedino4 hours ago

Are they using self-modifying code or anything else that would make this tricky?

dividuum1 hour ago

Really surprised this topic didn't come up anywhere. I couldn't find anything in the linked repositories either. I guess there's no self-modifying code due to it being mapped into the address space from a cartridge?

izzydata5 hours ago

I hope this eventually also works for Linux so that N64 games can be reliably played on very low end portable handhelds. N64 is notoriously tricky to emulate, but building them for the platform natively removes all performance problems.

cpressland5 hours ago

I’m pretty sure Linux is natively supported via N64Recomp: https://github.com/Mr-Wiseguy/N64Recomp

An example of this can be found here: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...

jjice5 hours ago

> N64 is notoriously tricky to emulate

Huh, I wouldn't have expected that. I don't know much about the specifics of N64 emulation, but I've had N64 emulators running perfectly since the early 2010s. I played mostly the big classics, so I'm unfamiliar with more niche title performance.

LetsGetTechnicl4 hours ago

You'd be surprised, even Nintendo doesn't get it perfect themselves. When N64 games were first made available on the Nintendo Switch Online platform, there were several problems with graphical effects and input lag. Here's an MVG video from the time: https://www.youtube.com/watch?v=jSyBMSOfPxg

jjice3 hours ago

Haha I remember this launch and how awful it was an thinking about how a bunch of fans have done such a better job. Hell, even Nintendo did a better job for the Wii's Virtual Console.

0cf8612b2e1e4 hours ago

I think part of the issue is that some purists believe anything less than pixel perfect fidelity is unacceptable. I recall reading a report on N64(?) Wii(?) about how the flame flicker in one level of one game was off.

tempoponet4 hours ago

Any Dolphin progress report will be full of these one-off quirks with an exhaustive deep-dive on how the issue was diagnosed and solved.

Setting aside the part about purists finding it unacceptable, I appreciate the tenacity of the devs that find these problems worth solving.

jezzamon4 hours ago

Depends what you're trying to do, but some glitches used in speed runs literally depend on the exact values of pixels on the screen

https://youtu.be/0B095eHBrCg?t=24m40s

Not saying that supporting glitches like that is a hard requirement for these ports though

mrguyorama3 hours ago

The N64 had a fully unified memory architecture, and weird custom silicon that also happened to be a fully programmable GPU kinda device. For decades, all N64 emulation was done by translating calls to that GPU (called the RDP) to openGL or DirectX calls, and that works horribly, but anything else would have had awful performance. Several years ago however, someone decided "Fuck it" and created a fully emulated version of the RDP that you could run, ie feed it real N64 instructions and it spits out pixel values. It was significantly slower than the translation approach, so you had to have like a powerful 8 or more core CPU to run it well.

Some other madlad then took that approach, and ported it to a GPU Shader, because fuck yeah thousands of cores! It actually greatly improved the situation, as you didn't need a super powerful GPU, just a somewhat modern GPU.

That development means devices like the steam deck actually have zero issues running awesome N64 emulation, including allowing for upscaling to much higher rendering resolutions without artifacts because you are literally telling a virtual RDP to do it, and it happily complies.

Before AngryLion and ParaLLEl, we were stuck with basically the same graphics plugins, glitches, and tweaks as the late 90s.

https://www.libretro.com/index.php/category/parallel-n64/ for a more detailed description of how this changed things.

grecy4 hours ago

Many games were very playable with UltraHLE back in 1999, on the hardware of the time (~ Pentium 133 IIRC)

Fartmancer4 hours ago

I tried this out on my Ubuntu PC and it works great. Played it for around an hour without any issues.

vaughnegut5 hours ago

I watched the youtube video this article links to the other day and it mentioned that it supports Linux, specifically mentioning that it should be usable on Steam Deck.

izzydata4 hours ago

The steam deck has way more than enough resources to power through any and all N64 emulation so that wouldn't change much there. I'm specifically talking about something $50 retro handhelds and the like.

For example Mario64 and Ocarina of Time are completely reverse engineered and have native support for Windows and Linux and they run perfectly on those systems as where they really struggle when trying to emulate.

vundercind4 hours ago

I still get audio pops and glitches with whatever the default n64 emulator EmuDeck installs is, on many games. Be nice to eliminate that.

andrewclunn5 hours ago

That will likely require full decompilation. This is akin to wrapping the emulator up with the rom, with a few common functions (found via decompilation) being updated to support more modern rendering approaches. This isn't so much "native" as it is a patched container in an executable form.

EDIT - But hey, you can always just add another layer of emulation via Proton to run it in Linux.

GaggiX4 hours ago

I don't think that's true, it really does recompile the N64 games into native executables, you can compile them using any C compiler like msvc, gcc and clang.

pipes1 hour ago

As an aside, the perfect dark decompile port is really nice to play on the steam deck. Not sure why, but the Linux version tends to freeze on the villa level. Switching to the windows version and using proton works great.

https://github.com/fgsfdsfgs/perfect_dark

vouaobrasil4 hours ago

One thing this could be cool for is games like Goldeneye, which is hard to play on PC because it expects that weird joystick input. It would be awesome to have a native Goldeneye port with normal mouse behaviour like other FPSes.

whateveracct4 hours ago

WASD with mouse aim control doesn't really work with the game though.

The modal aspect of aiming combined with the travel time/return-to-center of the cursor is a really fun part of the game. If you could just free-aim while running a la PC FPS it would kind of ruin the campaign since everything is designed around this. Picking your spots and keeping cool while aiming are the appeal.

That said, if you keep the modal aspect and have the mouse just 1) rotate Bond like left/right on the stick does and 2) control the cursor only in "aim mode" (hit R)..then I think that could be fun.

Tbh, I wish shooters didn't go straight to Quake-style WASD+mouse free-aim across the board. The modal aspect makes gives Goldeneye a certain physicality I really like.

X0Refraction3 hours ago

Weirdly Goldeneye did have a control layout where you could move with one joystick and aim with the other using 2 controllers: https://www.youtube.com/watch?v=dZaEpugk3hY

GardenLetter272 hours ago

Yeah, it's awesome as you can set this up relatively easily with EmuDeck and play it with the two sticks on the Steam Deck.

anthk3 hours ago

Deus Ex has quake controls but you need to focus a little before aiming. Then, later you get upgrades and laser reticles allowing you to shoot near instantly.

AlecSchueler3 hours ago

You can turn off auto aim in the game though. Always the first thing I do.

terramex3 hours ago

There is emulator hack for Goldeneye that add WASD + mouse support and I heard that it works great.

https://github.com/Graslu/1964GEPD/releases/tag/latest

wodenokoto4 hours ago

Wouldn't it still expect a weird joystick?

haiku20774 hours ago

The native ports have additional features, which are easy to implement starting from the native compilation. For example, the native port of Zelda has gyro aiming and automatic autosave options.

vouaobrasil4 hours ago

Well I was hoping there'd be a way to translate mouse input into the joystick input in a straightforward way that isn't available on emulators.

haiku207738 minutes ago

It could be done with native mouse control. No joystick intermediate- instead modify the C code to allow direct control of the player character with a mouse.

ThrowawayTestr2 hours ago

The mouse+wasd hack works really well. Also works with Perfect Dark.

simple1054 minutes ago

Super impressive walkthrough video in the article. It does a great job of explaining Majora's Mask. Although, it's probably glossing over a lot of the upfront technical challenges of using it to port games.

djmips2 hours ago

What's the advantage over an emulator? This is after all, a form of an emulator - one where you translate ahead. This sort of thing has been done in the past with things like Bleem so it can be more performant but on a modern PC any good emulator is going to perform well.

https://en.wikipedia.org/wiki/Bleem!

skrrtww2 hours ago

The goals of this project and the goals of N64 emulation are fairly different.

The goal of N64 emulators (generally) is to accurately recreate the behavior of the original console.

Conversely, there is a large crowd of people who just want to play SM64, OOT and MM with a bevy of "graphical enhancements" like 60fps, widescreen, texture packs, randomizers, etc.

For these people, the fact that these games originally ran on the N64 is practically irrelevant. In fact, it's a hindrance; The N64's graphical pipeline is cumbersome to emulate and actively stands in the way of modern 'enhancements.'

This project is more aimed at giving the games themselves modern treatments, removing the N64-centric aspects of the games from the equation entirely.

wmf2 hours ago

JIT emulation can cause stutters while AOT should not. The difference may not be noticeable now that computers are so much faster than the N64.

doublepg232 hours ago

The video shows multiple bugs disappearing when using this method vs. emulation.

ThrowawayTestr2 hours ago

Recompilation is not emulation.

protoster5 hours ago

Do typical emulators compile ahead of time? Just-in-time? If not, why? This approach (ahead of time compilation) appears to have huge benefits.

chlorion9 minutes ago

There are lots of emulation methods but interpretation is probably(?) the most common or at least very common.

Interpretation involves writing a VM that represents the state of various parts of the machine, and executes instructions that change the state of the VM, with varying levels of accuracy.

jerf4 hours ago

You name the compilation and/or interpreter technique and there's at least one emulator that uses it.

ranger_danger5 hours ago

A fair amount of 32-bit and later emulators do have JIT recompilation, but I'm not aware of any ahead-of-time translation unless that's how TeknoParrot works (you can run linux arcade games that use ELF binaries on windows with it for example), but I wouldn't call that emulation either way since the architecture is the same.

entropicdrifter2 hours ago

Modern Vintage Gamer over on Youtube has worked with Nightdive and Limited Run Games and helped design a C recompiler called Carbon Engine for various older consoles that are functionally the same as ahead of time compiled emulators.

https://youtu.be/eZRzaGFWoz8?si=XQyJol0pe2z2oG6d

DrNosferatu2 hours ago

Any tutorials/step by step guide on why to use these tools and perform this from start to finish?

DrNosferatu2 hours ago

Any efforts for other platforms?

I would love to play a source-port of arcade “GTI Club”! <3

xnx4 hours ago

Would this recompilation technique be applicable to other systems (3DS, GameCube, Wii, etc.)?

naikrovek4 hours ago

In theory it will work for anything, but there is a LOT of work that must be done to annotate the binaries on the source platform so that tooling such as this can pull it apart and reassemble all the pieces into something that works on the target platform.

A straight recompilation is one thing, but what this tool does is recompile with the target system’s apis for input and output in mind. A straight recompilation would offer less than an emulator, really.

This tool knows (or is told) where rendering routines are, for example, so that they can be replaced with destination platform versions. That’s how higher resolutions and different aspect ratios are supported in a recombination.

ranger_danger5 hours ago

Jamulator did this for NES way back in 2013 but nobody really seemed to care...

https://andrewkelley.me/post/jamulator.html

There is also Winlator for running Windows programs on Android:

https://github.com/brunodev85/winlator

Also is the youtube video linked in the article using an AI voice?

claudex4 hours ago

>Jamulator did this for NES way back in 2013 but nobody really seemed to care...

At least Mr WiseGuy seems to care. From the N64Recom Github repo[0]: "This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."

[0]: https://github.com/Mr-Wiseguy/N64Recomp

BearOso4 hours ago

Jamulator was unsuccessful because so much extra hardware was on the cartridges. Recompilation complicates things and doesn't provide many benefits in that situation.

The N64 is fixed hardware, so it's a little bit easier. Even so, this project still uses emulation for the RDP. I don't know how it handles generated RSP microcode, maybe it doesn't. A lot of games just used the official libraries.

zamadatix3 hours ago

Jamulator didn't take it farther than what NES emulators could do beyond the way it ran. If Jamulator had released with similar enhancements for Zelda it probably would have been a lot more popular. I.e. the interest is more from what is now available with it than about how it does it.

That's just Nerrel, a real person, narrating. It's crazy (in an interesting way, not necessarily a doom and gloom way) how we have AI voices these days so good we start to suspect people who don't speak like we expect are AI.

refracture3 hours ago

That's just Nerrel; his narration is so flat that he's always sounded like an AI. I enjoy that mix with his humor.

deadbabe2 hours ago

Would love to play fully ray traced N64 games.

anthk3 hours ago

I'd love to see this with THPS2 and 3, some games I love but not with the 'modern' graphics (PSP/DC and up).

nottorp3 hours ago

Isn't Nintendo hunting every one of their fans^H^H^H^H IP abusers with their black helicopters?

Why do people even bother when they know they'll get lawyers at their door in 3... 2... 1... ?

kotaKat3 hours ago

Because a few of them will turn and go take a job offer from NERD.

https://www.nerd.nintendo.com/files/Secu%20Job%20Offer%20202...

yamazakiwi2 hours ago

Nintendo isn't as hard on tracking people emulating older systems, emulating their most modern system is where they start to get particularly whiny.

babypuncher2 hours ago

Nintendo doesn't typically go after emulation projects. Yuzu was the exception, and there are reasons for that related to how the Yuzu team ran their project and distributed it that painted a legal target on their back.

This project isn't distributing any of Nintendo's code, game assets, or other intellectual property.