SA-1 Root: making Super Nintendo games use their own accelerator chip

What the project is: engine patches, not a chip emulator

SA-1 Root is a project for enabling and accelerating games using the SA-1 chip, and the README describes it as a pack of patches that optimizes the game to the maximum possible while keeping high hardware compatibility and keeping most of the game aspects intact.

That last clause is the design constraint that makes the project interesting. The obvious way to speed up an old game is to rewrite it, and the other obvious way is to emulate a faster machine. SA-1 Root does neither. It targets the actual coprocessor that shipped inside a handful of Super Nintendo cartridges and writes patches that make the original game code use it.

The project is a 65816 assembly codebase, and the banner at the top of the README carries the version and the author:

  _____             __   _____             _   
 / ____|  /\       /_ | |  __ \           | |  
| (___   /  \ ______| | | |__) |___   ___ | |_ 
 \___ \ / /\ \______| | |  _  // _ \ / _ \| __|
 ____) / ____ \     | | | | \ \ (_) | (_) | |_ 
|_____/_/    \_\    |_| |_|  \_\___/ \___/ \__|
    Version 1.10             by Vitor Vilela

The individual games each have their own directory in the repository, with Contra-III/, Gradius-III/, Race-Drivin/ and Super-R-Type/ at the top level, and each has its own version: Contra III v1.3, Gradius III v1.7, Race Drivin' v1.1 and Super R-Type v1.3. Super Mario World is handled separately, since that title is covered by the SA-1 Pack rather than by this project.

The releases follow the same per-game pattern, and the titles are informative about the scope. The newest tag is v1.10, titled Contra III for Europe and Japan, dated 2026-10-20, and the previous one is v1.9, Super R-Type for Europe and Japan, from 2026-10-01. So the project ships regional variants, which is what you would expect when a patch is tied to a specific release of a game with different data and different memory layout.

The licence is not stated for the repository, which is worth knowing before redistributing anything derived from it.

What the SA-1 chip actually is, and what activating it buys you

The README explains the hardware, and the numbers are what make the project worth doing.

SA-1, the Super Accelerator, is a coprocessor included on some Super Nintendo game cartridges, made to work together with the Super NES CPU and used to enhance processing speed, graphics and memory.

The speed comparison is the headline. With its 10.74 MHz clock, the SA-1 CPU is four times faster than the normal SNES CPU, and because the SA-1 CPU and the SNES CPU run simultaneously, that can result in up to five times faster processing over a game with no enhancement chips.

What that headroom buys is spelled out: more sprites processed at once, more in-game effects, faster loading, and much more. On a game whose engine was written for a 3.58 MHz machine, that is the difference between a game that runs and a game that stutters.

The system features list in the README gives the hardware detail, and it is more specific than a general description. There is a 16-bit 65c816 processor clocked at 10.74 MHz, 2 kB of fast internal work memory, which the register documentation calls I-RAM, also clocked at 10.74 MHz, multi-processor processing with parallel operating mode and memory sharing control, and a total of 8 MB of ROM clocked at 10.74 MHz alongside 256 kB of BW-RAM clocked at 5.37 MHz.

Two features stand out for anyone thinking about how the patches work. There is high speed arithmetic hardware for multiplication, division and cumulative sum, and there is a custom DMA circuit for fast transfers between ROM, I-RAM and BW-RAM. The arithmetic unit is why game engine routines can be moved wholesale rather than rewritten, and the DMA path is how data gets to the coprocessor without the main CPU waiting.

There is also a Bitmap and Character Conversion function for fast graphics manipulation, Variable-Length Bit data processing for enhanced algorithms such as graphics and data compression, and Super MMC memory mapping capabilities for BW-RAM and bank switching for multiple ROM image access and mirroring.

Root against Pack, and the difference in what each one does

The README has a section specifically on the differences with SA-1 Pack, and the distinction is about scope rather than quality.

SA-1 Root is intended to be the base pack for enabling SA-1 on the games and optimizing it. SA-1 Pack is intended to be a full featured pack that not only enables SA-1 and accelerates the game but also improves the game engine and provides additional tools for ROM hacking.

The example given makes the gap concrete. Super Mario World's SA-1 Pack doubles the maximum physical amount of allowed enemies on screen and includes different shared routines for additional SA-1 features. That is a game engine change, in the sense of a gameplay change, on top of the acceleration.

