AI disclosure: most of the new port code was written by AI, with me driving development and testing. The existing emulator and CPU recompiler are Panda3DS and Dynarmic. AI also helped write this post.

I'm working on a browser port of Panda3DS: guest ARM → WebAssembly at runtime, graphics through WebGL2. It also runs in an iPhone WKWebView without a JIT entitlement. I've hit a performance problem that I haven't managed to reproduce outside the emulator.

Environment: iPhone Air, iOS 27.0.1, Low Power Mode off, thermal state nominal during measurement. The rendering path is WebGL2 through ANGLE/Metal in Safari/WKWebView.

A heavy scene in a commercial 3DS game runs at 16–22 Hz on the phone. Here's what I've tried:

• Removing all draw calls, while keeping uploads and the rest of the emulator running, brings it to 59–63 Hz. This points to the drawing path, though it doesn't isolate GPU work from submission or synchronization.

• Recording one frame's WebGL calls and replaying them in a standalone page gives 59 Hz on the same phone, even with 9 ms of added CPU work per frame. The recording contains 8,711 calls and 345 draws: 343 TRIANGLES draws and 2 TRIANGLE_STRIP draws, no TRIANGLE_FAN.

• Adding 256 MB of WASM memory, heap-view uploads, and up to 40,000 live WASM instances to the replay doesn't reproduce the slowdown.

The replay repeats a single captured frame. Suspected differences in the real workload (not established causes):

• Texture contents change every frame, with around 22 texture uploads.

• Render targets are drawn to and then sampled by later draws.

• There is substantial framebuffer churn: 132 bindFramebuffer and 117 framebufferTexture2D calls per frame. The capture includes these calls, but repeating one frame may not reproduce the dependencies across changing frames.

How would you profile this on iOS to distinguish GPU work, WebGL submission overhead, and synchronization? Have you encountered a similar gap between a captured-frame replay and a live emulator? What would you add to the replay to make it representative?

The replay is web/probe-glreplay.html, with the capture in web/glframe.json. Measurements and experiments are in docs/webkit-instances-and-batching.md.

Source: https://github.com/gagarinyury/panda3ds-wasm

Browser demo: https://panda.profy.top — bring your own game dump; no game data hosted.

Happy to run additional experiments or collect traces if someone can suggest a useful next step.

I've been building ppu.toys, a "ShaderToy for the SNES PPU". I posted about this a few weeks ago and I finally finished a video walkthrough of the studio. AI was used extensively when building the website and core wasm emulation.

Watch the walkthrough here: https://youtu.be/4NtyIM-2uLM

This is an emulation of the PPU, the 65816 or SPC700 are not part of the equation. A Lua frame() function writes VRAM/CGRAM/OAM and the PPU registers directly, and per-scanline hooks act like HDMA. The core is headless Rust, compiled to WASM for the browser studio.

How it works:

• Memory is byte-accurate (word-addressed VRAM, 15-bit CGRAM, OAM). Each frame resolves into a 224-row line table: frame defaults, plus scanline hooks
• A per-pixel compositor then renders it: priorities, main/sub screens, windows, color math.
• Supports BG modes 0–4 (with offset-per-tile in 2 and 4) and Mode 7, including EXTBG. OAM evaluation applies the 32-sprite and 34-sliver limits and sets the STAT77 flags.
• A trace inspector walks any output pixel back through the layers and the compositing decision to the BGR555 value.
• The S-DSP is ported from ferris's snes-apu. The site features a full sequencer to create loops

I built this as a playground for myself to really stretch the limits of what was possible on these classic graphic chips. Early experiments on exporting ppu.toys creations to ROMs have been incredibly promising, so stay tuned for exciting updates!

I hope you enjoy the site as much as I enjoyed creating it!

Site: https://ppu.toys

Core + CLI: https://github.com/LioraLabs/ppu.toys (cargo install ppu-cli)

TLDR plz

Sly is my new multi-system emulator, releasing with support for Game Boy Advance and SNES with many, many more planned! It includes a 3D game library, a debugger, a simpler ("classic") desktop frontend and an iOS app, with Android being developed soon. The debugger also runs in your browser and there are plans to create a dedicate web platform to play games!

Available now on GitHub! Here are some demo videos:

• Sly Debugger on YouTube
• Sly Launcher on YouTube

What even is this?

Hey everyone! You might know me from Gecko, the GameCube and Wii emulator I've been posting about every now and then. I teased Sly in the past few updates and the day has finally come :)

