The SNES
Checksum

The Super Nintendo launched in Japan in 1990 — as the Super Famicom — and reached North America in 1991, Europe in 1992. It arrived in the shadow of the 1983 North American video game crash, a market collapse Nintendo had watched claim Atari and dozens of third-party publishers. The lesson Nintendo drew was precise: if you did not control what ran on your hardware, the market would drown in shovelware and collapse beneath it.

Nintendo's response was a two-layered system of control that operated at both hardware and software levels. The first layer was physical and immediate — a lockout chip that refused to let unauthorised cartridges boot at all. The second was administrative — a mandatory approval process, backed by legal threat, that required every licensed publisher to submit game code for Nintendo's review before manufacture. The checksum sat inside this system as a piece of technical housekeeping that would later take on a life of its own.

The Checking Integrated Circuit — the CIC — was Nintendo's hardware padlock. It is a system in which a key (stored in the game cartridge) is used by a lock (stored in the console) to verify that the game is authentic and from the correct region. Both chips were Sharp 4-bit microcontrollers running a proprietary protocol: at boot, the console-side chip would open communication with the cartridge-side chip and begin exchanging a rolling sequence of values. If the cartridge could not respond correctly — because the CIC chip was missing, cloned incorrectly, or from the wrong region — the CIC would repeatedly reset the CPU at a frequency of 1 Hz, causing the television and power LED to blink and preventing the game from becoming playable.

The SNES used an evolved version of the NES's 10NES system, with regional variants. In total, six types of CIC lockout chips existed for the SNES — three for NTSC regions and three for PAL. A Japanese Super Famicom cart carried a different CIC seed than a European PAL cart, and the mismatch was intentional: region lockout and piracy prevention were baked into the same mechanism. You could not simply buy an American cartridge and play it on a European console — the chips would disagree, the CPU would reset, and you would see a black screen.

Unlicensed publishers found other routes. A few games released in Europe and Australia came as dongles that connected to a licensed cartridge, borrowing that cartridge's CIC chip for authentication — a method also used by Super Noah's Ark 3D on the SNES. Tengen, Atari's home games subsidiary, took a more confrontational approach on the NES: the corporation obtained a description of the lockout chip's code from the United States Copyright Office by claiming it was required for an ongoing legal defence, then used it to produce a clone chip. Nintendo sued. Tengen lost.

Passing the CIC handshake got a cartridge to boot. What happened next depended on what the CPU found in ROM. Every licensed SNES game was required by Nintendo to include a structured header — a 48-byte block of metadata embedded in the cartridge ROM, describing the hardware configuration and identifying the software to anyone who needed to read it.

The header's location in the file shifts depending on the memory mapping mode. LoROM games place it at file offset $007FC0, HiROM games at $00FFC0, and ExHiROM games at $40FFC0. Emulators use the map mode byte and the checksum itself as dual heuristics for figuring out which layout a ROM file uses — if the checksum and complement at a given offset sum to

$FFFF

The SNES checksum is not a CRC in the cryptographic sense — it is a simple 16-bit arithmetic sum. Every byte in the ROM is added together, with overflow discarded, to produce a 16-bit value. That value is stored at

$FFDE

$FFDC

$FFFF

def compute_snes_checksum(rom_data: bytes) -> tuple[int, int]:
    """
    Returns (checksum, complement) for a LoROM image.
    Before calling: zero out bytes $7FDC-$7FDF in the data.
    """

    # Step 1 — zero the header fields so they don't skew the sum
    data = bytearray(rom_data)
    data[0x7FDC:0x7FE0] = b'\x00\x00\xff\xff'  # complement=$0000, checksum=$FFFF

    # Step 2 — sum every byte, discard overflow past 16 bits
    checksum = sum(data) & 0xFFFF

    # Step 3 — complement is the bitwise NOT, masked to 16 bits
    complement = checksum ^ 0xFFFF

    # Invariant: checksum ^ complement == 0xFFFF (always)
    assert checksum ^ complement == 0xFFFF

    return checksum, complement

# Example: Super Mario World (U) has checksum $A0DA
#          complement = $A0DA ^ $FFFF = $5F25
#          $A0DA + $5F25 = $FFFF ✓

There is a subtlety in the initialisation step. Before computing the checksum, the header's checksum and complement fields must be pre-filled with

$0000

$FFFF

For ROMs whose size is not a power of two — a 3 MB game, for instance, rather than a clean 2 MB or 4 MB — the process becomes more involved. The ROM is treated as two regions, each a power of two in size. The larger comes first, the smaller is repeated until the combined total reaches the next power of two, and the checksums of both halves are added together. This mirroring matches what the physical cartridge does in hardware, where smaller ROM chips repeat their address space to fill the memory map.

