J1coding
72f95b7534
Regex over the source, same shape as the other two tests in here. No build impact, nothing to wire up. It is the only thing in this branch that constrains the next setting anyone adds. Twelve checks, and they earned their keep straight away. Two descriptors disagreed with the value their own property starts at: the OSD position declared a named constant then started at a bare 3, and the JIT protocol declared the by-version default then started at .legacy regardless. Swift will not let the initializer say _xConfig.defaultValue, so the duplication has to stay and the test is what keeps it honest. It also found that a descriptor could inline its own read and write pair straight into SettingCodec, which is the exact asymmetry the type exists to prevent, and that four exemptions could rot without anyone noticing. Four settings load by hand on purpose and are listed as such, so adding to that list is a decision rather than something a new setting inherits by sitting next to one. Five migration reads are listed the same way: a migration wants the value as it is on disk before anything loads, sentinel and all. I broke the tree twelve ways to watch each check fail, including renaming the _xConfig convention, which used to make the whole suite pass on an empty set in three milliseconds. The reset functions still read fxaa = false rather than spelling the descriptor out. The literal is easier to read and the test is what stops it drifting. Also wrote down what init() actually does, because the comment above it said the opposite. Assignments there do not fire their didSet, so nothing writes back while the INI loads. That matters most if you are about to tidy init() into per section helpers, where they would fire, and every non suppressible setting would start writing itself to disk on every launch. Measured with a probe inside commit rather than read off the language reference: zero calls across a launch, one call from one toggle in the same run with the same probe. The two dozen widest setter lines wrap now. commit(_xConfig, x) names the setting three times and didSet gives you no newValue to shorten it with, so the longest ran to 177 characters.
ARMSX2 — Native ARM64 JIT Fork of PCSX2
ARMSX2 is a free and open-source PlayStation 2 (PS2) emulator based on PCSX2. Its purpose is to emulate the PS2's hardware, using a combination of MIPS CPU Interpreters, Recompilers and a Virtual Machine which manages hardware states and PS2 system memory. This allows you to play PS2 games on your phone, PC, or gaming handheld, with many additional features and benefits.
Thank You
The ARMSX2 team is eternally indebted to the PCSX2 project it is based on. We are so fortunate to build on their 20 years of hardcore development.
About This Fork
The upstream PCSX2 project ships an ARM64 interpreter build for ARM, but its high-performance JIT recompilers (EE, IOP, VU0, VU1, and vtlb fast memory) are x86-64 only.
This fork exists to close that gap. The goal is to preserve the correctness features of 20 years of PCSX2 development, while generating the fastest native ARM performance possible.
Current status:
- ✅ EE (Emotion Engine) recompiler — integer, float, MMI, COP0/COP1/COP2, branches, load/store
- ✅ IOP (I/O Processor / R3000A) recompiler — full integer, load/store, branches, coprocessors
- ✅ VU (Vector Unit) recompiler — microVU skeleton + Upper FMAC vector ISA complete; Lower ISA and runtime complete
- ✅ vtlb fast memory
- ✅ Native ARM64 binary builds and boots the PS2 BIOS
- ✅ 2D games are already playable
- ✅ 3D games run
Why LLMs / AI Were Used
A word on methodology:
The x86-64 JIT code in upstream ARMSX2 is already proven correct — it has run thousands of PS2 titles for years. The challenge in this port is not emulator design or JIT theory; it is mechanical translation of a large, well-understood x86-64 assembly codebase into equivalent ARM64 assembly (via VIXL) while preserving the exact same register-allocation contracts, block lifecycle, and recompiler semantics.
Large language models (LLMs) were used as an accelerant for this translation work — pattern-matching x86 JIT boilerplate to ARM64 equivalents, scaffolding emit routines, and keeping the porting velocity high. The JIT logic (block compiler, dispatcher, analysis passes, flag pipelines, clamping rules, Tri-Ace hacks, etc.) is taken directly from the upstream x86 implementation and validated against it. Nothing was hallucinated from scratch.
In other words: the hard engineering was done by the PCSX2 team over two decades. The hard typing — translating ~50k lines of x86 emitter code into ARM64 — is what AI helped compress.
System Requirements
ARMSX2 targets ARM64 across desktop (macOS, Windows, Linux) and mobile (Android, iOS/iPadOS), all from the single shared core. Our setup documentation page contains additional details on software and hardware requirements.
Please note that a BIOS dump from a legitimately-owned PS2 console is required to use the emulator. For more information, visit this page.
Building
Check out our github actions for the latest build recipe