psxrecomp/docs/ARCHITECTURE.md

Architecture

How PSXRecomp is put together, end to end. For the higher-level "why three ways of running code" story, read EXECUTION_MODEL.md first; this doc is the component-level view.

Two programs: the recompiler and the runtime

PSXRecomp is split into two CMake projects that are built and run separately:

  recompiler/           runtime/
  ───────────           ────────
  MIPS  ──▶  C           C + hardware simulation  ──▶  native game binary
  (build-time tool)      (linked with the generated C)

• recompiler/ (C++20) is an offline tool. It reads MIPS R3000A machine code and emits C source files under generated/.
• runtime/ (C99 + C++17) is the engine. It loads the game's assets into an emulated PS1 address space, links the generated C in as native functions, and simulates the console's hardware around them.

A game repository (e.g. TombaRecomp) contains no framework source — it links this framework in (as a submodule) and provides the game's config, seeds, and build glue. See BUILDING.md.

The recompiler (recompiler/)

Two entry points share the same translation core:

• src/main_bios.cpp — ingests the flat BIOS ROM (SCPH1001.BIN, loaded at 0xBFC00000) and emits generated/SCPH1001_*.c.
• src/main_psx.cpp — ingests a PS-X EXE extracted from a game disc and emits generated/<serial>_*.c.

The translation pipeline:

Stage	File	Job
Decode	mips_decoder.cpp (+ vendored rabbitizer)	Decode MIPS instructions
Control flow	control_flow.cpp, basic_block.cpp	Build basic blocks / CFG
Discovery	function_discovery.cpp, function_analysis.cpp	Find function entry points (seeded from Ghidra exports)
Codegen	code_generator.cpp, full_function_emitter.cpp, strict_translator.cpp	Emit C: one function per guest function, plus a dispatch table

Output is two files per program: a _full.c (the function bodies) and a _dispatch.c (the address→function dispatch table). Both are build artifacts and are never hand-edited — if the C is wrong, the fix is in the recompiler.

GTE (the PS1 geometry coprocessor) instructions are emitted inline; COP0 kernel-mode instructions the BIOS needs are handled in codegen.

The runtime (runtime/)

The runtime is assembled by one CMake helper, psxrecomp_add_runtime_target() (defined in runtime/runtime.cmake), which a game's CMakeLists.txt calls with the paths to its generated C. The runtime provides:

• Memory & address space (memory.c) — the 2 MB main RAM, scratchpad, BIOS ROM, and MMIO regions, with the dispatch that routes a guest PC to its native function (static, overlay, or interpreter).
• Hardware simulation via MMIO handlers — GPU (gpu.c, gpu_sw_renderer.c, gpu_gl_renderer.c), DMA (dma.c), timers (timers.c), CD-ROM (cdrom.c, iso_reader.cpp), MDEC, SIO0 controllers/memory cards (sio.c, memcard.c), SPU (spu.c), GTE (gte.cpp), and interrupt delivery (interrupts.c).
• Host services — window/input/audio via SDL2, a cooperative-thread scheduler on host fibers (psx_fiber.c: Win32 Fibers / POSIX ucontext), and the optional debug TCP server (debug_server.c).

BIOS: LLE baseline + a swappable HLE tier

The recompiled SCPH1001.BIN is the low-level (LLE) baseline: it is the kernel, and it is the reference implementation and the correctness oracle. There are no per-vector HLE shims replacing it.

On top of that, PSXRecomp carries an optional HLE tier (bios_hle, on by default for player convenience) that can synthesize the post-boot kernel handoff state to skip the BIOS boot sequence, and intercept a small set of BIOS services — always falling through to the recompiled BIOS for anything it doesn't implement. LLE stays fully linked and is what every accuracy check runs against. Turn it off with [runtime] bios_hle = false or PSX_BIOS_HLE=0; with it off the build behaves as pure LLE. (Design notes: docs/internal/HLE_SCHEDULER_CARVEOUT_PLAN.md.)

Static / overlay / interpreter dispatch

This is the heart of the system and has its own doc, EXECUTION_MODEL.md. In brief: a guest PC resolves to statically-recompiled native code (BIOS + main EXE), a runtime-compiled native overlay (overlay_capture.c → tools/compile_overlays.py → overlay_loader.c), or the small dirty-RAM interpreter (dirty_ram_interp.c) — in that priority order.

Overlay compile backend

When an overlay needs compiling, the runtime spawns a C compiler on the recompiler-emitted C and loads the resulting DLL — it does not JIT in-process. The backend tier is resolved in overlay_backend.c (see main.cpp around the code_provider setup):

  static  →  gcc  →  tcc

• static — the overlay was baked into the binary at build time (best case).
• gcc — used when a system gcc is on PATH (the development default).
• tcc — TinyCC, the toolchain-free fallback bundled beside shipped executables in overlay_toolchain/ (an embedded Python + tcc.exe) so players never need a compiler installed.

Compiled overlays are stored in a content-addressed cache namespaced by compiler and target ABI (<game>/gcc/<arch-abi>/… vs <game>/tcc/…); a gcc shard wins over a tcc shard for the same region. See docs/FEATURES.md, docs/OVERLAY_CACHE_V2.md, and docs/ASYNC_OVERLAY_COMPILE.md.

Renderers

Three GPU backends behind one interface:

• Software rasterizer — CPU, most portable, the reference look.
• OpenGL — GPU-authoritative VRAM/FBO renderer, the default; moves rasterization and supersampling onto the GPU. Falls back to software if GL init fails. (See docs/internal/GL_RENDERER_HANDOFF.md.)
• Vulkan — experimental, off by default (PSX_ENABLE_VULKAN=OFF).

Widescreen (a genuine wider GTE FOV, not a stretch) is opt-in and gen-time; see WIDESCREEN.md and docs/internal/NATIVE_WIDE_PLAN.md.

The oracle model (how correctness is checked)

PSXRecomp validates itself against Beetle PSX (the mednafen-psx libretro core), run as a separate process with an identical TCP JSON debug protocol:

• psx-runtime — the recompiled runtime (debug server on port 4370).
• psx-beetle — Beetle PSX (debug server on port 4380).

A tool written against one works against the other by switching ports; cross- checking is done by querying both, never by sharing state in one process. There is also a first-divergence co-sim build that cycle-locksteps the compiled backend against the interpreter. See docs/internal/COSIM_ORACLE.md, docs/config_schema.md, and TCP_COMMANDS.md.

Configuration

Every process has a BIOS config; a game adds a game config (game.toml), and the two are merged (game wins on scalar keys; program blocks and generated dispatch tables are additive). Full schema: docs/config_schema.md.

Where to go next

• EXECUTION_MODEL.md — static/native/interp in depth.
• BUILDING.md — dependencies + build steps.
• ../CONTRIBUTING.md — dev workflow and rules.
• ../CLAUDE.md — the exhaustive engineering constitution.