A real SNES routine · ActRaiser (1990) · $00:984E–$00:9883

Three ways to run the same 54 bytes

Emulation, recompilation and decompilation get mixed up all the time. This page takes one real routine from ActRaiser, a 1990 SNES game, and shows it each way. The routine decides what the player’s character does next while standing still. The difference between the three comes down to when the game’s code gets translated, and how much machinery is still running underneath it while you play.

On the cartridge

These 54 bytes are the routine exactly as it sits in the ROM. Point at a group to decode it.

Turning bytes into instructions is the job an emulator does while you play, and a recompiler does once before you play. Decompilation goes a step further and works out what the instructions mean.

Who does the work, and when

All three end with the game running on your computer. What changes is when the game’s code gets translated, and what is still running underneath it while you play.

Emulation

Pretend to be a SNES. The emulator reads the game’s machine code as data and carries out each instruction as it comes.

The game’s machine coderead as data, a few bytes at a time
Interpreter loopfor every instruction, every time it runs
A simulated SNESCPU, RAM, graphics, sound and DMA, kept in step
Your OS, GPU and audio
Your CPU

Emulator source codewritten once, for every game
C compileroptimizes the emulator, not the game
Nothing game-specificthe emulator loads the ROM as is

Recompilation

Translate the program once. A recompiler turns the machine code into C before you play. The compiled game runs natively on a layer that stands in for the SNES hardware.

The game as native codegenerated C, compiled for your CPU
Translation layerSNES registers and memory map, graphics, sound and DMA
Your OS, GPU and audio
Your CPU

The game’s ROM
Recompilerdecodes every instruction once and writes C
Generated Cexact, but still shaped like the SNES
C compileroptimizes the game’s own code
Native programplus the translation layer

Decompilation

Recover what it means. People, with tools, work out what each routine does and rewrite it as ordinary code that needs no model of the SNES.

The game as ordinary Cnames, types and plain functions
Your OS, GPU and audioor any engine
Your CPU

The game’s ROM, disassembled
People, with toolswork out what each routine means
Readable Cnamed, typed and structured
Testscheck it behaves exactly like the original
C compileroptimizes it like any program
Native program

While you play, the emulator carries the most machinery and the decompiled game carries the least.

Hatched layers are a model of the SNES hardware.

One decision, three ways

Each frame the player stands still, the game runs these 20 instructions to decide what happens next. They check, in this order:

Nothing underfoot: fall.
B pressed and nothing overhead: jump.
Down held: crouch.
Left or Right held: run.
Otherwise, stand still.

Set up a situation and its path through the original code lights up. Switch tabs to follow the same path through each approach, and point at any line to see where it went. Attack and magic are checked just before this routine, so Y, X and A don’t appear here.

Situation

B jumps, Down crouches, ◀ and ▶ run. Press to toggle.

ResultJump

Original
Emulator
Recompiled
Decompiled

Original

65816 machine code

What the SNES CPU runs. X holds the address of the player’s object ($08A0), so $001A,X is the player’s pose.

The actual instructions, in the old machine’s language. The last column says what each one does in plain words.

● ran↷ branch taken→ leaves the routinefaded rows were skipped

The live translator

This is the translator’s rulebook. It knows what every kind of instruction means, but nothing about this game.
This piece of the game runs about 60 times a second, and the translator works through it again every single time.
All that translating is extra work for your computer, on top of actually playing the game.

An emulator: the game is data, and a loop drives it

This code knows nothing about the game. case 0xAD runs both LDA $00A1 instructions here, and every other absolute LDA in the game.
Each time an instruction runs, the emulator fetches its bytes again and works out what they mean, down to whether it is 8-bit or 16-bit (cpu->m_flag ? … : …). That even decides how many bytes the instruction has.
The C compiler optimized this loop, not the game. It never sees that the three instructions at $985B together mean “is B pressed?”, so it can’t simplify them.
After every instruction, the graphics, sound and timers have to catch up so the whole console stays in step.

The numbers in the margin count how many times the translator used each rule for the situation you picked.

Illustrative. It uses the same Cpu struct and memory helpers as the Recompiled tab, so the two line up. Real emulators differ in detail but share this shape. The counts in the margin show how often each part ran for the situation above.

The pre-translated book

This piece was translated once, before you started playing. Each old instruction became a line or two of new code.
Nothing needs translating while you play, so your computer has much less extra work to do.
But it’s word for word. It still talks about the old machine’s parts, and it never says what any of it is for.

Recompiled: translated once, then compiled to native code

Each instruction became a line or two of C. The operands are now constants (0x00A1, 0x0080), and branches are gotos to labels named after ROM addresses.
Nothing reads or decodes the game’s bytes while you play. The C compiler sees the game’s own logic and optimizes it like any other C.
It still behaves like a SNES CPU. Registers and flags live in a struct, and mem_read16(cpu->db, 0x00A1) goes through the translation layer, which maps SNES addresses onto emulated memory and hardware.
The translation is exact but nameless. Nothing here says “jump” or “ground”, because the recompiler never learned what any of it means.

Illustrative. Real recompiler output has this shape, but is usually noisier, with extra bookkeeping for calls, interrupts and debugging.