With Sly I wanted to work on both sides of emulation: creating modern experiences for both gamers and developers! As such Sly focuses on 2 things:

1. A unique take on emulation frontends, simply to enjoy your favorite retro titles in a cool way
2. A very modern yet extremely advanced debugger for power users that want to understand how the games and the hardware work

However, as not everyone may be interested in these things but may still want to dabble in new projects, Sly comes with extra goodies:

• A "classic" (read: minimal) emulation frontend
• Mobile app(s): iOS is already implemented, Android support is planned

Sly is (almost*) entirely written in Rust, incl. the frontend. The frontend uses GPUI, so no web shenanigans there!! The cores are all written by myself, mostly based off of emulators I had already written before. This does not wrap libretro cores or anything like that!

(* the Classic frontend is written in C++ and the iOS app is written in Swift. They tap into the Rust core.)

Sly Launcher

The launcher presents your library as 3D boxes and cartridges. It downloads artwork automatically and supports different regional packaging, per game release overrides and cartridge finishes (tho this is still a bit ugly lol). There's different view types (ways of displaying the boxes, etc) and you're able to flip the selected box to read the back :)
The attached launcher recording shows all three layouts with GBA games then switches to SNES and launches Yoshi's Island!

The original idea of this project was to be a comfy frontend I could run on my TV while I sit in a nice couch, so it's made with controllers and different resolutions, aspect rations, etc. in mind!

If you'd prefer a straightforward list, Sly Classic is the smaller Qt based frontend. It has game banners, gamepad support, scaling, fullscreen and a quick save slot plus ten numbered state slots.

Sly Debugger

This is a big part of the project and share's the "spotlight" with Sly Launcher! You can step through instructions, run to emulation events, set CPU and memory breakpoints, follow disassembly in a list or graph and inspect registers, call stacks and memory. There are dedicated views for MMIO registers, DMA and so much more. On the graphics side you can inspect tiles, tilemaps, backgrounds, sprites and palettes alongside the game's output.

The SNES core also cover the SPC700 and SA-1 coprocessor! SA-1 and Super FX have their own workspaces with registers, disassembly and hardware-specific views.

There's also built-in Lua editor support!! Scripts can inspect and modify memory and react to emulation events. One example for Yoshi's Island logs coin pickups, lets Yoshi keep "fluttering" mid-air while you hold B and prevents Baby Mario from being release(?).

Compatibility?

Sly is actively growing and is based on multiple emulators I already had written, so cores are being picked up quickly. So far I support:

• SNES support is very good
• Most GBA games run, no audio yet. Savegames are also not supported (tho savestates are)

with much more planned! To name a few I want to support PS1 (next on the list based on community votes), GameBoy (Color), Sega Genesis, Dreamcast, GameCube and Wii! That list is not complete :)

Where can you use it?

You can find everything on my GitHub!

• Windows, macOS and Linux: separate downloads for Sly Launcher, Sly Classic and Sly Debugger
• Web: try Sly Debugger in a WebGPU capable browser.
• iOS: an unsigned IPA for sideloading (planning to release in the AppStore). Android is planned.

For anyone interested in learning the hardware, I've also been working on a 3 part GBA graphics series with interactive explanations and examples from real games! I'm super proud of these blog posts so I'd love to hear your thoughts! Sly Debugger facilitated creating them :) The posts go from bitmaps, tiles and palettes through sprites, blending and windows to rotation, scaling and perspective:

• GBA Graphics, Part 1: Bitmaps, Tiles and Palettes
• GBA Graphics, Part 2: Layers, Sprites and Blending
• GBA Graphics, Part 3: Rotation, Scaling and Perspective

Links plz

• Website
• GitHub / Downloads
• Browser debugger
• Screenshot databases: SNES / GBA
• My blog

If you try it, I'd love to hear what works and what breaks. Please include the frontend, platform, game region/revision and steps to reproduce when reporting a problem. Code contributions are welcome and so is help with design, icons, UI/UX, artwork and cartridge models. Please read the README in full before submitting anything!

Looking forward to see where this will go! And don't worry, I wont abandon Gecko now :)

Hi all,

I am creating a product that would be of interest to people playing retro games and by extension to emu devs.

Let’s just say a “modern home computer”, like a c64 but with arm64, tons of ram and a gpu. And crucially, very, very low input lag.

I was wondering if there was an in-person meetup of emu devs around London where I could show it off, talk it through, and get some feedback and help.

I don’t need a lot of people at the moment, just a bunch of technically minded people to have an informal technical conversation with.

