J1coding 30d9816eda iOS: resolve the shader catalogue off-device, and sign what it may ship
The half of the downloader that cannot run on a phone: a generator that
turns any preset in a pinned slang-shaders tree into a complete, path-safe,
licence-classified file closure, and refuses to emit anything until a person
has signed the rules it would be built from.

Resolving a closure means walking includes and references across a
5,000-file tree. Over the GitHub API that costs two to five requests per
preset against a 60-per-hour limit keyed to the originating IP rather than
to the app, so every user behind one carrier NAT shares one budget. On a
local clone it costs fifteen seconds of CPU and no network at all. That
asymmetry is the whole design.

emit refuses without a signed rules file recording the pin, so the catalogue
cannot physically exist before the nine class questions were answered. Six
were confirmations of rules the bundled sixteen already ran under. Three had
never been decided and were worth 577 presets between them, and the one that
mattered was whether a LICENSE file governs the directory it sits in --
worth 552 on its own, and exactly the inference the standing rule exists to
refuse. Admitted, with the reasoning in the signed document rather than
here.

Of 2,553 presets in the tree, 867 are offered: 13 dropped on upstream
defects, 8 on an extension the extractor will not write, and 1,665 excluded
by class. Fourteen presets the earlier hand audit had measured agree row for
row on file count and on upstream bytes, which is the free correctness check
on all of it.

The whole-tree run found the divide-by-zero prescale in ten more files than
the two bundled ones, refusing 98 presets. Twelve sites and not ten, because
the scanner reports one per file and clamping the first in crt-potato and
ultra_potato made a second visible in each; the scan was re-run until it
came back empty.

All twelve now carry a notice in the file itself saying it changed and when.
ATTRIBUTION.md covers the bundle and covers nothing once the same file
travels in a zip on its own, which is where GPL section 2(a) asks for the
notice anyway. The first wording of that notice said the change was "one
max() and nothing else", and the guard test looked for max() anywhere in the
file -- so the comment describing the fix satisfied the test that checks the
fix exists. Both were changed: the notice says clamp, and the test now
requires the guard on a line that actually matches the prescale pattern.
2026-08-18 23:41:53 +02:00
2022-11-29 09:46:18 +00:00
2026-07-27 19:48:36 +02:00
2024-01-14 14:18:03 -05:00
2026-04-03 12:41:47 -04:00
2026-07-18 12:04:18 -04:00

ARMSX2 — Native ARM64 JIT Fork of PCSX2

All Platforms

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

Project Demo

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

S
Description
No description provided
Readme
512 MiB
Languages
C++ 68.2%
Kotlin 9.8%
Swift 7.7%
C 5.6%
Objective-C++ 2.2%
Other 6.4%