I’m very pleased to announce that the original Snowboard Kids is now 100% decompiled! This means that all functions ^{have matching C implementations that, when compiled, produce identical machine code to the original game.}

This was obviously not a one-person effort. I am particularly grateful to inspectredc, Bl00D4NGEL, and queueRAM for their significant contributions to the project. No amount of AI would have been able to replace them. ^{I would also like to thank iFuzzle, JamesBLewis, and douglasjv for lending their tokens to the cause.}

My hope is that a full decompilation will prove useful to the Snowboard Kids community. Speedrunners in particular have long focused on the first game. Working source code can help shed light on externally observed phenomena such as CPU pathing and the exact factors contributing to player speed. A full understanding of the source code will also be useful for static recompilation and more ambitious modding efforts in the future.

The speed at which the project was finished is also noteworthy. Snowboard Kids took only 84 days to decompile compared with 596 days for Snowboard Kids 2, roughly one-seventh of the elapsed time.

Weekly progress of the Snowboard Kids decompilation.

What explains this difference? Well, it’s 2026, so the answer is at least partially AI. But it would be a gross oversimplification to attribute the difference entirely to LLMs.

What Was Different

To state the obvious, I was not starting from scratch. By this point I had already spent nearly two years on a similar project and was vastly faster than when I began. This advantage is difficult to quantify and was somewhat offset by new challenges such as working with a different compiler.

Overall, roughly 4.8% of matching commits involved expert intervention. ^{I have already credited these amazing people once, but it’s worth reiterating. This project would not have been possible without significant help from the decompilation community, particularly inspectredc, queueRAM, and Bl00D4NGEL <3.}

The difficulty generally didn’t come from trying to understand what a function did ^{but rather how that logic was expressed in C and how the resulting code was compiled. Snowboard Kids was compiled with IDO 5.3 rather than the GCC 2.7.2 compiler used by Snowboard Kids 2.}

Most programmers will be familiar with GCC. It is a widely used open-source compiler still in active development today. IDO, on the other hand, was a proprietary compiler developed by SGI, whose own story is closely entwined with that of the Nintendo 64. ^{Its source was not available, and its original development environment was tied to obsolete SGI hardware and software. To use and properly understand it today, the decompilation community has had to reverse-engineer and decompile parts of the compiler toolchain as well as statically recompile the IDO 5.3 and 7.1 suites to run on modern hardware. That closed history makes IDO harder to reason about than an open compiler such as GCC.}

IDO splits optimisation and code generation across several different passes, transforming code quite aggressively along the way. ^{Tiny changes to the C can then ripple through those passes and produce a completely different register allocation.}

The community has made great strides in understanding IDO and its quirks, but this remains more of an art than a science. LLMs and I are not particularly good at reproducing its output. The usual workflow, for both me and the agents, was to figure out what a function did and then write C that approximated that purpose. From there, small tweaks assisted by the permuter could catch any remaining differences. But you can’t permute yourself into a match in all cases, particularly when the underlying structure is wrong. IDO’s behaviour made this workflow far less predictable.

A motivated human team with the right expertise and intuition can match or even exceed the pace of the Snowboard Kids decompilation. The Pilotwings 64 decompilation was completed in only 74 days. ^{Pilotwings 64 had 16% fewer functions than Snowboard Kids, but more compiled code overall, so this is not a clean comparison either.}

Pilotwings 64, a charming flight simulator, was a Nintendo 64 launch title and remains a cult classic to this day.

Snowboard Kids was also smaller than its sequel, containing 2,145 functions compared with 2,995 in Snowboard Kids 2. Function count is a crude measure of difficulty, but there were simply fewer functions to decompile.

Where Agents Did Help

I’ve already written elsewhere about using agents to decompile functions. The same basic process was used here, so I’ll focus on what changed. Unlike the previous project, this one began with access to frontier models and a capable agent harness.

Library Code and Other Low-Hanging Fruit

I was interested to see how agents would fare during the early stages of a project. One area where they thrived was matching standard-library code. In theory, this is the most obvious chunk of almost any Nintendo 64 decompilation. The code is not unique to the game, and versions of it are available online. Snowboard Kids contains more than a hundred source segments from Nintendo’s libultra, alongside functions from the libmus audio library. Tools such as N64Sym can identify probable library functions in the ROM.

This pass was fairly successful. The main stumbling block was convincing agents to rely on the existing library source rather than decompile the same functions again from scratch. This required stronger prompting. Once a likely library function was identified, agents were instructed to treat the corresponding source as their starting point and exhaust plausible SDK versions, compiler options, and conditional compilation paths before attempting their own implementation.

