# Goldeneye 007: reconstructing the N64 ROM from C source

> The n64decomp Goldeneye 007 project is a work in progress decompilation that rebuilds the N64 game from reconstructed C source, matching the original ROMs byte for byte for the US, Japanese and European releases. It is a research and preservation project built around the original SGI IDO compiler and a Makefile that verifies its output.

**n64decomp/007** — A decompilation of Goldeneye 007 brought to you by a bunch of clever folks. (MIRROR of https://gitlab.com/kholdfuzion/goldeneye_src)

- Repository: https://github.com/n64decomp/007
- Stars: 804 · Forks: 92
- Language: C
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/n64decomp-007

## What a decompilation project reconstructs

The repository describes itself as a WIP decompilation of Goldeneye 007, brought to you by a bunch of clever folks, and it is a mirror of the upstream project hosted on GitLab at kholdfuzion/goldeneye_src.

The idea of a decompilation is worth understanding before the tooling, because it explains why the project is shaped the way it is. The goal is not to reverse engineer the behaviour of the game and write new code that behaves the same way. The goal is to reconstruct source code that, when compiled with the same compiler and the same settings, produces a byte identical ROM. That is a much harder constraint and a much more useful result, because a byte identical build proves that the understanding of the original program is complete rather than approximate.

The language is C, which is what the original game was written in, and the code lives under src/ with headers under include/.

The project publishes a status badge for each of the three regional releases, NTSC, Japanese and PAL, each linking to its own page on the goldeneyestatus site. Those badges are the honest progress indicator for the project: they say, per region, how close the reconstruction is to matching the original ROM.

The audience is preservationists, people learning how a 1997 game was actually built, and the decompilation community in general, where a project like this is treated as a serious reverse engineering exercise.

## Three regional ROMs and the SHA-1 that proves the match

The build targets three separate ROMs, and the repository lists the expected SHA-1 of each:

* ge007.u.z64 with sha1 abe01e4aeb033b6c0836819f549c791b26cfde83
* ge007.j.z64 with sha1 2a5dade32f7fad6c73c659d2026994632c1b3174
* ge007.e.z64 with sha1 167c3c433dec1f1eb921736f7d53fac8cb45ee31

The tree holds the same three digests as separate files, ge007.u.sha1, ge007.j.sha1 and ge007.e.sha1, so the check is a file comparison rather than a copy and paste into a terminal. There is also a ge007.ld file, which is the linker script, and an imagelist.u.csv for the US region.

The comparison is built into the build itself. The Makefile has a COMPARE option, set to 1 by default, described as checking the output sha1sum when building all, and if it fails to match then comparing ELF sections to known md5 checksums. So a successful build is a verified build, and a mismatch does not stop at a checksum failure but escalates into a section level comparison that tells you which part of the ROM is wrong.

That escalation matters more than it sounds. A checksum tells you that you are wrong; a section comparison tells you which function or data block is wrong, which is the difference between a debugging session and a guessing game.

## The IDO compiler, qemu-irix and the toolchain probe

Matching a ROM byte for byte means matching the original compiler, and the original compiler for Nintendo 64 was the SGI IDO compiler, which ran on IRIX, a Unix variant that no longer exists on any current machine. The project handles that in two ways.

The first is a recompiled build of the compiler. The Makefile sets IDO_RECOMP to YES by default, and in that case the compiler lives in the tree at tools/ido5.3_recomp, so the build uses a locally built compiler rather than the original binaries.

The second is emulation. If IDO_RECOMP is set to NO, the build expects qemu-irix, the IRIX emulator, and errors out with a clear message if it is missing: using the IDO compiler requires qemu-irix, and you may install the package or set the QEMU_IRIX environment variable to the full path of the binary. In that mode the IRIX_ROOT points at tools/irix/root.

The container image takes the same two paths. The Dockerfile installs qemu-irix by downloading a specific Debian package, qemu-irix-2.11.0-2169-g32ab296eef_amd64.deb from the n64decomp/qemu-irix releases, and installing it with dpkg. The comment in the Dockerfile says to comment out the qemu installation if you are using ido recomp, which is the same choice expressed as a build option.

On the host side, the Makefile probes for the cross toolchain. It checks whether mips-linux-gnu-ld exists and uses the mips-linux-gnu- prefix, otherwise whether mips64-linux-gnu-ld exists and uses that prefix, and otherwise falls back to mips64-elf-. The binutils-mips-linux-gnu package is installed in the container for exactly this reason.

## Compression tools, checksum tooling and the AI print workaround

The Makefile shows more of the build than the compiler, and three parts of it are worth noting.

First, the compression and checksum tooling lives in tools/ and is invoked by name. DATASEG_COMP points at tools/data_compress.sh, RZ_COMP points at tools/1172compress.sh, and N64CKSUM points at the tools/n64cksum binary. The N64 format stores some data compressed in a specific way, and matching the original bytes means using the same compressor, so those scripts are part of the correctness story rather than a convenience.

Second, the checksum command follows the verbosity setting. With VERBOSE set to 1 the build calls sha1sum, and otherwise it calls sha1sum with the quiet flag. The default VERBOSE is 2, and the default FINAL is YES, with VERSION set to US. The terminal output is also handled through included makefiles, include/make/VT100Codes.make for colourising text and include/make/Gui.make for the interface.

Third, there is a piece of source level automation. The Makefile defines a ConvertAIPRINT variable built from a sed expression whose comment says it converts AI Print commands from readable strings to byte arrays automatically. The original game prints debug text through a call whose arguments are byte arrays, and reconstructing that by hand in the source would be miserable, so the build rewrites the readable form. It is the kind of detail that only appears once you read a decompilation Makefile closely, and it explains why the sed expressions are there at all.

## The container: ubuntu 22.04 with the project mounted

Building this needs a specific and rather old toolchain environment, so the project ships a container definition that provides it.

The base image is ubuntu:22.04:

```dockerfile
FROM ubuntu:22.04
```

The distribution packages installed are deliberately few and specific, including the cross binutils:

```dockerfile
    apt -y install bash-completion sudo binutils-mips-linux-gnu wget make git python3 build-essential
```

The image then installs qemu-irix as described, and sets up a workspace. It adds a passwordless sudo rule for the dev user, creates that user with a bash shell, switches to it, and sets the working directory to /home/dev/project. The container's default command is an interactive bash shell rather than a build, which tells you the expectation is that you work inside the container and invoke the build yourself.

The Compose file wires that up. The single service is named ge007, it builds from the local context with the repository Dockerfile, it mounts the whole project into /home/dev/project, it sets the hostname to ge007, it keeps a tty so the interactive shell works, and it uses restart unless-stopped so the container comes back after a reboot.

The allbuild.sh script at the repository root is the other entry point for people who would rather build on the host with the toolchain already installed.

## Repository layout and the three guides

The tree is organised the way a decompilation project usually is, with the reconstructed game separated from the tooling and from the assets.

There are src/ and include/ for the C source being reconstructed, ld/ for the linker script, rsp/ for the response files that tell the compiler how to build each object, assets/ for the extracted assets, scripts/ for helper scripts, tools/ for the toolchain and the compression helpers, and docs/ for the guides. The root also carries a .clang-format, an .editorconfig and a CppProperties.json, which is a Visual Studio configuration file and suggests the project is expected to be browsable and editable in an IDE as well as from a terminal.

Three guides live in docs/ and they define who the project is for. The Setup Guide covers installing the necessary dependencies and how to use the project, the Structure Guide explains the structure of the repository, and the Style Guide documents the code style conventions for anyone contributing code. The presence of a Style Guide at this level of detail is a good sign about how the project intends to receive patches, since a decompilation is only maintainable if contributions match the original style closely.

The Makefile, the allbuild.sh script and the Docker setup cover the other half of the story, which is that a matching build is a toolchain problem as much as a code problem.

## Where this project is the wrong tool

Three points to be clear about before anyone clones it.

The first is that this is not a way to obtain the game. The README states plainly that the repository does not include all assets necessary for compiling the ROMs and that a prior copy of the game is required to extract the assets. The code and the tooling are here; the art, audio and other data are not, and you are expected to extract them from a copy you already own.

The second is that it is a work in progress, and the per region badges say so. A build that does not match its checksum is the normal state of a decompilation at any given moment, so if your goal is a playable or matching binary today, this is not it. The comparison mode exists precisely so that the mismatch is reported rather than hidden.

The third is the platform requirement. The build wants an IRIX environment or the recompiled IDO compiler, a MIPS cross toolchain, and specific compression tools, and the container exists to make that reproducible. On a machine without Docker and without the cross toolchain, the first build is a setup project of its own.

There is also a question of where the canonical history lives. This repository is a mirror of the GitLab project, the licence is not recorded here, and the release history in the GitHub repository is empty, so anyone contributing should follow the upstream contribution route rather than treating the mirror as the source of truth.

## Conclusion

Adopt this project if you are interested in game preservation, in matching a N64 build byte for byte, or in the mechanics of the IDO toolchain and the decompilation workflow itself, and if you can obtain your own copy of the game to extract the assets the repository does not include. Do not adopt it as a source of the game itself, since the assets are not in the tree and must be extracted from a prior copy, and do not expect a finished product, since the repository describes itself as a work in progress. Verify three things first: the region whose status you care about, because the NTSC, Japanese and PAL badges track separate pages and separate build targets; that the toolchain the Makefile selects matches your host, since it probes for mips-linux-gnu-ld and mips64-linux-gnu-ld before falling back to mips64-elf-; and that the comparison mode is enabled so a mismatched build is reported rather than silently accepted. The licence is not recorded for the repository, the last push was on 2026-08-17, and the upstream project lives on GitLab with this repository as a mirror.

## FAQ

### What is the n64decomp Goldeneye 007 project?

It is a work in progress decompilation of Goldeneye 007 that rebuilds the N64 game from reconstructed C source, with the goal of producing ROMs identical to the originals. Status badges track the NTSC, Japanese and PAL regions separately.

### Do I need a copy of the game to build the ROMs?

Yes. The README states that the repository does not include all assets necessary for compiling the ROMs and that a prior copy of the game is required to extract the assets.

### How does the build verify that it matches the original ROM?

The Makefile has a COMPARE option, enabled by default, that checks the output sha1sum against the expected digests stored in ge007.u.sha1, ge007.j.sha1 and ge007.e.sha1. If the sums do not match, it compares ELF sections against known md5 checksums.

### What compiler does the project use and why?

The original SGI IDO compiler, which ran on IRIX. The Makefile defaults to IDO_RECOMP, using a local recompiled build in tools/ido5.3_recomp, and otherwise requires qemu-irix, with the QEMU_IRIX environment variable as the way to point at the binary. The Docker image installs a specific qemu-irix Debian package.

### How do I build the project?

Use the container, with docker compose, which builds from the repository Dockerfile, mounts the project into /home/dev/project and opens an interactive shell, then run the build from the Makefile or the allbuild.sh script. The Makefile also probes the host for mips-linux-gnu-ld or mips64-linux-gnu-ld and falls back to mips64-elf-.

## Sources

- [Issues](https://github.com/n64decomp/007/issues)
- [n64decomp/007 on GitHub](https://github.com/n64decomp/007)
- [README](https://github.com/n64decomp/007/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/n64decomp-007