Donkey Kong 64's PC Port Quietly Ships an ARM64 Build. Nobody Mentioned It.

2026-09-18 · News and analysis

Affiliate disclosure: This guide contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.

Donkey Kong 64 got a native PC port at the end of August, and the coverage all landed in the same place. Ultrawide support. Uncapped frame rates. Extended draw distance. No AI code.

All true, all worth having. But every one of those write ups was tested on a desktop, and so every one of them skipped the line on the release page that matters most if you game on a handheld.

DK64 Rekongpiled ships an official Linux ARM64 build.

That is rare enough to be worth an article on its own. Most recompilation projects target x86 and stop there, which is exactly why we had to write a whole guide explaining that Android and ARM handhelds mostly miss out on this scene.

The Short Version

• What it is: a native PC port of Donkey Kong 64, built with N64Recomp
• Released: version 1.0.0 on 29 August 2026, with 1.0.1 the same day
• Current version: 1.0.2, released 2 September 2026
• Builds shipped: Windows, Linux x64, Linux ARM64, macOS ARM64, and a Flatpak
• Who made it: Rainchus, Ballaam, Killklli, 2dos and Umedtakes, the team behind the DK64 Randomizer
• AI policy: the team has been explicit that no AI coding tools were used
• What you supply: a US ROM of Donkey Kong 64, dumped from your own cartridge
• Not in PortMaster: the project distributes its ARM64 build itself

Why the ARM64 Build Is the Story

Static recompilation translates a game's original machine code into C. That C then gets compiled, and compiling is where architecture becomes destiny.

Your PC, your Steam Deck and every Windows handheld run x86-64. Android handhelds, Anbernic Linux devices, Retroid, AYN and the rest run ARM64. These are different instruction sets. A build for one will not run on the other, and no settings toggle fixes it.

So somebody has to deliberately produce the ARM build, test it and keep maintaining it. On a volunteer hobby project that is a real cost, and most teams reasonably decline. They have PCs. Their testers have PCs.

The DK64 team built it anyway. On a list where most entries are Windows and Linux x86 only, that is a genuine outlier.

What It Does Not Mean

Here is where we have to be careful, because "ARM64 build exists" gets read as "runs on my Anbernic" and those are not the same claim.

An ARM64 binary will not launch on a device that cannot supply what it needs. DK64 Rekongpiled is a full 3D N64 game rendered at modern resolutions with extended draw distance. The binary being the right architecture is a necessary condition, not a sufficient one. Your handheld still needs the GPU, the memory and a Linux environment the binary can actually run in.

Realistically this build is aimed at capable ARM Linux devices, not at a forty dollar handheld. Do not buy an RG28XX expecting this.

It is also not in PortMaster, which is where most ARM handheld users would expect to find something like this. The project ships the ARM64 binary from its own releases page. That means no automated per-device packaging, and no PortMaster compatibility list to check. You are on your own for setup.

If you want decomp and recomp ports that are properly packaged for cheap ARM handhelds, the ten that are actually in PortMaster are the better starting point.

Recompilation, Not Decompilation

Worth being precise about this, because the two words get swapped constantly and the difference explains why this port arrived when it did.

A decompilation reconstructs human readable source code from a shipped binary. It is enormous manual work, often years of it, and Donkey Kong 64 does not have a finished one.

A recompilation skips that. N64Recomp takes the original machine code and mechanically translates it into C without anybody needing to understand what the code means. You get a native executable without a decomp ever existing.

That is why DK64 could be ported now. Nobody waited for a decompilation, because static recompilation does not need one. Our decomp vs recomp explainer covers the trade offs, and the short version is that recomps arrive faster while decomps give modders deeper access.

What Landed in 1.0.2

The 2 September update is small but tells you the project is being actively maintained rather than dumped and abandoned.

Camera response was improved for analog sticks. Draw distance was extended for some actors, and specifically disabled for melon crates where it looked wrong. First person inversion now applies to gyro and mouse aiming as well as sticks. Audio engine stability was improved, and a batch of rendering and interpolation bugs were fixed.

The more interesting additions are for modders. Three new events were added to the modding API, covering map load, EEPROM load and asset file override. That is groundwork for texture packs and larger mods rather than anything you notice while playing.

The ROM Requirement

The project ships no game content. You supply a US ROM of Donkey Kong 64, dumped from a cartridge you own.

That is not a formality the team added to be safe. Recompilation output contains the translated code structure, but the game's assets were never in the project to begin with. Without your own ROM there is nothing to render.

We do not link ROM sources and we are not going to. If you own the cartridge, dumping hardware exists. If you do not own it, this port is not for you.

The AI Angle

You will see "zero AI code" in most headlines about this release, and it is not marketing copy. It is a position the team took deliberately, and loudly, because a competing DK64 recompilation was being generated with AI tools.

That fight is a bigger story than this port, and it is reshaping how the whole scene presents itself. We cover it separately in the recomp scene's AI problem.

What to Play It On

On the x86 side this is straightforward. Any modern PC runs it, and the

is the obvious handheld pick, with a Linux x64 build and a Flatpak both available.

On the ARM side, aim high rather than low. A

class device is the sensible target if you want to experiment with the ARM64 binary, and you should treat it as an experiment rather than a supported configuration.

Questions People Ask

Does DK64 Rekongpiled run on Android handhelds?

Not as shipped. The ARM64 build is a Linux binary, and Android is not a Linux desktop environment. Some ARM Linux handhelds can run it, but the project publishes no compatibility list and offers no Android package.

Is this on PortMaster?

No. The project distributes its own builds, including the ARM64 one. That means no per-device packaging and no PortMaster compatibility data to check before you try it.

Do I need a decompilation of DK64 for this?

No, and one does not exist. This is a static recompilation built with N64Recomp, which translates the original machine code directly and never needs a decompilation as an input.

Which ROM region does it need?

A US ROM. The project states it works only with the US version, and you are expected to dump it from your own cartridge.

Is it finished?

Version 1.0.2 is a full release rather than a beta, and it is still receiving updates. The 1.0.2 changelog is mostly bug fixes plus new modding API events.

Was AI used to make it?

No. The team has stated clearly that no AI coding tools were involved, and made that stance public partly in response to a rival AI generated DK64 port.

Related Reading

• The Recomp Scene's AI Problem
• Every Decomp Port You Can Play on a Cheap ARM Handheld
• Decomp vs Recomp: How Old Games Become PC Ports
• N64 Recompiled Games List
• Can Android Handhelds Run Recompiled Games?
• Recompiled Games List: Every Native PC Port by System
• Mario Kart Wiicompiled: The First Wii Recomp

Version numbers, release dates and the build list come from the project's own GitHub release data, retrieved 18 September 2026. No ARM handheld testing was performed for this article, and no per-device performance claims are made.