Nintendo 3DS Static Recompilation Landscape

A general survey of native-code static reconstruction (in the N64: Recompiled / Zelda 64: Recompiled sense) for the Nintendo 3DS, not tied to any specific game. Companion docs: ps3-recomp.md, ps2-recomp.md, psx-recomp.md, ps4-recomp.md, amiga-recomp.md, snes-recomp.md, megadrive-recomp.md, saturn-recomp.md, arcade-recomp.md, engine-based-porting.md.

1. Architecture: a security-coprocessor design descended from the DS, wrapped around a hybrid GPU

The 3DS’s CPU story continues the DS’s dual-CPU split rather than breaking from it (Copetti, lioncash’s 3DS ARM docs):

• ARM11 (dual-core, ARMv6k, 268 MHz stock, up to 804 MHz quad-core on New 3DS) is the application CPU and the one that matters for recompilation. Nintendo fixes one core as “appcore” (games) and one as “syscore” (OS), with syscore able to lend the app up to 30% of its cycles — a software-imposed split, not a hardware one, that doesn’t meaningfully complicate lifting versus a single core.
• ARM9 (ARM946E-S, 134 MHz) is not a general coprocessor like PS3’s SPUs or Saturn’s SCU-DSP. Per 3dbrew and Copetti, it runs a microkernel (Kernel9 + Process9) dedicated to cryptography (AES/RSA/SHA/ECDSA), title verification, and I/O, with exclusive access to security hardware — a locked-down security processor games don’t touch directly. In DS/DSi compatibility mode it flips to become the primary CPU running unmodified DS code, continuing the DS’s own ARM9-main/ARM7-legacy lineage. For native 3DS game recompilation the ARM9 side is largely irrelevant.
• PICA200 GPU (Digital Media Professionals, “MAESTRO-2G,” 268 MHz, OpenGL ES 1.1-advertised plus proprietary extensions) is a genuine hybrid, not pure fixed-function: up to four parallel programmable vertex/geometry shader units, but a fixed-function fragment stage — four texture units feeding six configurable “color combiner” stages rather than a real pixel-shader ALU (Wikipedia, Copetti). That fragment stage is architecturally close to GameCube’s Flipper / Wii’s Hollywood TEV combiner model — same “fixed pipeline of configurable combiner stages, no real pixel shader” shape — while the vertex side is more flexible than Flipper’s fixed-function transform pipeline. For recompilation, that means PICA200 command streams are more tractable than a pure fixed-function part (real vertex-shader bytecode to lift), but the fragment combiner state still needs reverse-mapping to shader code, the same problem GameCube/Wii tooling already solves. It’s nowhere near as portable as PS4’s fully programmable GCN pipeline (see ps4-recomp.md).
• DSP: a CEVA TeakLite II-derived core (~134 MHz, 24-channel, up to 32.7 kHz) handles audio, but games almost never program it directly — Nintendo’s SDK treats it as an opaque black box driven by proprietary uploaded firmware (Copetti).
• Functional wrinkle, not architectural: every frame the system renders three framebuffers — two parallax-barrier stereoscopic 400×240 top-screen views plus one independent 320×240 bottom-screen frame — through the single PICA200 pipeline (Copetti). This doesn’t change what needs lifting, but any recompilation target must reproduce dual-viewport, dual-screen output rather than a single video stream.

2. Critical recent context: the Citra shutdown and its aftermath

Citra, the dominant open-source 3DS emulator for most of the platform’s post-retirement life, was shut down in March 2024 as collateral damage in Nintendo’s lawsuit against Tropic Haze LLC (maker of the Switch emulator Yuzu) — Citra shared developers with Yuzu, and the settlement required Tropic Haze to surrender or stop work touching Nintendo’s IP (Hackaday, PC Gamer, Wikipedia). Citra itself was never separately sued, and being GPL-licensed, its code survived even though the original team stopped work.

As of 2026, the fork landscape has consolidated rather than fragmented further:

• Azahar (azahar-emu.org, GitHub) is the dominant successor, formed by merging Lime3DS and Citra alumnus PabloMK7’s fork into one project positioned as “the de-facto platform for future development.” It’s very actively developed (thousands of commits, hundreds of open issues/PRs, a real roadmap and Discord), ships across Windows/Mac/Linux/Android, and reviewers describe strong Pokémon/Zelda/Mario compatibility — functionally the spiritual continuation of Citra rather than a diminished fork (citraemulator.org roundup, Azahar setup guide). Lime3DS as a standalone project has effectively folded into Azahar.
• Panda3DS (GitHub) is notable for being a from-scratch HLE rewrite in C++, explicitly not a Citra fork, started “as a fun project out of curiosity.” It’s real and cross-platform, but by its own README is less mature — “many games boot, many don’t,” widespread graphics glitches — and reviewers consistently rank it behind Azahar in compatibility (roughly mid-60s percent and climbing), positioning it as a lightweight secondary option (Panda3DS Games List, alternatives roundup).
• No other independent 3DS emulator of comparable scope was found; the ecosystem has narrowed to “Azahar as the mature default, Panda3DS as the from-scratch alternative” — a notably healthier post-shutdown outcome than the 2024 panic suggested.

