3.17 billion tokens, a $4,974 API bill, and 24 calendar days. Guided by a single human engineer orchestrating one persistent session and 147 specialized subagents, the project successfully ported the Nintendo 64 classic F-Zero X to the Nintendo 3DS handheld. The New 3DS runs the game at a locked, native 60 frames per second in stereoscopic 3D, while the legacy Old 3DS—clocked at a meager 268 MHz—has also been brought up to speed.
In the retro homebrew community, decompilation-based source ports typically take years of sustained effort from loose collectives of volunteer developers. The G-Diffuser on 3DS project compressed that delivery timeline to just over two weeks of active coding. While automated code generation eliminated months of mechanical scaffolding, it also pushed the real engineering challenges squarely under the spotlight.
Writing boilerplate code quickly became a secondary concern once automated pipelines took over. The genuine engineering abyss opened during real-world hardware performance attribution under heavy load. Only when developers leveraged on-device hardware performance counters to confront the physical limits of the instruction cache did the system make its crucial leap from a sluggish 10 fps to a locked 60 fps.
One Engineer, 147 Agents: From a Black Screen to 60 FPS in 24 Days
The project kicked off on August 11, 2026. Building on top of the community’s decompiled F-Zero X codebase, the developer constructed a single-operator agentic pipeline. The upstream game logic remained intact; the porting effort concentrated almost exclusively on building a hardware abstraction layer tailored to the 3DS architecture.
The first phase spanned 24 calendar days, though only 15 of them saw active development. The sprint was halted three times after hitting model providers’ weekly rate limits. Even with those pauses, the codebase progressed from an unbootable black screen on August 11 to a release-grade New 3DS build running at 60 fps by September 3.
The orchestration hierarchy paired a primary coordination session with 147 discrete subagents dispatched concurrently across granular tasks. This division of labor absorbed the heavy manual lifting of initial scaffolding, giving a solo developer the throughput of a small engineering squad.
Figure: In-race gameplay on New 3DS hardware in v1.0.0: the bottom screen runs DASH, displaying energy, race position, lap times, and the course map. Source: G-Diffuser on 3DS Post-mortem
Legal compliance was engineered into the project from day one. The final distributable binary contains zero copyrighted Nintendo game ROM data or proprietary disk images. Instead, the runtime dynamically loads assets provided by the user directly from the SD card, neatly sidestepping potential copyright disputes.
3.1 Billion Tokens for 15,000 Lines: Where Emulators Deceive
The initial 24-day sprint consumed 3.17 billion tokens—amounting to roughly $4,974 at published API list prices. In return, the pipeline generated 15,039 lines of native C/C++ code and 48 iterative patches under the port tree.
Getting code to compile and run, however, is a far cry from a playable racing title. When the game first reached an in-race state in an emulator on August 14, performance hovered between 12 and 20 fps. The first hardware test on August 21 showed notable progress at 48 to 50 fps, yet remained noticeably shy of the rock-solid 60 fps target essential for a high-speed arcade racer.
A grueling sequence of micro-optimizations followed. By September 2, baseline benchmarks on New 3DS hardware recorded a median of 51.3 fps, with 10th-percentile (p10) frame rates dropping to 39.2 fps and only 9% of frames hitting the 60 fps ceiling. By this point, profiling in emulators showed smooth execution curves that completely masked the real silicon’s latency bottlenecks.
The developer launched five consecutive architectural iterations. Introducing a fast bridge output cache nudged median performance to 57.2 fps. Subsequent passes overhauled HUD texture atlasing, optimized triangle submission buffers, and streamlined audio mixing, raising the p10 baseline to 48.0 fps. Finally, offloading the render thread to the console’s third CPU core, enabling “Ahead” projection, and scaling rival vehicle detail pushed the final median frame rate on September 3 to 59.6 fps.
Figure: The 64DD Expansion Kit Select Mode (COURSE EDIT, CREATE MACHINE) running on New 3DS, with DASH idle on the bottom screen. Source: G-Diffuser on 3DS Post-mortem
Dropping to 10 FPS on Silicon: The Instruction Cache Trap
With New 3DS support stabilized, the second phase turned toward the severely constrained legacy hardware: the original Old 3DS. Armed with an underclocked 268 MHz ARM11 CPU and just 64 MB of accessible application memory, retro developers had long deemed locked 60 fps 3D racing on this machine an impossibility. Work branched from the main tree, with parallel agent sessions tasked with aggressive memory trimming.
Hardware testing on September 29 delivered an immediate reality check. The New 3DS binary crashed instantly on boot, while an aggressive memory-reduced build barely limped into the race, crawling at an unplayable 10 fps. Performance assumptions extrapolated from desktop emulators had collapsed entirely.
Traditional software optimizations quickly plateaued. The team narrowed audio mutex contention, freeing roughly 20 milliseconds per frame, and introduced dynamic frame-skipping to prevent slow-motion desyncs. Yet base rendering times on real silicon refused to budge.
The breakthrough came between September 30 and October 1. The developer hooked into the ARM core’s on-chip hardware performance counters to gather instruction-level execution telemetry. The diagnosis was unambiguous: the engine was not choking on raw instruction volume, but drowning in massive cache misses across the ARM core’s minuscule 16 KB L1 instruction cache.
Faced with this roadblock, the agent fleet promptly proposed a compromise: an interpolation-based pose replay pipeline that sacrificed real-time responsiveness to preserve frame rate. While technically complete, the human lead rejected the concession outright, insisting on pursuing native, uncompromised 60 fps rendering.
Rebuilding the Pipeline: Full Speed Across Two Console Generations
Armed with accurate architectural insight, the engineering direction shifted completely. Instead of shaving instruction cycles, the team redesigned the engine around cache locality. On October 1, work began on a custom native rendering interpreter.
The original porting layer relied on the N64’s legacy display list interpreter, which walked sprawling display lists every frame, triggering massive code footprints and frequent branch jumps. The native renderer bypassed generic geometry traversals entirely, replacing them with specialized, compact rendering loops per game entity (vehicles, tracks, Billboards). The critical path of each loop was strictly budgeted to fit entirely within the 16 KB instruction cache.
Figure: Selecting Blue Falcon on the Select Machine screen, launched via the Homebrew Launcher (.3dsx). Source: G-Diffuser on 3DS Post-mortem
The payoff was immediate. On the Old 3DS, median frame time in 2D Grand Prix races plummeted to 16.5 milliseconds. The performance gulf between console generations evaporated once the code aligned with the hardware’s memory hierarchy.
Over the next two weeks, the team implemented per-eye stereoscopic rendering and adaptive v-sync pacing. Outside of two extreme geometry-heavy circuits where a smooth 30 fps fallback activates, the legacy Old 3DS sustains 59 to 60 fps across almost every track. A unified codebase now produces three release builds spanning both hardware generations.
In the Age of Agents, Engineering Attribution Is the Real Divide
The G-Diffuser on 3DS project serves as a compelling study in modern AI-assisted engineering. Autonomous agents demonstrated astonishing speed at modular assembly, boilerplate synthesis, and rapid prototyping, dramatically lowering the activation energy for complex reverse engineering. Yet without grounded hardware feedback, agents easily fall into loops optimizing toward local false minima.
Smooth execution inside an emulator frequently obscures physical cache thrashing and bus contention. When the project stalled at 10 fps on actual silicon, no amount of generic prompt engineering could deduce the root cause without hardware profiling. Isolating the 16 KB cache boundary out of hundreds of thousands of instructions required a human engineer grounded in computer architecture.
This 43-day project clearly delineates the division of labor between human and machine. A fleet of autonomous agents can rapidly haul bricks, assemble scaffolding, and execute exhaustive code changes. But the decisive levers that make or break an ambitious system remain first-principles causal attribution and architectural courage.
References:
- G-Diffuser on 3DS Project Post-mortem
- Hacker News Discussion
