ssb-decomp-re

What the decompilation project is

This repository is a decompilation of the original Super Smash Bros. for the Nintendo 64. The README presents it as a smashin' decompilation, a playful phrasing for the work of turning the shipped game back into readable C source. The project uses the decomp.dev progress tracker, with shields for code and data completion. The primary language is C, and the license is not specified in the metadata. The goal of a decompilation is to produce source code that, when compiled, matches the original game binary. The README links to a list of remaining functions that still need to be rewritten, so contributors can see exactly where help is needed. This is a common structure for console decompilation projects: a community fills in functions until the rebuilt ROM matches the original. By publishing the work, the project lets anyone study how the game was built, mod it, or learn from a real world reverse engineering effort. The README's tone is inviting to new contributors who want a concrete task. The decomp.dev shields give a public measure of how close the project is to a perfect match, which helps a newcomer gauge the current state before cloning the repository. The information above is drawn from the project README and its repository metadata, which remain the source for the project's current behaviour. The build requires a user supplied baserom.us.z64 and the splat YAML files smashbrothers.us.yaml or smashbrothers.jp.yaml. A reader who wants exact commands or file names should open the repository and read the documentation the maintainers provide.

Setting up the build environment

The README gives precise setup steps. Two hashes identify the expected ROM: SHA1 e2929e10fccc0aa84e5776227e798abc07cedabf and MD5 f7c52568a31aadf26e14dc2b6416b2ed. To get the code, run git clone with the single branch flag set to main and the repository URL. After cloning, run bash ./installDependencies.sh to install dependencies. The script also tells you where to place the ROM if it is not already in the right spot. The required location is the repository root, in a file named baserom.us.z64. Having the ROM there is required before you can run make extract, which pulls assembly and assets out of the ROM. The README is explicit that the base ROM must be supplied by the user, since the project does not distribute the game itself. These steps form a fixed order: clone, install dependencies, place the ROM, then extract. The README's instruction to use the single branch clone keeps the working tree focused on main, avoiding the extra history that a full clone would pull. This small flag matters for contributors who only need the current build state. The information above is drawn from the project README and its repository metadata, which remain the source for the project's current behaviour. The build requires a user supplied baserom.us.z64 and the splat YAML files smashbrothers.us.yaml or smashbrothers.jp.yaml. A reader who wants exact commands or file names should open the repository and read the documentation the maintainers provide.

Extracting and building the ROM

With the ROM in place, the README says to run make init, or alternatively make clean and then make extract and make. Extraction must be repeated whenever the splat YAML file changes. The project uses smashbrothers.us.yaml for the US version or smashbrothers.jp.yaml for the Japan version. Extraction also depends on anything inside the symbols folder, because splat reads those files. The README therefore recommends running make init after every pull, since upstream changes to the YAML or symbols will otherwise leave your build out of date. To build the ROM, run make, or make with parallel jobs using nproc for speed. On macOS, the README notes that MIPS binutils and GNU make can be obtained from MacPorts. These commands turn the extracted assets and the C source into a rebuilt ROM that should match the original when functions are correct. The warning to re extract after editing the YAML or symbols is a practical detail that prevents confusing build errors. It reflects how tightly the build depends on the splat configuration staying in sync with the source. The information above is drawn from the project README and its repository metadata, which remain the source for the project's current behaviour. The build requires a user supplied baserom.us.z64 and the splat YAML files smashbrothers.us.yaml or smashbrothers.jp.yaml. A reader who wants exact commands or file names should open the repository and read the documentation the maintainers provide.

Debugging non matching functions

The README describes a few handy scripts for debugging functions that do not yet match the original. One tool listed is first_diff.py, which helps locate the first difference between the original and rebuilt assembly. The table in the README shows the tool name on the left and details on the right, though the visible text stops after the first entry. The purpose of these scripts is to narrow down why a recreated function produces different output than the game's original code. In a decompilation, a non matching function means the rebuilt binary differs from the target, so contributors use diff tools to find the exact instruction or value that diverges. The README presents these scripts as part of the normal workflow rather than an extra. By including them, the project gives contributors a path from a failed build to a specific fix, which keeps progress moving one function at a time. The emphasis on small debugging helpers fits the incremental nature of decompilation, where success is measured function by function rather than in one large step. The information above is drawn from the project README and its repository metadata, which remain the source for the project's current behaviour. The build requires a user supplied baserom.us.z64 and the splat YAML files smashbrothers.us.yaml or smashbrothers.jp.yaml. A reader who wants exact commands or file names should open the repository and read the documentation the maintainers provide.

Editorial conclusion

The decompilation targets the US and JP ROMs via splat YAML files and requires a user supplied baserom.us.z64 with SHA1 e2929e10fccc0aa84e5776227e798abc07cedabf.