No One Can Stop Mr. Domino — Recompiled

A static recompilation of No One Can Stop Mr. Domino (USA, SLUS-00804), built on psxrecomp and recomp-ui. The PS1 MIPS binary is translated to C and compiled as a native x64 executable — the game runs as real code, not under emulation.

Serial	SLUS-00804
Region	NTSC-U
Publisher	Acclaim Entertainment (dev. ArtDink)
Year	1998
Framework	psxrecomp v0.3.1-alpha-691 (pinned submodule)

Legal

You must own the game. This repository contains no disc image, no boot executable, no BIOS, and no recompiled game code — only configuration, build scripts and notes. Everything derived from the disc is produced on your machine from your own dump and is gitignored.

Retail BIOS dumps are not redistributed either; the build uses the bundled, MIT-licensed OpenBIOS unless you point it at your own SCPH1001.BIN.

Status

Boots, runs at the correct speed, and all six stages are covered by the native overlay cache.

Interpreted instructions per frame
No overlay cache	2,405
437 native shards, all six stages	77 (−97%)

PS1 games stream code overlays from disc that a static recompiler never sees at build time, so they fall back to an interpreter. Compiling captured overlays into native shards is what closes that gap; the remainder is mostly code the BIOS assembles in RAM at boot, which never existed on disc to begin with.

Requirements

CMake	3.20+
Python	3.x
Git	with submodule support
Ninja	recommended — the emitter build prefers it
MSVC	for the emitters only (C++20)
MinGW-w64 GCC	required for overlay shards — see the note below

The runtime is built with clang, not MSVC. psxrecomp's runtime sources use GNU C extensions — designated-initializer ranges ([0 ... N] =) in sio.c, __attribute__ in mdec.c — which cl.exe cannot parse. The build script fetches the portable cmake-clang-v1 toolchain automatically, so nothing extra is needed for that step.

Overlay shards additionally need a real MinGW-w64 GCC (WinLibs is the easiest). Clang cannot build them: the generated overlay C defines overlay_flush_cycles() with dllexport after psx_cycles.h has declared it without, which GCC permits and clang rejects outright.

Build

Clone with submodules, put your .cue where game.toml expects it (by default a sibling directory — adjust [game] disc or pass -Disc), then:

powershell -ExecutionPolicy Bypass -File scripts\build_windows.ps1

That syncs submodules, runs psxrecomp_cli.py generate to translate the disc into C, and configures and builds the runtime. The first run is long — it compiles roughly 300 MB of generated C. Output is build-release\Domino_Recompiled.exe.

Flag	Effect
-Bios C:\path\SCPH1001.BIN	Also generate the retail BIOS backend
-Disc C:\path\game.cue	Override the disc path from game.toml
-Config RelWithDebInfo	Optimized with symbols, and enables the TCP debug server
-BuildDir build-debug	Build somewhere other than build-release
-SkipGenerate	Rebuild only, when generated\ is current
-Clean	Wipe the build directory first
-KeepGoing 10	Pass -k 10 to Ninja to surface many errors in one run

Growing the overlay cache

This is what takes the game from playable to fast. game.toml sets [runtime] overlay_cache = true, so every overlay the game streams is recorded to overlay_captures.json beside the exe while you play. Compiling those captures produces native shards that load automatically on the next launch.

# play, quit normally, then:
powershell -ExecutionPolicy Bypass -File scripts\build_overlay_cache.ps1

Repeat as you cover more of the game. Coverage accumulates: the runtime keeps an immutable history in overlay_captures.json.d\, and the script compiles every snapshot, so overlays that were long since overwritten in RAM are still included.

Flag	Effect
-BuildDir build-debug	Read captures from a different build
-OutDir build-release\cache	Write shards somewhere else
-Gcc C:\mingw64\bin\gcc.exe	Pick the shard compiler explicitly
-Force	Rebuild shards that already exist

overlay_captures.json contains code read from your disc. It is gitignored; keep it local and never attach it to a public issue.

Reaching every stage

Shard coverage only grows for code you actually execute, so the cache is only as good as the ground you cover. tools\ram_hunt.py can warp between stages using the game's own stage-advance path:

# load a save state near the end of a stage (F7), then:
python tools\ram_hunt.py stage 4
# finish the stage -> loads stage 4

This needs a RelWithDebInfo build, since only that carries the TCP debug server. The same tool snapshots and diffs RAM, traces writes with the guest PC that made them, and pokes memory — see --help.

The runtime also has save states (F7, slots 1–9, 0, -, =) and rewind (F8), which need no tooling at all.

Notes

• docs/stage-select-findings.md — reverse engineering of the stage counter: what it does, what it does not, and where a proper stage select would have to look instead.
• symbols.toml → python tools\sync_symbols.py → psx_symbols.h grows a progressive symbol map. See psxrecomp/docs/SYMBOLS.md.
• Submodule gitlinks are the authoritative framework pins; framework_pins.txt is a human-readable snapshot. Bump them deliberately.

Credits

Built on psxrecomp by mstan. Titles using this framework can also be managed through RetComM Launcher, which handles installs, updates and BIOS/ROM wiring across multiple recomps.

---

_{R.A.I.D. — Retro AI Development · a Discord for AI-assisted retro reverse-engineering, decomp & recomp}