Interested in learning more about the the N64? Excellent! This section will guide you through the basics, starting from basic MIPS assembly language all the way to an introduction to reverse engineering your first game!
When it comes to finding a game to reverse engineer it can be helpful to look at games that are cross-platform to compare builds. But the most valuable reverse engineering projects tend to be the platform exclusives as these are games people can no longer play on modern consoles.
Although most Nintendo 64 games are written in C or C++, they all get compiled down to MIPS assembly code, so this is what you will mainly be working with when reverse engineering, so it is good to at least have a basic knowledge before getting started.
We recommend using the
Reversers Edition of the Mupen64+ emulator as it provides useful features for reverse engineering such as auto detection of functions.
The Nintendo 64 has some of the most beloved video game soundtracks with classics such as Banjo-Kazooie, Buck Bumble, Super Mario 64 and many more.
Every game produced for the N64 required a little piece of code known as the “bootloader” or boot code to initialise the state of the console. You don’t have to know anything about this, apart from that it exists and tends to execute in the address space
There are a couple of different types of reverse engineering when it comes to Nintendo 64 games, these are listed in the sections below.
The goal of a partial game reversing project is to understand and document how games “work”, for example how did the developers implement the characters animation or jump mechanics. This can be beneficial for game developers and anyone who is interested in how games are made, they can also be beneficial for speed runners due to the better understanding of how to exploit the game.
The output of this type of project is normally documentation which goes in detail on how a specific game feature works.
Recently there has been a growing interest in reversing Nintendo 64 games back to source code that when compiled is binary-compatible with the original ROM.
These projects take a very long time but in the end are hugely rewarding, they result in full source code that can be compiled and even ported to other hardware.
With the source code available it is trivial to understand how the game works and can be the basis for future game mods that are many times more complex.
Unlike a full game reversal project a Mod goes in the opposite direction by changing the original game to add new levels, textures, music and even alter the games code and physics engine.
The Game Modding category also includes translation patches to convert the game’s text to another language, which can bring many region-exclusive games to a world-wide audience.
Whether you just want to get further in your favourite game, unlock hidden content or even completely corrupt/glitch the game, you can use a cheat cartridge such as Action Replay or emulator memory editing to change games in real-time.
The main Nintendo 64 anti-piracy measure was the enhanced
CIC chip based on the Super Nintendos CIC chip design but far more secure.
This was a mechanism to prevent cartridges being produced without Nintendo’s licensing fee.
During the N64’s lifetime there were various unlicensed devices that ignored the CIC chip such as game backup devices (e.g Bung’s Dr V64), game cheat cartridges (e.g Equalizer/Action Replay) and region unlockers (Passport Plus). Most required a legitimate cartridge to be inserted into the back and used that for the CIC chip communication.
During its lifetime the Nintendo 64 had its share of piracy problems, although no where near the extend of its competitor the Sony Playstation it was still possible to backup and run backup games via hardware such as the Doctor V64.
Development kits are released to game developers before the launch of the system to allow games to be developed for the system’s launch. These systems would evolve over the systems lifespan and contained useful features for debugging and optimising games for the platform. These systems were not just limited to the official offerings by Nintendo as a few other publishers had their own versions of development hardware.
The official development kit for the N64 was a partnership between SGI and Intelligent Systems and the hardware evolved over time. The first development kit released was a modified
SGI ONYX provided by SGI and contained similar hardware to the final N64.
There were a few third party developers who created their own custom development kits for the Nintendo 64. One of the main developers for 3rd party devkits was SN Systems with their Maestro64 aimed at 3D and Sound artists and with a much cheaper price tag than an official N64 devkit.
A version of the Nintendo 64 SDK was released on the internet allowing you to use the same tools that your favourite developer used back-in-the-day. This can be useful if you are aiming for a 100% accurate decompilation of a game that can be compiled to the byte-identical ROM.
When the N64 was launched it was the most powerful game console on the market and brought incredible processing power into the home. The hardware was state of the art and exploring how it was developed is a fascinating topic.
The Console itself was built by a partnership between Nintendo and SGI and contained a 64-bit MIPS CPU along with a custom chip known as the
Reality Co-Processor which handled graphics and vector calculations along with a few other functions.
The N64 controller was a very distinctive shape, some people loved it and others hated it, but we can all agree it was a unique experience. If you are interested in how the controller hardware works then check out this excellent article by HowStuffWorks Controller - How N64 Works | HowStuffWorks
Nintendo made the controversial decision to continue using cartridges for its next-gen console after the Super Nintendo, this has the b of excellent loading times compared to CDs but came at the cost of a smaller capacity and higher cost to produce.
Up until very recently there has been little official N64 source code released, just a few examples that come with the released SDKs. This changed very suddenly when 2 retail games had their source code leaked at roughly the same time, these games were
Turok - Dinosaur Hunter and
Mortal Kombat 64.
Studying the source code for these games can give vital insight into what it was like developing games back in the mid to late 90s when the Nintendo 64 was at the cutting-edge. The information gained from this can be very useful to help you reverse engineer the games back into retail-like source code.
There are some fantastic open source projects in the Nintendo 64 homebrew community, these range from tech demos to full games and everything in between. One excellent example of source code provided by the homebrew community is Peter Lemon’s N64 Bare Metal Mips programming examples: PeterLemon/N64: N64 Bare Metal Mips Assembly Programming
One of the best ways to learn how the Nintendo 64 worked is to take a look inside the source code of an emulator, by modifying it and seeing the results on your favourite games you can start to understand why it worked the way it did.
Read all about Datel Action Replay Professional (N64) in this s...
Read all about Mupen64+ Emulator Source Code Analysis in this s...
Read all about Mystical Ninja N64 Memory Rom Editing in this s...
Read all about N64 Rom Memory Hacking (Paper Mario) in this s...
Read all about Official Nintendo 64 (Ultra 64) Development Kit Hardware in this s...
Read all about Turok 64 Official Source Code Analysis in this s...
Read all about Official N64 SDK Setup (MacOSX/Linux/Win) in this s...