If there isn’t such a meetup and anyone of you is curious, please comment and let’s arrange for meeting up. Date and location will be shared via private messages.

Thank you all for your attention 😀

Amber Folio emulates only the PC that SSI's Gold Box games actually touch, and nothing else: an 8086, EGA, the 8253 timer, the PC speaker, the Tandy 1000's SN76489-family sound chip, and the handful of DOS calls the game makes. Pool of Radiance (1988) runs on it unmodified, overlay manager and all. Source, AGPL: https://github.com/amberfolio/amberfolio

Design choices that might interest this sub:

• CPU conformance. Checked against SingleStepTests/8088 v2: all 323 files, about ten thousand cases each, registers, flags and memory compared after every case. Undefined flags must match bit for bit too, with no masks. Where the Intel manual and the recorded chip disagree, the chip wins.
• One virtual clock. Nothing reads host time. A run is keys, ticks and state hashes, so sessions replay exactly and are committed as tests, with no game content in them.
• Enhancements as "seams". CS:IP breakpoints qualified by which overlay is resident, with native handlers. They fail closed: an unknown binary, or an overlay that isn't loaded, means the seam does nothing. With every seam off, a run's machine state is identical to a build with no seam engine at all, checked by recorded pairs in CI.
• Log, don't fake. An unimplemented instruction or port stops the machine and says where, rather than guessing.
• Facts, not data. The repo holds addresses, offsets and SHA-256s, never game code, data or a disassembly, with a content guard on every commit.

Hosts: an SDL desktop build (Windows, macOS, Linux, from source) and a WebAssembly build. The web one runs at https://amberfolio.org in desktop browsers and on iPhone, iPad and Android, from your own GOG or Steam copy; the files stay in the browser.

Built with heavy use of AI coding tools (Claude Code, exclusively), and I'd rather say so here than have someone find it. Not affiliated with the games' rights holders.

I'm a UEFN developer and just created my first emulator, which effectively started out as a port that went further and further as I started understanding the concepts and things started actually coming together really well!

It runs both in UEFN (in a Fortnite session) and as a standalone app if you have a build of the Verse CMD tool. Not very fast at all (30hz max it seems, and it struggles to quite reach that...) considering the language and lack of profiling tools available on the standalone... but really cool that it's possible! Just DMG for now but I'm thinking about expanding it to support CGB next.

Repo: https://github.com/Ep8Script/VerseBoy

Video: https://twitter.com/Ep8Script/status/2110781973082108113

Does anyone have experience in this field? I would like to learn assembly instructions specific to the system. Mips I want to modify PlayStation 2 games using a tool. IDA pro

Pokemon revamped is a fork of the Obentou Emulator that allows you to play first gen pokemon games at maximum resolution of your device, exceeding the classic 160x144 gameboy PPU resolution.

FULL AI DISCLOSURE: I´m a lawyer from brazil, my bg in programming is a little bit of basic and assembler from the 80´s and 90´s while trying to make things run on a msx, so, not much...in the beggining of the project i coded a few hundred lines in android studio by myself while i was learning how to do it, but after i discovered the wonders of Codex and Claude Code, the coding and documentation itself was primarily done by AI, and i do not regret it by one bit! It would take a long time to post my inspirational story, but thats the TLDR.

Hello there! General Kenobi here(not really, but i know you read it on ewan mcgregor´s voice!)!!! After a really busy week on the app launching, i´m just chilling for now! Just celebrate my marriage aniversary and got really really drunk on the weekend! So, No new features, but wait!!!!! i just make a comparison video and updated to youtube! hope you guys like it, its just so i dont lose the momentum!

On a completely different note, i hav to decide what course to pursue, some things are natural, greater image quality, lower latency, lower cost... but maybe some other things:

1- Multi Frame Generation: Maybe it seems like the biggest step, but actually is the easiest... all the work is done, the estimator and the basis for the synthetic frame, it has the same base(a pair of reals) and is just some adjustments on the algorithim to change the point to generate the frames... buttttt... i dont really see the value in it... like 4x fg.... 75% of the image are synthethic frames... theres no miracle... one other thing is like 3x 40-120 for 120hz refresh rate.... so.... maybe... but dunno.

2- Integrated temporal AA +upscaler or Temporal super resolution: Some aspects of frame generation already provide some data to upscale the image with a higher quality, but not so much... I think it can be done on some level (somethings a inherent to in game engines implementations, but we can extrapolate and try to infer it, like subpixel jitter), so... that doesnt mean it will look good or hav good performance... but one candidate is arm ASR, wich is based on fsr2, dunno if i can develop my own on this case.... well.. thats it... tell me what you guys think!