That is why Super Mario World appears in the list of available games but points to the separate SA-1 Pack repository rather than having a directory here. The project's own list shows Contra III, Gradius III, Race Drivin' and Super R-Type, with Super Mario World listed as an SA-1 Pack only entry.

The distinction matters if you are deciding where to spend your time. Root is the enabling and optimisation layer, and it aims to keep the game intact. Pack goes further and deliberately changes the game, which is a different kind of project with a different set of expectations about what a saved file or a high score table means.

The version numbers support the same reading. The releases here are numbered per game and per region, v1.9 for Super R-Type for Europe and Japan and v1.10 for Contra III for Europe and Japan, and the per-game internal versions are lower, Contra III v1.3 and Super R-Type v1.3 among them, so the top level version is the project release while the directory version is the state of that particular patch.

Compatibility, and the emulator that will not work

The compatibility section is short and it makes two claims that matter in opposite directions.

SA-1 Root is warranted to work with real hardware, including SA-1 carts, and with the most up to date SNES emulators including bsnes and Snes9x.

ZSNES is not compatible with the SA-1 Root patches.

That exclusion is worth understanding rather than treating as a footnote. ZSNES was the long-standing default emulator for a generation of users, and a project that explicitly excludes it is telling you that the patches rely on behaviour or memory mapping that ZSNES does not reproduce. The SA-1 documentation linked in the useful links section, including the SA-1 registers page, is the reference for what those differences are.

The claim about real hardware is the stronger one. Working on an actual cartridge with the actual coprocessor means the patch is exercising the chip rather than an approximation of it, and the credits list is consistent with that level of rigour. There are two hardware bug reports credited, one from arcademaster01 and one from Jonas Quinn, and a third from Voultar, and there are separate entries for testing and for trace logs on each of the four games, including several dedicated to providing trace logs for Contra III, Super R-Type and Race Drivin'.

Trace logs are the thing that makes this credible. Reverse engineering an engine to move routines onto a coprocessor means tracing what the original code does at the instruction level, and the credits show that the author was supplied with that data by people running the games on real hardware or in a debugger, one of whom contributed a Gradius III speed reduction patch add-on and several of whom filed bug reports. The credit for the author himself is the honest one, crazy author that did most of the patches.

So the compatibility story is: real carts, the current emulators, and not the one popular emulator from the previous era. If your only route to playing is ZSNES, this project is not for you.

Where to read more, and who maintains it

The README closes with a set of technical references that are worth more than most of the prose.

There is the SA-1 article at SnesLab, which is the general hardware overview, the SNES Dev. Book hosted on romhacking.net, the SA-1 registers page on the Super Famicom wiki, and the author's own SA-1 Doc repository on GitHub. The register reference in particular is what you want when you are writing code that talks to the coprocessor directly, because it is the list of what the chip exposes and what each register does.

The author is reachable through several routes: a personal site at sneslab.net, a GitHub profile, a Twitter account, and a Patreon page. The Patreon link is also where the special thanks come from, with two named patrons, and the README notes the support is what keeps the work going.

That funding model is worth noting as a structural fact about the project. Work of this kind is slow, expert and largely thankless, the hardware and the games are old, and the audience is a small specialist one. A patch set that requires a per-title engine analysis, trace logs and testing on real cartridges is not something a general open source funding model would sustain, and the patron list is how this one does.

The last push to the repository was on 2026-10-20, the same day as the v1.10 release, and there are no GitHub releases listed beyond the tagged ones. The top level of the repository is deliberately minimal: the four game directories, a README, a .gitignore and nothing else, so the per-game directories hold essentially all of the work.

Editorial conclusion

Adopt SA-1 Root if you own a compatible Super Nintendo cartridge and want the original game running with its own accelerator chip enabled rather than a separate re-release. Do not treat it as a general SNES enhancement toolkit, because the patches are per-game and depend on that title's engine internals. Before you apply one, read the compatibility section, since the project warrants the patches for real hardware and for the most up to date emulators including bsnes and Snes9x but not for ZSNES, and note that the optimisation is aggressive enough that the author reports trace logs from testers were needed to get each game right.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. VitorVilela7/SA1-Root on GitHub