Nintendo 3DS in a Browser: Two Days of AI-Assisted Porting, Then the Hard Parts

Yury Gagarin — Sun, 18 Oct 2026 07:50:56 +0000

Cover: AI-generated concept illustration of a hypothetical foldable phone, not a photograph of existing hardware or a screenshot of the emulator.

It started with the idea of a dual-screen iPhone. That form factor seems almost made for Nintendo DS and 3DS games: the main display above, the touchscreen below.

But before thinking about a finished app, I wanted to answer a smaller question: could a 3DS emulator run on an iPhone at a useful speed?

For this experiment, I couldn't rely on giving an ordinary iOS app its own JIT entitlement. So I tried another route: recompile guest ARM code to WebAssembly at runtime, then let the browser engine compile that.

After two days, I had an experimental Panda3DS port running Super Mario 3D Land in a browser. On a Mac, it reached full emulation speed. On an iPhone, things got more interesting.

AI disclosure: AI wrote most of the new port code. I directed the work, ran builds, tested on devices, and helped investigate failures. This article was also prepared and translated with AI assistance. The emulator foundation is Panda3DS, and the CPU recompiler foundation is Dynarmic, built by their respective developers. These two days produced a port of that existing work, not a 3DS emulator from scratch.

Source on GitHub · Try the browser demo

What works today

In Chrome on an Apple Silicon Mac, Super Mario 3D Land and Mario Kart 7 run at 60 fps emulation speed in the tested scenes. Sound, keyboard input, and on-screen controls work.

Actual player screenshot: Super Mario 3D Land on an M-series Mac. This is separate from the imagined hardware in the cover.

Everything runs locally. The server serves the page and emulator; users open their own game dumps. There is no streaming or server-side emulation, and no commercial game data is hosted.

On iPhone, menus and light scenes in Mario 3D Land run at roughly 55–63 fps. The heavy World 1-1 scene only reaches 16–22 fps.

This is still an experiment. Compatibility varies, compiling new shaders can cause noticeable pauses, and some games do not get past startup. Full save states are not implemented, although game-save persistence is available.

You can try the site without a commercial game: it includes free homebrew graphics examples.

How ARM code reaches the browser

Panda3DS uses Dynarmic for dynamic CPU recompilation. The port adds a backend that translates Dynarmic's intermediate representation into WebAssembly.

The path is:

Guest ARM → Dynarmic IR → WebAssembly → machine code compiled by the browser engine.

PICA graphics are rendered through WebGL2.

On iPhone, this runs inside WKWebView without the application receiving its own JIT entitlement: WebKit performs the WebAssembly compilation.

The architecture sounds straightforward. Getting a picture on screen was only the beginning.

Surprise #1: headless testing hid a graphics bottleneck

One scene was bottlenecked by graphics buffer uploads.

In a visible Chrome window on ANGLE/Metal, the existing streaming-buffer path using glBufferSubData took approximately 30–40 microseconds per call. At more than 500 calls per frame, that becomes a substantial part of the frame budget.

Switching to buffer orphaning with glBufferData reduced the upload cost. In one measured scene, emulation speed went from 15–22 to 60 fps.

The awkward part: headless Chrome did not expose the same bottleneck.

For this project, the lesson was practical: automated runs help, but I also need to measure performance with the game actually visible.

Surprise #2: too many small WebAssembly instances

Initially, each compiled guest block had its own WebAssembly instance.

That worked at small scale. In Safari on the Mac, however, performance deteriorated as the number of live instances grew into the tens of thousands.

There was another problem: importing many helper functions consumed executable memory in JavaScriptCore, eventually crashing the page.

The changes were to:

Pack 256 compiled blocks into one instance.
Call helpers indirectly through a shared table, reducing per-module imports.

In one heavy Safari-on-Mac scenario, this brought performance from roughly 19 Hz to 44 Hz.

These are measurements from this project, not a universal WebAssembly optimization recipe. On iPhone, the same changes did not fix the main slowdown.

The unresolved iPhone problem

