J1coding
1d0e6bea4e
Tester on the last build said the phone rumble now sustains properly but plays at one strength the whole time regardless of what the game asks for. Four things were stacked up behind that. The big one is that we took max() of the two motor values. The PS2 small motor has no speed control at all, it is on or off, so it arrives here as a flat 1.0. Taking the larger of the pair meant the moment a game touched the buzzer the whole thing pinned to full and the heavy motor, the only one carrying any variation, got thrown away. The other three are in how the pattern was built. The live intensity parameter multiplies the event's own intensity rather than replacing it, and we were baking whatever the first rumble happened to be into the event, so that first value became a ceiling for the rest of the burst. Sharpness was baked the same way and then shifted again by its control, which is an offset rather than a replacement, so it landed twice. And the sharpness curve had it backwards against the hardware: the taptic engine puts out the most force around 0.73, and we were sitting the binary buzzer right on top of that while the analog motor played down at 80 Hz where you can barely feel it. Each motor now gets its own looped channel, the heavy one low and dull, the buzzer high and sharp, both built at full intensity so the live parameter has room to work. Only intensity is sent at runtime now. Test Rumble never reached any of this either. It only called the controller path, which wants a real controller and quietly gives up without one, so on a bare phone the button did nothing at all. It now steps the heavy motor up through three levels and buzzes the small one, which is enough to check the strength slider without loading a game. Last thing, the tap fallback for hardware with no taptic engine was handed the controller-clamped values and then divided by the full range, so it could never get past 44 percent.
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