Why the _M0X0 suffix? The 65816 can switch its accumulator between 16 and 8 bits, and the same eight bytes then decode to a different program.Why the odd name ending in _M0X0? The old machine had two modes, and the same numbers mean different things in each one.

M=0, 16-bit A (as the game runs it)

$985E  89 80 00  BIT #$0080
$9861  F0 03     BEQ $9866
$9863  82 73 00  BRL $98D9

M=1, 8-bit A

$985E  89 80  BIT #$80
$9860  00 F0  BRK #$F0
$9862  03 82  ORA $82,S
$9864  73 00  ADC ($00,S),Y

An emulator checks the M flag as it goes. A recompiler has to settle it before writing any C, so it emits a separate translation for each mode a routine is entered in, and calls the one that matches.

Where did the program counter go? This is all the CPU state the recompiled code needs. There is no PC.No bookmark needed. This is everything the pre-translated game has to remember about the old machine.

In recompiled code the next instruction is simply the next line of compiled C, and a JSR becomes an ordinary function call. The emulator has to keep pc itself and move it along byte by byte.

The live translator has to keep a bookmark of exactly where it is. The pre-translated game just runs from one line to the next, so it doesn’t need one.

Rewritten in plain words

Someone worked out what this piece is for and rewrote it so people can read it.
It reads almost like a sentence: if there’s no floor, fall. If you pressed jump and nothing is above you, jump.
Because it’s clear, it’s easy to fix, change, or add new moves to.

Decompiled: rewritten as ordinary code

The decision in these 20 instructions became five lines. Names replace numbers: bit $80 of $00A1 is jump_pressed, and the carry flag after JSR $8FE7 is on_ground.
There are no registers, flags, addresses or ROM. It is a plain function you can read, test and change without any model of the SNES.
The rules are easy to see now. Falling beats everything, a low ceiling cancels a jump, and crouching beats running.
It can grow past the original. A new move is one more line, and nothing here depends on SNES timing or memory layout.

Illustrative. The names are chosen by whoever does the decompiling. A faithful decompilation keeps the original’s order of side effects, which is why the two probe results arrive as inputs instead of being called in here.

Testable without a SNES. No ROM, no CPU state, no emulated memory.Easy to check. You can test the rewrite without any old machine at all.

The situation starts with B and Down held, moving right, and nothing underfoot. Each line changes one thing and checks the decision.

Real projects mix all three

These aren’t exclusive choices. A recompiled game still needs something to play the part of the hardware, a project can leave some chips emulated, and decompiled code can replace recompiled code one routine at a time.

RecompiledThe main CPU’s game code
Translation layerMemory map, graphics, DMA and timing
EmulatedCoprocessors, such as the SNES’s SPC700 sound CPU
DecompiledGameplay, one routine at a time

Here is one way a decompiled routine can take over from recompiled code without changing anything around it.

The recompiled function checks for a replacement

A hook at the top hands control to the decompiled version, but only when the machine is in the state the replacement expects, such as 16-bit registers. Otherwise the recompiled body runs, so the original stays available to compare against.
An adapter translates between the machine and the types

It still calls the original probe routines in the original order, reads the same buttons and D-pad value, asks choose_idle_action for a decision, and turns the answer back into the address the original would continue at.

The rewrite speaks in plain words, but the rest of the game still speaks the old machine’s language. A small go-between collects what the rewrite needs to know, asks it what to do, and passes the answer back.

A careful adapter also leaves registers and flags the way the original would have, because recompiled code that runs next may read them.

Each routine that moves across leaves the adapters less to translate. Once nothing is left, that part of the game no longer needs the SNES model at all, and it can grow past what the original hardware allowed.

At a glance

	Emulation	Recompilation	Decompilation
In one line	A live translator	Translate the whole book first	Rewrite it in plain words
When does the translating happen?	While you play, nonstop	Once, before you play	Once, by people, before you play
Extra work while you play	Lots	A little, for the stand-in parts	Almost none
Can people read it?	No	Barely	Yes
Easy to change the game?	Hard	Possible	Easy
Work to support a new game	None, it works with any game	Some	A lot

	Emulation	Recompilation	Decompilation
When the game’s code is translated	While you play, every instruction, every time it runs	Once, before you play, by a tool	Once, before you play, by people using tools
What your CPU runs	The emulator’s loop. The game is data.	The game as native code, on a translation layer	The game’s logic as native code
Model of the SNES needed	All of it	CPU state, memory map, graphics, sound	None
Main runtime overhead	Fetching, decoding and dispatching every instruction, plus simulating the hardware in step	The translation layer: emulated memory and hardware, SNES-style flags	Nothing inherited from the SNES
Work per game	None. One emulator runs the whole library.	Teach the tool the game: what is code, which CPU modes, where jump tables lead	Understand, name, rewrite and test each routine
Readable source	None	Exact but nameless (`L_9866`, `cpu->flag_z`)	Names, types and structure
Changing the game	Patch bytes in the ROM	Hooks and patches around translated code	Edit it like any program
How it stays faithful	Reproduce the hardware	Reproduce every instruction’s effect	Test against the original