The heavy scene runs at 16–22 Hz on the phone.

Remove all draw calls, while keeping uploads and the rest of the emulator running, and it reaches approximately 59–63 Hz. That points toward the drawing path, but does not by itself distinguish GPU execution, command submission, and synchronization.

To narrow it down, we recorded the WebGL calls for one frame and built a standalone replay page.

The recording contains:

8,711 WebGL calls.
345 draws: 343 TRIANGLES draws and two TRIANGLE_STRIP draws.

The standalone page replays that frame at approximately 59 Hz on the same phone, even with 9 ms of artificial CPU work added per frame.

Adding a large WASM memory and tens of thousands of live WASM instances does not reproduce the real emulator's slowdown either.

But the recording repeats a single frame. In the real game, texture contents change, render targets are sampled by later draws, and dependencies carry across frames. The replay may be missing an important part of that workload.

The open question is: what needs to change in the replay to make it representative of the live emulator?

The replay is in web/probe-glreplay.html, with the recording in web/glframe.json. Detailed measurements and rejected experiments are documented in the repository.

What two days actually produced

A working browser prototype, with a new recompilation path, graphics, audio, and controls. It can already run games, but it has a long way to go before becoming a mature emulator.

AI made it possible to attempt a volume of changes I would not otherwise have taken on at this pace. A substantial part of the work was verification: does the game boot, does it render correctly, what does a timing number actually measure, and did the latest change improve anything?

The useful result is that the original idea can now be tested on real hardware. Instead of asking whether it is possible at all, I have a running port and specific problems to investigate.

Thanks to the Panda3DS and Dynarmic developers for the foundations of this experiment. The project is GPL-3.0-or-later and is not affiliated with Nintendo or Apple.

If you have profiled WebGL2 on iOS, or seen a similar gap between a captured-frame replay and a live application, I'd love to compare notes.

🔮 I Built an AI Code Fortune Teller with Kiro | Kiroween 2025

Yury Gagarin — Fri, 05 Dec 2025 12:31:15 +0000

# 🔮 Crystal Ball CI/CD - An AI Code Fortune Teller

For Kiroween 2025, I built an AI-powered code review system
that predicts bugs before deployment - wrapped in a mystical
Halloween UI! 🎃

## What It Does

Crystal Ball analyzes GitHub Pull Requests using Claude 3.5
AI and broadcasts predictions to a real-time dashboard:

🔍 Detects SQL injection, XSS, hardcoded secrets
⚡ WebSocket real-time updates
🎨 Mystical Halloween interface with animations
📊 Color-coded scores: 🟢 ≥80, 🟡 60-79, 🔴 <60

## How Kiro Changed My Workflow

### Spec-Driven Development
I wrote specs in .kiro/specs/ defining the architecture,
API contracts, and requirements. Kiro generated
production-ready code that just worked - zero integration
bugs because contracts were defined upfront!

### Vibe Coding for UI
The game-changer: I described what I wanted ("floating
crystal ball with mystical glow", "flying ghost animations")
and Kiro generated 500+ lines of perfect CSS with:

Glass refraction gradients
Rotating mist animations
Random lightning strikes
Individual ghost trajectories

What took days of CSS tweaking took hours with vibe
coding.

### The Combo
Specs for the plumbing, vibes for the polish. Backend
logic needed precision - API contracts, security,
validation. UI needed feel - mystical glow, smooth easing,
ethereal effects. Kiro handled both seamlessly.

## Try It
🔗 GitHub:
https://github.com/gagarinyury/crystal-ball-cicd-kiro
🌐 Live Demo: http://207.180.199.169:5175

The .kiro/ directory has all the specs - see spec-driven
development in action!

## Key Takeaway
Kiro's vibe coding understood intent. When I said "make it
feel mystical," it added pulsing glows, exponential easing,
and layered shadows I hadn't thought of. That aesthetic
understanding is powerful! ✨

May the Crystal Ball reveal only good omens in your code! 🔮

#kiro #kiroween #ai #codereview

DEV Community: Yury Gagarin