Nintendo DS Static Recompilation Landscape

A general survey of native-code static reconstruction (in the N64: Recompiled / Zelda 64: Recompiled sense) for the Nintendo DS, 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, and this series’ gba-recomp.md, which this document follows on from directly — the DS’s ARM7 side is literally the GBA’s own CPU lineage, and the console can boot straight into a hardware GBA-compatibility mode built around it.

1. Architecture: two real application processors, not a CPU-plus-audio-coprocessor split

The DS is not shaped like the “big CPU + small fixed-function audio coprocessor” pattern seen elsewhere in this series — SNES’s SPC700 (snes-recomp.md) or Genesis’s Z80 (megadrive-recomp.md), both narrow 8-bit chips running a short audio driver that never touches general game logic. The DS pairs two genuine, general-purpose ARM application processors that both run substantial ordinary game code (Copetti’s Nintendo DS architecture writeup):

• ARM9 (ARM946E-S, ARMv5TE, ~67 MHz) — main CPU, 12 KB L1 cache, 48 KB tightly-coupled memory, integrated CP15 MPU. Runs the bulk of game logic and drives the 3D hardware.
• ARM7 (ARM7TDMI, ARMv4T, ~33 MHz) — historically the exact CPU used in the Game Boy Advance, clocked roughly double the GBA’s rate here. Owns I/O: cartridge/SPI, touchscreen, microphone, wireless, sound. It’s a full ARM core running arbitrary application code, not a hardwired peripheral controller — and it’s precisely this CPU that becomes the DS’s entire active processor in AGB (GBA) compatibility mode: the ARM9 halts, novel hardware is disabled, buses redirect, the ARM7’s clock drops to 16.78 MHz (the GBA’s native rate), and it runs the original GBA BIOS and cartridge code directly, with no way back out short of a reset (Copetti). That’s the direct throughline to gba-recomp.md: the DS’s “I/O CPU” and the GBA’s “the CPU” are the same silicon lineage.

Both processors run independently-scheduled instruction streams over their own private and shared memory — genuine asymmetric multiprocessing, not a command/response protocol to a subordinate chip. They communicate via a dedicated IPC FIFO unit (two 16-deep, 32-bit hardware queues, one per direction, with an IPCSYNC handshake register for interrupt-driven signaling) and a shared WRAM block mappable as 32 KB/0 KB or 16 KB/16 KB between the two CPUs via WRAMCNT (GBATEK DS Memory Control, BlocksDS memory map, double.nz FIFO tutorial). Homebrew SDKs also reserve a small fixed structure near the top of main RAM (the last ~48 KB of the 4 MB pool — bootstub, .nds header, ARM9 exception/user-settings data) as a well-known handshake location a recompiler has to special-case; the precise byte offset is an SDK/loader convention rather than fixed silicon. Net effect: two independent lifting targets that must be co-simulated with correct relative timing, closer in kind to Saturn’s dual-SH2 problem than a single-CPU-plus-DSP design.

Layered on both CPUs is the DS’s 3D hardware, its own translation problem distinct from lifting either ARM core. It’s explicitly fixed-function, not a programmable GPU with a shader ISA (contrast PS2’s VU1 or PS3’s RSX, ps2-recomp.md, ps3-recomp.md): a Geometry Engine (matrix stack, transform, lighting, clipping, ~2,048 triangles/frame) fed through a 256-entry command FIFO (GXFIFO), feeding a Rendering Engine that rasterizes to a line buffer rather than a framebuffer, with perspective texturing, Gouraud shading, fog, blending, and Z-buffering (ndsdoc 3D Geometry Engine, GBATEK DS 3D Overview, RadDad772’s engine notes). For recompilation this is a command-stream translation problem — map a fixed, enumerable set of GXFIFO opcodes to modern-API draw calls — tractable the way GameCube/Wii’s TEV combiner or PS3’s RSX/GCM stream are tractable, not an arbitrary-shader-bytecode problem.

2. Existing prior art