The CIC chip stopped cold-booting pirate cartridges. It did not stop cartridge copiers — dedicated devices that dumped a legitimate cartridge's ROM to floppy disk or a RAM pack, which could then be replayed through a licensed shell cart containing a real CIC chip. By the mid-1990s, copiers like the Super Wild Card and the Magicom were widely available, and publishers knew it. The response was a second generation of anti-piracy measures embedded in game code itself.

Early copiers were unsophisticated in a specific way: they gave every game the same generous amount of SRAM regardless of what the cartridge header declared. Developers began writing code that checked this. EarthBound — known in Japan as MOTHER 2 — became the landmark example. A subroutine called on startup verified that only 8 kilobytes of SRAM was present. Cartridge copiers had more, so if they were detected, the game displayed a screen reading "It is a serious crime to copy video games." The check was not looking for a pirate — it was looking for the specific fingerprint of the hardware pirates used.

EarthBound went further. A second subroutine took a checksum of the game's own anti-piracy code at runtime — if those bytes had been modified to disable the SRAM check, the checksum would fail, and the game would enter an unstable state. The ROM verified itself. Patching one protection triggered another. Donkey Kong Country 2 used a similar approach: at the beginning of each level, a checksum was computed over 544 bytes of critical game code. If the result didn't match the expected value, the protection triggered silently.

Other games checked the PPU type. The SNES had different PPU revisions for NTSC and PAL — one generating 262 lines and one generating 312 lines. A game could read register values to determine which PPU was present and refuse to run if the result didn't match the expected region. Playing an NTSC cartridge on a PAL console — even with the CIC bypassed — would trigger a region warning. Some titles ran this check continuously through gameplay, not just at boot.

The hardware underpinning all of this was remarkable for its era and, in one respect, quietly peculiar. The SNES CPU is the Ricoh 5A22, an 8/16-bit processor based on the WDC 65C816 — itself developed between 1982 and 1984, originally for the Apple IIGS personal computer. It runs between 1.79 MHz and 3.58 MHz depending on which memory bus it is accessing, and uses an extended MOS Technology 6502 instruction set. The 6502 lineage traces directly back to the original NES — Nintendo was, in a sense, still running an evolved version of the 8-bit architecture it had started with in 1983, now dressed in 16-bit clothing.

What the 5A22 could not do in raw speed, the SNES compensated for with dedicated graphics hardware. Mode 7 — background graphics mode seven of eight available — gave the PPU the ability to apply an affine transformation matrix to a single background layer on a per-scanline basis. The CPU had to perform trigonometric functions to populate the rotation matrix entries, which was computationally expensive. Ricoh integrated hardware multiplication and division registers into the 5A22 specifically to accelerate this. The result was the rotating, scaling, tilting ground plane that defined a generation of racing games: F-Zero's track banking into the distance, the map screen in Super Mario Kart, the Mode 7 boss fights that appeared in dozens of titles throughout the SNES's lifespan. None of it was "3D" in any real sense — the effect applied transformations scanline by scanline to simulate perspective on a flat plane. It was an illusion. It was a very convincing one.

Nintendo's approval process required correct headers, and correct headers required correct checksums. As a quality gate, the mechanism was sound — a publisher could not submit a corrupt ROM file without the checksum betraying it. What Nintendo did not anticipate was that the same checksum would become the primary tool by which, thirty years later, an entire ecosystem of emulators, ROM preservation archives, and flashcarts would identify, categorise, and verify every game the SNES ever ran.

The No-Intro and GoodSNES ROM databases use the checksum — alongside CRC32 and SHA-1 hashes of the raw file — to identify whether a dump is faithful to the original cartridge. A "good dump" is one whose internal checksum matches the declared value. ROM hacks, fan translations, and patched files typically carry broken checksums — useful metadata for distinguishing a modified ROM from a clean one without inspecting the data itself. Emulators like ZSNES and Snes9x report checksum validity directly in their ROM information screens, flagging mismatches as a signal that the file may be a bad dump or a modified image.

The checksum was designed as a manufacturing quality-control stamp and a piracy deterrent, embedded in 48 bytes of ROM header that the SNES CPU never read. It outlasted the console, the copiers, the approval process, and the patents on the CIC chip. It is still the first thing every serious SNES emulator looks for when a ROM file is opened — two bytes at a fixed offset, and their mirror, that together always add to

$FFFF