Another optimisation was to have an agent write a script that ran m2c against every unmatched function and automatically integrated any exact matches, rather than relying on agents to attempt those functions individually. ^{The script matched only 17 of 1,830 functions, an incredibly low success rate of 0.93%, but anything matched this way was cheaper than burning agent tokens.}

IDO Tooling and Skills

IDO is weird, but it is often weird in recurring ways. Successfully matching one function could reveal a compiler quirk that applied to many others. Codex has become better at carrying lessons between tasks through features such as local memories. To make those lessons available beyond a single agent, I prompted agents to record observed IDO behaviour in a DECOMPILATION_LEARNINGS.md file. When an agent discovered a generalisable compiler quirk, it could record the evidence there for later attempts. This created a useful feedback loop. Agents helped document IDO, and the resulting documentation made subsequent agents better at matching IDO code.

But the most useful resource was N64 Decomp Workbench, a collection of tooling and documentation for debugging late-stage MIPS decompilation mismatches. It can classify mismatches, account for relocations, replay individual compiler passes, and help distinguish a structural problem from a register-allocation problem. Pass replay requires the relevant compiler binaries and project-specific setup, but once configured it exposes information that a raw assembly diff cannot. A raw diff tells you that two functions differ. The Workbench can give agents a much better idea of why the functions differ and what sort of change might fix them.

Worktrees and Synchronisation

For this project, I ran the decompilation harness across four Git worktrees. Each worktree gave an agent an independent copy of the repository, allowing several functions to be attempted in parallel.

One small but useful improvement was to give every task an explicit deadline and expose that deadline to the agent. During the Snowboard Kids 2 project, agents often struggled to use the permuter effectively because it would continue running until it found a 100% match or was manually stopped. An explicit deadline allowed agents to set sensible timeouts and trade off permuting time against other forms of problem-solving. Anecdotally, it also helped them judge how long to keep working on a difficult function before giving up. I could then increase the time allowance as the easy functions disappeared and the remaining work became more difficult.

Another problem that had existed in Snowboard Kids 2 but became more apparent as I added worktrees was synchronisation. As discussed in my previous post, each agent was given a function to decompile alongside a set of similar functions that had already been matched. These provided useful reference points for reproducing particular IDO instruction patterns. Work was divided between the worktrees using Nigel’s --shard option, which uses basic hashing to partition candidates between a specified number of workers.

This allowed more work to happen in parallel without duplication, but introduced a new problem as the worktrees diverged. One worktree, for example, might successfully decompile a function that was 99% similar to a function being attempted elsewhere, but that new reference would remain invisible to the other agent until the changes were merged. Periodically merging everything into the main branch and resynchronising the worktrees fixed this, but synchronising all four could take more than an hour. Synchronising continuously wasted time, while waiting too long increased drift.

To make synchronisation less critical, I updated the similarity search to inspect every worktree. A newly matched function could immediately become a reference for another agent without waiting for it to reach the main branch. The harness would produce messages such as the following.

1✓ Candidate ["func_80094A94", "func_80094FF4 (../sbk-c)",
2  "func_80094808", "func_8009491C (../sbk-a)",
3  "func_8009469C (../sbk-c)", "func_80093144"] was fixed!

This helped the process remain efficient as the easy functions disappeared. Synchronisation was still needed to consolidate and push changes, but it was no longer required for agents to learn from one another.

Model Choice

I tried GPT-5.5 and 5.6, Claude 4.5 and Fable, and GLM 5.2. This is completely unscientific. The models were tested against a changing set of difficult functions, sometimes after another model had already made partial progress. Broadly, though, Codex continued to outperform Claude, as it had towards the end of the previous project. Sol xhigh was particularly effective once it became available.

GLM 5.2, served by z.ai, was very disappointing. I had previously been a big fan of GLM. It was effective, even if it was not quite a frontier model, and its generous usage limits made up for the gap. That tradeoff became much less attractive as the limits grew less generous while latency remained awful. The feedback cycles were so long that I stopped giving it work and eventually cancelled my subscription.

What Next?

The immediate priority is to better document the game. A 100% match means we have C code for every function; it does not mean we understand what every function does. There are still generated names to replace, unknown structure fields to identify, awkward matches to clean up, and large amounts of data to describe.

Work is also underway on a Snowboard Kids recompilation. Fortunately, the first game shares many of the quirks addressed by patches in Snowboard Kids 2: Recompiled.

I’m looking into porting the levels and other content from the first game into the second game’s engine, although I have no idea how much work that will be yet.

Beyond that, I’m interested in decompiling Snowboard Kids Plus on the PlayStation, a Japan-exclusive expanded release of the first game with extra levels and characters.

If you’ve made it this far, you’re probably interested in decompilation and Snowboard Kids. Take a look at the Snowboard Kids decompilation project. There is still plenty of cleanup and documentation work to do, and contributions are very welcome.