Decompilation is the scene’s dominant activity, and it’s overwhelmingly Pokémon-shaped: pret — the same community behind the GBA-era pokeruby/pokeemerald decomps referenced in gba-recomp.md — maintains active DS-generation repos including pret/pokediamond (Diamond/Pearl) and pret/pokeplatinum, plus HeartGold/SoulSilver, Mystery Dungeon: Explorers of Sky, and Ranger: Shadows of Almia, tracked from pret.github.io. Both pokediamond and pokeplatinum are long-running, still-active WIP projects (thousands of commits, live issue/PR traffic into mid-2026) that build byte-identical US ROMs from current source — a direct continuation of GBA-era community norms and tooling, not a separate scene. Neither publishes a headline “percent matched” figure, so the honest 2026 status is “still WIP, non-trivial fraction outstanding,” not a specific number. Non-Pokémon DS decompilation is comparatively thin — no broadly comparable effort (a DS-scale Mario or Zelda decomp) surfaced; the scene’s depth sits almost entirely in the Pokémon lineage.

The more directly relevant find is binary-level static recompilation, and it exists: ndsrecomp, by Matthew Stanley — the same “R.A.I.D.” (Retro AI Development) community author behind SegaGenesisRecomp (megadrive-recomp.md) and SNESRecomp (snes-recomp.md) — turns a legally-dumped DS ROM into a standalone C/CMake static-recompilation project, translating ARM machine code ahead of time for both CPUs on one interleaved scheduler. It’s explicitly labeled “very early pre-alpha (v0.0.1)”, “an experimental developer snapshot, not a ready-to-use emulator or a stable framework.” Demonstrated bring-up: boots both BIOSes to the DS firmware main menu with working touch, and separately gets Super Mario 64 DS (EU rev-0) to its title-screen flow — “narrow bring-up evidence, not a compatibility or gameplay claim,” per the author. Gameplay isn’t supported yet, and lower-screen 3D (Engine B) composition is acknowledged incomplete and currently wrong. Notably, ndsrecomp’s ARM7 handling was ported directly from the sibling gbarecomp project (gba-recomp.md) — a concrete, code-level instance of the DS/GBA continuity this doc opened with.

3. Reference emulators

DeSmuME is the older, historically foundational DS emulator — long the default reference, still active, but generally regarded as secondary to melonDS on accuracy and performance today. melonDS is the modern reference of choice: widely cited as more accurate, with a from-scratch renderer (including OpenGL) that holds fidelity at higher internal resolutions while narrowing its historical performance gap with DeSmuME (comparison). Its source and GXFIFO/geometry-engine documentation are the natural first stop for exact fixed-function 3D semantics.

4. Honest maturity assessment

Relative to gba-recomp.md’s quite-mature decompilation scene, DS is behind, but not by as much as its added complexity suggests, because the same community and conventions carry over directly rather than rebuilding from scratch. The pret lineage is a straight continuation — same org, same tooling, same progression model — applied to larger, dual-CPU, 3D-capable titles that are more work per game. DS arguably starts ahead of a from-zero platform here, inheriting a decade-plus of Pokémon-decomp institutional knowledge, even though non-Pokémon coverage lags the broader GBA scene.

On static recompilation, DS sits meaningfully behind GBA and behind the “early but real” tier occupied by SNES/Genesis/PS3 in this series (snes-recomp.md, megadrive-recomp.md, ps3-recomp.md) — ndsrecomp is real and directly descended from a working sibling GBA tool, but pre-alpha, single-title, and openly incomplete on 3D rendering, exactly the hardware GBA never had. GBA recompilation lifts one ARM7TDMI core against a simple 2D PPU; DS has to co-simulate two independently-timed ARM cores over IPC hardware and translate a real fixed-function 3D command stream — genuinely more moving parts, not just “GBA twice.” DS’s decomp scene rides GBA’s momentum well; its static-recompilation scene inherits GBA’s tooling lineage (literally, via ndsrecomp’s ported ARM7 core) but is still working through complexity GBA’s recompilation never had to solve.