System overview

PSXRecompStudio architecture

The project separates managed analysis and application logic from native execution components, with explicit validation boundaries between each stage.

Managed application and analysis

C# and .NET contain the domain model, binary-analysis workflows, recompiler IR and lowering logic, validation code, and tests. Avalonia provides the cross-platform desktop shell. The UI is intentionally kept separate from the core analysis model so research and validation can run without depending on a graphical interface.

Native core

C++ and CMake are used for the native core, including CPU and hardware-oriented components. Native implementation details are not exposed directly to managed code.

C ABI and P/Invoke boundary

The managed/native boundary is a stable C ABI. C# reaches that ABI through P/Invoke, while C++ types remain private to the native implementation. This makes the interop contract explicit and independently testable.

C# / .NET / Avalonia
        |
        | P/Invoke
        v
Stable C ABI
        |
        v
C++ native core

MIPS R3000A analysis

PlayStation 1 code analysis centers on the R3000A and MIPS I execution model. Current work includes instruction decoding, memory behavior, branch and load delay semantics, exception behavior, PS-X EXE analysis, basic-block extraction, and control-flow graph construction.

Recompiler research path

The current static recompilation path is validated on synthetic MIPS fixtures. MIPS instructions are lowered into a backend-agnostic IR, host C is generated deterministically, execution is bounded, and the result is compared against interpreter state. This validates the recompiler architecture without claiming complete PlayStation 1 game recompilation.

Validation and architecture enforcement

Golden Trace and differential validation are used to detect semantic divergence. Separately, compiler-enforced architecture rules constrain layering, dependency direction, forbidden API use, and the interop boundary. Together, these mechanisms are intended to keep both execution behavior and repository structure verifiable as the project grows.

Source documentation

The detailed system design remains in the repository documentation, including ARCHITECTURE.md, the architecture matrix, and the project ADRs.