Brian Degenhardt
9fbb2d8cf2
GrowVertexBuffer listed m_draw_vertex/m_draw_index alongside the real vertex and index buffers and preserved their contents across the reallocation, copying sizeof(GSVertex) * m_vertex->tail bytes out of them. That length has no relationship to their allocation: the staging arrays are single per-object buffers sized by whichever growth happened to run last, while m_vertex and m_index point at a rotating set of independently sized draw slots and pooled draw-node arrays whose capacities are exchanged thousands of times a second. Two numbers maintained by unrelated mechanisms, assumed to track each other. God of War II crashed on Android 2.6.6 with SIGSEGV inside memcpy on the MTGS thread, in the GIF parse path, on exactly that copy: the buffer whose tail was read had grown to ~50k vertices while the staging array was still the 10k one from init, so the copy ran ~1.1MB past the end. Instrumenting the same scene from a savestate reproduces the mismatch locally at 49108 live vertices against a 10000-vertex staging array (1.19MB), plus 85398 indices against 60000. The over-read only faults where the heap layout puts an unmapped page in range, which is why it hit a tester and not the dev box. The staging arrays are write-then-consume: SetupIA overwrites the full range it stages before anything reads it back, so their contents are dead at growth time and never needed preserving. Drop them from GrowVertexBuffer and give them their own grow-only capacity, established at the point of use from what is actually being staged. That also closes the matching out-of-bounds write on channel-shuffle draws, and removes two dead allocations plus two large dead memcpys from every buffer growth. Rendering is unchanged: per-draw ledgers over two God of War II dumps are byte-identical before and after. gs_draw_staging_tests pins both properties -- growth must not touch the staging arrays, and staging capacity covers the request and never shrinks. Re-listing the arrays in GrowVertexBuffer turns the first test red, and under -DUSE_ASAN=ON it reports the original fault outright: heap-buffer-overflow, READ of size 319904, 0 bytes after a 128000-byte region, in GSState::GrowVertexBuffer.
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