Reverse Engineering with Lockstep

Accuracy & Reverse-Engineering

The Game.com is one of the least-documented consoles ever sold, so Tigerbyte is built from original reverse-engineering. The thing that separates it from the handful of prior attempts is the accuracy bar we hold it to: real hardware, not another emulator.

The bar is hardware, not MAME

There is exactly one prior emulation of this machine of note — MAME's gamecom driver — and it is a genuinely useful artifact. But it is explicitly not our benchmark for "correct," because measuring against it would cap us at its accuracy, and that accuracy is openly limited:

• Its CPU runs at the wrong clock — 5.5296 MHz, where the real machine is 4.9152 MHz (we'll come back to how that's known).
• Its own CPU source says the per-instruction cycle counts were "educated guesses … through looking at binary data," and its issue tracker flags them as wrong.
• It doesn't implement the sound noise channel at all.

So treating "matches MAME" as success would bake those errors in. Instead the references that actually decide whether Tigerbyte is right are:

1. The official Game.com SDK. Its calibrated delay routines have known real-world durations — a 20 ms busy-loop, for instance — so back-solving them yields hardware cycle counts. That loop is what proves the clock is 4.9152 MHz exactly and pins down individual instruction timings (DECW=8, BR-taken=8, …), independent of any emulator.
2. The Sharp SM8521 datasheet — the register map, timer/interrupt behavior, sound generator, and the authoritative instruction-timing table.
3. Direct capture from a real console. Audio and video recorded off hardware, compared sample-by-sample. The sound work is tuned against a clean recording of the real boot jingle, measured spectrally — the console is the arbiter, not a second emulator's output.

Lockstep — the scaffolding, not the structure

Early on, one technique was worth its weight: diff a per-instruction program-counter trace from a known-running emulator against ours, and the first divergence is the instruction your CPU decoded wrong. Run over the same ROM, it turned "stuck somewhere in 20,000 instructions" into "instruction N, here." It found, in minutes, a word-ALU opcode group decoding with the wrong operand length — a two-line fix that had been silently corrupting a kernel table far downstream.

That is real and it mattered — but it is bootstrapping, not a measure of quality. It only checks the decoder (control flow is decode-correct regardless of timing), and it only checks it against MAME. It got the CPU on its feet so the hardware-grounded work could begin. (One gotcha if you try it: dump the trace with noloop, or the collapsed-loop markers desync the diff and fake a divergence.)

Where Tigerbyte already passes MAME

This is the part the bar above makes possible:

• Correct CPU clock (4.9152 MHz), proven from the SDK — not inherited from MAME's wrong one.
• Per-instruction cycle counts, cross-checked against the SDK's hardware-confirmed values.
• The SG2 noise channel implemented — silent in MAME and every other emulator; Tigerbyte generates it (an LFSR-based "false noise"), so noise sound effects actually play.
• Audio validated against a hardware recording, not against another emulator's guess.

The standard going forward

Accuracy is a claim that needs proof, so the plan is a real conformance effort: author SM8521 test ROMs (the SDK ships an assembler), keep building out hardware A/V captures, and finish transcribing the datasheet's instruction-timing table. The goal isn't to match the prior emulator — it's to be the reference the next one measures itself against.