3- Implement ZeroFG in a lighter emulator: The title say it all, i think that maybe try to implement on a lighter emulator to reach more people! If you guys have any suggestions, Please let me know!

Thats it! please let me know your suggestions!

Thanks for all the love!!! And dont forget that you can port ZeroFG to your favorite emulator by yourself also! It is as easy as it will ever be, with lots documentation and integration notes!!!

StevenMXZ turnip drivers are still highly recommended!!!!!

https://github.com/StevenMXZ/Adreno-Tools-Drivers/releases

Xendroid-ZeroFG releases page:

https://github.com/hy300leosquizz-ctrl/XenDroid-ZeroFG/releases

Engine:

https://github.com/hy300leosquizz-ctrl/ZeroFG/

So I'm a begginer-intermediate programmer and want to get into EmuDev, make a Chip8, then an N64 emulator.

But should I start with C and Assembly or can I go straight to high level languages like C++?

I can't find a roadmap or explanation.

After many months of thought SkyEmu has officially decided to adopt a no AI code policy.

As of right now all code in SkyEmu has been written by a human and we will not accept PRs of AI generated code.

We understand the utility in AI assisted development and still allow AI to be used for debug, code understanding, and other purposes that do not yield generated output into the repo.

We did this for a couple of reasons:

• AI generated code review is generally substantially more challenging than code review of code authored by humans and has questionable copyright ownership.
  
• We really want people to understand code that gets submitted to the emulator as many changes are interconnected. The knowledge of the changes made by AI tends to disappear when the context does. While human knowledge persists, even if an AI was used to teach the human how to make the changes.
  
• Code quality standards of many projects have substantially reduced after the incorporation of broad scale AI usage from the two above issues.
  
• Developers who wish to add functionality using AI tooling are generally very enthusiastic about the software and emulation development overall. However, they feel lost in the complexity of modern emulators. AI code generation robs them of the ability to learn how to make these changes and robs the community of the next generation of emulator developers. For this reason, we still allow AI to be used as a teaching aid for people who wish to contribute, but don't allow it to do all work for them, but instead encourage its use to help them navigate the complexities of the project so that they can grow their skills and are able to contribute themselves.
  
• It has come to our attention that SkyEmu is one of the handful of large emulator projects in active development that does not have any AI generated code, and we would like to keep it as an option for usage by people who prefer non-AI generated SW.
  

We understand this may be controversial, but believe this is the best pragmatic action, given the needs of our development team and the wider community.

https://reddit.com/link/1x3dxmw/video/nvqwvbnmhvuh1/player

This is a follow-up to my last post. The big problem last time was games like Doom that keep rewriting their own code in RAM. Those run at full speed now too.

The code is up:

- gpSP with the RISC-V (RV32) JIT: https://github.com/midworld/gpsp

- ESP32-P4 board code with game loading and saves: https://github.com/midworld/gpsp-esp32

Hardware is the same as before. Waveshare ESP32-P4-NANO at 400 MHz with 32 MB PSRAM, a $5 ST7789 320x240 SPI screen and an 8BitDo with its 2.4G dongle. LCD and speaker are on and frameskip is off.

The main fix is self-modifying code. When a game writes to code in RAM the JIT doesn't throw everything away anymore. It invalidates single blocks and brings them back later, and it patches code in place when it can. It also learns the spots a game keeps rewriting, like branch slots, so writes there don't cause a retranslation. Doom II rewrites its code constantly. A JIT that drops and retranslates on every change can end up slower than an interpreter on games like that.

I also added 2x/3x fast-forward, which you can see in the video. Light games like Pokémon have enough CPU left to go past 300%, but I capped it at 300% for the video. Need for Speed Underground runs at full speed but the FPS counter doesn't show 59.7. I think the game just limits its own frame rate.

Honestly, once things were somewhat optimized I could have reached full speed easily by moving rendering to the second core. That felt like cheating to me so I kept going until emulation ran at full speed on one core. I used Zba/Zbb/Zbs, which only gave about 1% all together. Not useless but I wouldn't do it again. RVC/Zcb helped a lot more. RISC-V took off after I left school and I'd only studied older ISAs, so this was all new to me. Mixing 2-byte compressed instructions with normal 4-byte ones was the fun part. I had to rewrite every piece of code that assumed branch targets were 4-byte aligned. In return the code got smaller and fits the cache better. Doom got about 7% faster from that.