Worth naming plainly: Nintendo’s action targeted alleged DMCA circumvention and monetization, not emulation as a concept, and none of Azahar, Lime3DS, or Panda3DS have been sued as of 2026 — but the community has visibly adjusted its posture (careful language about BIOS/key provisioning, no bundled keys, emphasis on legitimate dumps) in ways that read as a direct, ongoing reaction to Citra’s fate.

3. Decompilation and static-recompilation prior art

Decompilation (source reconstruction, not binary lifting) exists for 3DS but is narrower and shallower than the GBA/DS decomp scenes:

• zeldaret/oot3d targets Ocarina of Time 3D, leaning on the mature N64 zeldaret/oot decompilation as reference. It’s publicly active but, by the team’s own tracking, very early-stage — nowhere near the near-complete state of its N64 sibling (zeldaret org, GBAtemp thread).
• 3dsdecomp hosts several projects: RedPepper (Super Mario 3D Land EU decompilation) is by far the most active; supporting library decompilations (nnsdk, sead — Nintendo’s shared 3D engine, also used on Wii U/Switch) exist but show low, sporadic activity.
• No Pokémon 3DS-generation decomp effort was found. pret, the org behind the mature pokered/pokeruby/pokeemerald/pokediamond/pokeplatinum GBA- and DS-era decompilations, has nothing for X/Y, Sun/Moon, or any 3DS-generation title — those remain closed binaries; the closest public tooling is pk3DS, a ROM editor, not a decompilation. This is a real, checkable gap: the C++-heavy, more heavily templated/optimized codebases typical of 3DS-era first-party titles (versus GBA/DS’s simpler C-with-inline-ASM codebases) raise the bar for the large-scale volunteer matching that made the GBA/DS Pokémon decomps tractable.

Binary-level static recompilation — the ps3recomp/PS2Recomp/N64Recomp school this series tracks, including the R.A.I.D. (“Retro AI Development”) community referenced in the SNES/N64/NES docs — has no 3DS-specific project. A targeted GitHub search turns up nothing resembling an ARM11-to-native or PICA200-command-stream static recompiler; R.A.I.D.’s public output (SNESRecomp, NESRecomp, N64Recomp-derived work like PokemonStadiumRecomp) stops at 16/64-bit console architectures and hasn’t extended to ARM-based handhelds. No credible “3DS: Recompiled” or ARM11 static-recompilation effort, general-purpose or single-game, was found anywhere.

4. Honest maturity assessment

Static recompilation specifically for 3DS is effectively unstarted — no evidence of any binary-level ARM11 recompiler, general or game-specific, surfaced anywhere. That puts it in the same “unstarted” bucket as Amiga and Saturn in this series (see amiga-recomp.md, saturn-recomp.md), but for a different reason than either: it isn’t that the target hardware is exotic or under-modeled (PICA200’s combiner model and ARM11’s ISA are both well-documented, and Azahar/Panda3DS prove dynamic emulation is mature and improving), and it isn’t that a mature decomp base already exists to build from, as PS2’s OpenGOAL effort has (see ps2-recomp.md) — it’s that almost nobody has pointed static-recompilation tooling at 3DS at all, likely because dynamic HLE emulation (Azahar) already delivers strong compatibility with far less engineering risk than a from-scratch binary lifter would require.

Relative to this series’ GBA-through-Switch batch, 3DS is clearly the least mature of the newer Nintendo handhelds on the decomp/recomp axis, specifically because of scale: GBA and DS titles are commonly plain-C-with-assembly codebases that community decomp efforts (the pret Pokémon lineage chief among them) have cracked wide open over a decade-plus; 3DS titles are C++-heavy, more optimized, and compiled against large shared middleware (nnsdk, sead) that itself isn’t decompiled yet — so even source reconstruction, normally the easier predecessor step before binary-level static recompilation, lags badly (RedPepper and oot3d are early exceptions, not a broad scene).

The Citra-shutdown legal climate is a real, distinguishing chill specific to this doc: GBA and DS emulators/tooling were never targeted by Nintendo litigation the way Citra/Yuzu were, so their communities had no equivalent reason for caution. 3DS’s community, by contrast, watched its dominant emulator taken down as collateral damage in an unrelated 2024 settlement, and the visible result — careful legal posturing in Azahar’s and Panda3DS’s own documentation, no bundled BIOS/keys, emphasis on legitimately-dumped software — reads as a community optimizing hard for “don’t attract Nintendo’s attention.” A genuine static-recompilation project would be a far higher-profile target than “yet another emulator fork,” and no evidence surfaced that anyone currently wants to be the one to try it.