Another reason I stuck to one core is that I want the other one free for scaling and shader effects on a bigger display. I ordered a larger screen and I'll probably try using the second core for screen effects when it arrives. The P4 has its own SIMD extension called XespV. GBA emulation had almost no use for it beyond a bit of affine background work, but it might be fun for scaling or shading. The P4 also has a PPA block for scaling.

About the new ESP32-S31. It runs at 320 MHz instead of 400 MHz, so the clock is 20% lower, and it has no L2 cache. Hot data would have to go into SRAM by hand. On the P4 just going from 128 KiB to 256 KiB of L2 made things about 30% faster. The S31 also has less SRAM and its PSRAM is 8-bit instead of 16-bit, so half the bandwidth. My guess is it ends up at roughly half the P4's speed. Getting full speed there will probably mean moving rendering to the second core. That won't help much for games like Doom II though. They barely use the GBA's tile and sprite hardware and draw everything with the CPU, so they might not reach full speed on the S31.

Other changes:

- The ROM cache used FIFO replacement and was very slow when the cache was small. It uses clock replacement now and anything over 1 MiB is reasonably usable. P4 boards usually have 16 MB of PSRAM or more so it doesn't matter much there, but it could help on devices with less RAM.

- Fixed the timing issue behind the well-known Hamtaro: Ham-Ham Heartbreak hang. Timing is closer than before but not exact, so other ROMs may still have issues.

- Less sound noise and fixes for bugs when switching games without unloading the core.

Video: https://www.youtube.com/watch?v=Z_ojDzy8Sz4

Previous post: https://www.reddit.com/r/emulation/comments/1wx3tg6/esp32p4_runs_gba_at_full_speed_597_fps_with_no/

So I'm a beginner programmer, I've dabbled in it for a bit, tried many languages over the years but got stuck in tutorial hell every time and quit. I want to be serious this time around.

I'm strictly a hobbyist, I want to eventually write a PS1 emulator. So which of these languages is better for me to learn? I keep being warned that C++ is so unsafe you can get to a point where you can spend months searching for a single faulty line to fix a bug if the project is sufficiently big.

That sounds like....hell. But I still see everyone using it. Is it really that bad?

So i have the goal to learn how to program for a while since i discovered video games but every time i try to learn it but i get bored FAST

I dont wanna push throught the bordom cause i might get burned out and give up on this dream

Am not looking for a miracle i just need to make sure that am not wasting my time and actualy learning how to get hooked into programing i just cant find a hook that keeps me pushing an objective

Then i remember emulators i was alaways curious about emulators when i was a kid they looked like black magic

I need to understand how they work and make my own

Rn all i know is very basic knowledge about c (prinf scanf while if switch case hexadecimal and binary code ) just the beginer levels i leanred in school

My question are :

Where do i start ?

When do you personaly think its stopes being boring ?

How long should the sessions be ?

Do i have to push throught boredom?

How

My goal : learning how the nintendo ds works

And Creating an emulator for it

My dream : creating the ultimate nds emulator i want to make the next desmum / melon ds / no$gba

The emulator: a 6502 with cycle counts, PPU drawing at dot 256 of each scanline with real scroll registers (mid-frame splits and status bars work), 8x8 and 8x16 sprites, sprite 0 hit, vblank NMI, mappers 0/1/2/3/4/7/9 (MMC1, MMC3 with its A12 scanline counter, MMC2), and the APU (lengths, envelopes, sweeps, triangle linear counter, noise) driven into a sound chip that's part of the circuit. Passes nestest (5,003/5,003) and blargg's instr_test-v5 official set.

The host is the unusual part. It's compiled bare-metal for RV32IM and runs on TINY-32, a 32-bit RISC-V CPU built gate by gate inside my circuit simulator. The CPU passes the official riscv-tests. Every 6502 instruction turns into RISC-V instructions, which turn into gates switching, about 1.4 to 2 million RISC-V instructions per NES frame at 60 fps.

Video is raw and real time on a 6-year-old PC (Ryzen 5, GTX 1650, the whole thing sitting around 17% CPU and 400 MB RAM) and an M2 MacBook Air with 8 GB and no fan.

Source, linker script, startup code and build steps:

https://github.com/PlangoDev/tiny-nes

No ROMs included, use dumps of carts you own.
(Had to add this for legal reasons since Tiny Logic is a paid game and I’d hate to become the next target of a Nintendo Takedown)

Happy to dig into the PPU timing, the mapper work, or how the simulator gets a gate-level CPU fast enough for this.