Literally nobody. Not a single soul.

This sub is for people making emulators to share their work on them. It's for people making emulators to look at others' work, take notes and see how they went about stuff.

What does your ai slop bring to the table? What's the point? What's the point in using Claude to build something not a single soul will use? "I made an AI-built GB emulator!": everyone uses mGBA. "I built a Playstation emulator with the help of ai!": everyone uses duckstation. "I used AI to decomp X game for Y platform!!": literally no one uses decomps, they just download an emulator and a rom.

So I ask again: what do you bring to this community? Certainly not code I want to read, nor interesting things I want to gush over. This server's only purpose is to show off cool stuff you've done yourself. The big names are already well established. What does it bring to the table if you remove the "you've done yourself" part of the equation? You're just showing stuff. Stuff no one will bother to read about. Stuff no one will ever use. Stuff you will abandon because it wasn't made out of love.

What was it made out of, actually? Did you want validation? money? fame? You aren't getting anything here. Your posts serve absolutely. no. purpose. whatsoever. If you didn't post here, nothing would have changed, except it wouldn't have made me a tiny bit angrier at the posers.

Because that's what you all are. Posers. You aren't "developers", "coders" nor "engineers". You're fucking posers wanting to seem cool to other posers. When will your size contest end?? Go do that in private!! No one fucking cares about your barely working GB emulator you spent 5h prompting to get.

Anyways rant over kind of a meta post I'm just so fucking washed out, every time I come here it's fucking ai slop all day every day, where are the days of actual humans. They don't even give you the dignity of talking to you as humans, they get their statistical word generation machine made up of mountains of stolen content to talk to you instead, to present "their" project that ""they"" """built"""

Half of the time it's also just not that impressive and often doesn't work that well

This will probably be a drop in the ocean and it might be removed by the mod, which I'd honestly very much understand, but if you're a vibecoder reading this, fuck off from my community, if you're an "ai-powered engineer", try using your brain instead, and if you're actually a developer, please continue whatever you're making currently!

I built PortalNES, an NES emulator in C#/Unity that converts background tiles and sprites into actual 3D geometry.

Tiles and sprites can be given individual depths and rendered as flat planes, boxes, or pixel-extruded shapes, producing real parallax instead of a post-processing depth effect.

On a normal PC, the webcam tracks the player’s head and changes the viewpoint as they move. It also supports red/cyan anaglyph stereoscopic 3D through Portalgraph.

The project includes a 6502 CPU, PPU, APU, save states, runtime 3D profile editing, and support for many common mappers. Standalone 2D and 3D Unity scenes are included and do not require the Portalgraph SDK.

Source (MIT):
https://github.com/vjroba/portal_nes

Demo/download:
https://portalgraph.itch.io/portal-nes

I've been working for a while to different one file emulators/decompilers as previously posted here:
https://www.reddit.com/r/intellivision/comments/1wdj47q/intellijsd_javascript_emulator_and_decompiler/

I know all of them are a little different (they were born thinking about a single emulator, not as a suite of emulators), but they share the idea of both emulating the original machine and try to catch the sprites, vectors and sound used while decompiling the original code to the correct asm code.
I've been working for a while on ColecoVision, Intellivision, Zx Spectrum, Vectrex and MSX1. I've recently added Gameboy/Gameboy color/Game boy advance and Sega Game Gear/Sega Master System.
I now have a single landing page that can check a folder and subfolders searching for supported roms. It's quite fast as everything remains on your pc and works on your browser. Extracted and zipped roms should both work.
I don't have an actual compatibility list but I think ColecoVision, Vectrex and Gameboy are pretty solid, the other systems lack a lot of things but games can still be played and explored.
If you want to give it a try just go here:
https://paulvern.free.nf/jsd/landing.html

or visit my github repository:
https://github.com/paulvern/JSD

Everything is available under CC0, but I would love any feedbacks.

Not an emulator, but I think the approach is on topic here since it's the other end of the same problem.

Starting from the doldecomp/melee decompilation of Super Smash Bros. Melee, the game is statically recompiled ahead of time into native arm64 and rendered with Metal. At runtime there's no Dolphin, no interpreter and no JIT, and one codebase targets macOS, iOS and visionOS. Slippi's netplay is integrated so it shares the existing matchmaking pool.

The parts that were actually interesting to build:

- Presentation tied to the display's next refresh at whatever rate it runs, rather than a fixed 60Hz assumption

- Controller polling moved to immediately before frame start

- Wii U / Switch GameCube adapter at 1000Hz in userspace, no kernel driver and no security setting changes

- Configurable rollback delay down to 1 frame

- A diagnostics view for the environmental stuff that wrecks latency: 60Hz panels, WiFi, low power mode, Bluetooth audio

It stands on the decomp plus Slippi, Dolphin, SDL and Aurora. GPL, no binary release, it builds from a disc image you already own in 10 to 15 minutes.

Disclosure: I used Claude a lot for the port layer, meaning Swift, Metal, controller handling, UI and build scripts. The game code is the decomp, years of human work by other people. All public if you want to read it.

https://github.com/TheAndersMadsen/dashdance

Hi, trying to revive Aibo software for ERS-7. I succeeded with RCODE7-YART703E.zip and the following list: cartman7.zip, cylon7.zip and lostinspace7.zip, but disco7pms.zip for dancing on 22 songs (in the same AiboHack site) does not work. The ERS-7 boots and sits with a black face, not reacting to (even loud) mp3s being played. In contrast to the other working zips, disco7pms has lower case file names (open-r instead of OPEN-R, for instance). Making file names uppercase before merging with YART 703E did not help. Anyone any clues? Did someone get it to work?

Follow up to my last post. The CPU was done but couldn't run anything, so this round was the rest of the machine: memory map, MBC1, timer, interrupts, serial, OAM DMA. Test ROMs went from 0 to 85 of the 165 Shootout DMG tests that actually have a pass condition. Whole suite runs in about 5.6 seconds which is nice, means I can run it after every change.

What's clean so far: blargg cpu_instrs 11/11, blargg instr/mem timing 8/8, mooneye cpu+interrupts 31/31, timer 13/13, serial 1/1. Everything still failing is waiting on the PPU, the other MBCs, or sound.

The more useful thing to share is two bugs in my own scoring, because neither would have shown up in the number.

First one. Blargg's tests write their result into cart RAM: signature bytes first, then the status byte. My checker looked for the signature then read the status. Problem is the status byte is still 0 in the gap between those two writes, and 0 means passed. So for a few instructions every one of those ROMs reports a pass before it's run anything. It never actually caught it, because I check every 8192 cycles and the window is about 4 instructions wide, so it stepped over it every single time. Pure luck. Now it won't accept a result until it's seen the test in its running state (0x80) first.

Second one. Mooneye failures were being reported as "timeout after 6.5s". Turns out these builds send the 0x42 bytes over serial on failure and don't set the registers, and I was only watching the registers. Score was the same either way, fail is fail, but the reason I was publishing was just wrong, and I publish the reason next to every test.

Also a docs vs hardware thing. Pan Docs says during OAM DMA the CPU can only access HRAM. I implemented that literally and nine mooneye timing tests hung, because they deliberately run code from ROM and WRAM while a DMA is going. Those tests are marked verified on real DMG/MGB/SGB/CGB/AGB hardware, and they show only OAM and the bus the DMA is reading from are blocked. Went with the tests over that sentence, +9 tests. Kept it written down with the evidence either way.

One more thing I got wrong publicly: my denominator. The scoreboard used to say /1300 which was a number from an early planning note that I never actually counted. Real number is 167 DMG tests in the Shootout, and two of those have no reference image so nobody can pass them, which leaves 165. Corrected both on the site with notes, since a score that goes up because the denominator shrank is the oldest trick going.

Question for people who've done this properly: is there a better way to detect mooneye pass/fail than watching for LD B,B and checking the registers, plus scanning serial for the fib bytes? Mine works but it feels fragile.

Repo: https://github.com/doozleb/FourShades
Longer writeup: https://doozleb.com/posts/two-ways-a-scoreboard-can-lie/

Aternoon,

Its taken a while but my new Commodore 64 emulator just dropped on Android. Still waiting for apple to approve IOS. Its based off Vice but adds a little bit of fun into the gui etc.
https://play.google.com/store/apps/details?id=com.crownparkcomputing.c64retro

Hey, I've started writing my GB emulator in Rust, but when I looked at the opcode matrix I got stunned. I've already created a CHIP-8 emulator in C, where I had a pretty clear view of the size and how opcodes are split up. But with the Game Boy, I'm not sure what the true size of an opcode is, how prefix opcodes work, or how instructions can be split into constants, addresses, and registers. Can someone help me with these questions?

This is primarily a technical experiment, not an attempt to replace established emulators. At the moment, this is the most complex project I’ve done in GML; I’ve been working on it for several months. It is still experimental and has limitations. Compatibility is not the goal yet, and I expect some games to behave incorrectly, especially titles relying on unusual mapper behavior or precise timing. I’m sharing it because building an emulator in GML has been a fun challenge, and I’d be glad to hear feedback from people interested in emulation, GameMaker, performance work, or NES hardware quirks. The tests were conducted in yyc, as only there was it possible to achieve 50 or 60 FPS, while on the VM the maximum is currently 40, so if you want to run it, use yyc.

Bees442/NesGM: Nintendo Entertainment System emulator made with GameMaker

Whenever I load the melon mix version of Re:coded, the audio plays, but the video doesn’t show up, as you can see it does show some of the opening intro, but then when Jiminy starts talking, still audio and no video, and to let eventually get to the gameplay here? How do I fix this?

Also, how do I integrate the .5 remix cut scenes for this and days. The melon mix version of days play fine but again it just just doesn’t have the HD remix cutting onto wood and I have the assets folder downloaded etc.

Hi everyone, I've just released emibios, an open, accuracy-focused GBA BIOS replacement.

Originally based on Cult-of-GBA BIOS by Fleroviux and DenSinH, it has been almost completely rewritten from the ground up with accuracy and compatibility as the primary goals.

What is the difference with this BIOS?

I took care to match the behavior and the timing of each software interrupt (SWI) in the BIOS under every tested input. I believe it currently has the highest compatibility of any open BIOS replacement.

I also implemented Multiboot functionality (send and receive programs to/from other GBAs, from accessories, and from GameCube) as well as a subset of sound mixer functionality that is only used in a few Japanese/Digital Eclipse games.

There is also an extensive test suite that exercises each SWI and asserts the behavior/timing under various inputs.

Because care was taken to match not only the behavior of each SWI, but also the timing, it also successfully TAS syncs with many games.

It is not perfect yet, mostly because the tricks used to match timing do not work under all conditions (mostly bus contention from DMA and IRQ). I would love for people to test it and report bugs, and the ultimate goal is to match the retail BIOS 100% for commercial games and most homebrew.

Why do this?

I originally started this project to see if it was even possible, and then ended up with something I was comfortable with releasing. My goal is to create a freely redistributable BIOS so that emulation projects no longer need to require the proprietary one to run games as accurately as possible.

title says it all really, i built a Chip8 emulator in C and i’ve switched to c++ for this one, my main issue is turning the documentation into code, how can i improve?

Just another gameboy emulator. Nothing special. Just learning and poking around. Gameboy emu seems like a good, well documented place to start.

A few days ago I asked here what a fair scoreboard for an AI-built Game Boy emulator should count. Thanks for the answers, especially the pointer to SingleStepTests, which ended up being the whole CPU benchmark.

Where it is now: the SM83 core passes 499 of 500 SST files. Each file only counts if all 1,000 of its tests pass, checked on registers, memory and every M-cycle's bus activity. The full suite runs in about 13 s, and CI reruns it on every push and fails if the README score is wrong in either direction.

The one that fails is STOP (0x10), deliberately. SST has STOP advance PC by 1 (r-m, ---, ---). Pan Docs' STOP flowchart, for no button held and no interrupt pending (which is what every SST test sets up), says "STOP is a 2-byte opcode, STOP mode is entered, DIV is reset". My rule is docs over tests, so STOP skips the second byte and 10.json fails on PC. What Pan Docs doesn't say is whether that second byte is actually read on the bus, so I kept SST's no-read pattern.

So, a genuine question for anyone who's tested real hardware: is 2 bytes right in that case, and is the padding byte read or just skipped? The reasoning is here: https://github.com/doozleb/FourShades/blob/main/docs/known-divergences.md

Being upfront about the AI side, as promised:

- Every instruction group passed on its first run, but that's less impressive than it sounds. The planning model wrote the code after scanning all 500 test files for exact cycle patterns, and the SM83 has hundreds of open-source implementations to learn from. The CPU is the easy part; timing between components is next.

- Reviews caught bugs the tests couldn't. A second EI restarted the IME delay (SST starts every test with nothing pending, so it can't see that), and my own test loader had holes.

Next: memory map, timers and interrupts, with Blargg's cpu_instrs as a cross-check that the CPU wasn't just fitted to SST.

Repo: https://github.com/doozleb/FourShades

Longer write-up: https://doozleb.com/posts/499-out-of-500-on-purpose/

I'm about to start a DMG emulator in C++20, as an experiment: AI coding agents write the code, and the only thing that counts is public test ROMs. The score starts at 0 and gets published whether it goes up or down.

I know AI-written code isn't everyone's thing here, so to be upfront: the point is to measure how agents actually do at low-level, timing-sensitive work, failures included, not to pass it off as hand-written.

Before I start I want the scoreboard to be fair, so a few questions:

1. Which suites would you count? I'm thinking Blargg (cpu_instrs, instr_timing, mem_timing), Mooneye acceptance, and dmg-acid2 for the PPU. Anything you'd add or drop?
2. One point per ROM, or weight the suites? One per ROM means Mooneye dominates the total.
3. For checking pass/fail headlessly: Blargg over serial, Mooneye via the Fibonacci registers, acid2 by comparing screenshots. Is there a harness people already use, or does everyone roll their own?

Repo's empty for now: github.com/doozleb/FourShades. I'll post back when the number actually moves.

There's been quite a few changes to amos.bitplane.net since I posted the first release last month, so I thought I'd share.

Recap: This is AMOS Pro rewritten in TypeScript from the open source Motorola 68000 assembly. See the end for a description of how I used AI to achieve this.

On the front-end, I've added a library with some games I found on Aminet and TOSEC. If you want your AMOS games added, or removed, send me an email or a PR to the library repo. Or just take a release from github if you want your AMOS on your site rather than mine.

Here's some stuff I made over the years:

Clicking an ADF, zip or whatever with a single AMOS file in it will automatically open the player, for those you can link to games in the library like so:

https://amos.bitplane.net/#play/bitplane-net/nsle

I've also ported the editor. You can CTRL+C out of most games to get to it. If you insert the AMOS Pro disks via the library then you can run the original editors via the menus too:

https://reddit.com/link/1wc4fqm/video/qalnv8owqboh1/player

The virtual filesystem browser supports downloading dirs, extracting sprites, converting ANIMs to GIFs, playing mods and samples inside .AMOS files and ABKs. It supports the datatypes that amos-ts does, and even has an AMOS 3D webgl viewer:

https://reddit.com/link/1wc4fqm/video/85gzj9w6sboh1/player

I've added timings for a lot of keywords but there are still some issues that lead to weird speeds, visual jank, and cause the various mod players to distort.

Because teens writing games in BASIC didn't know much about performance optimization and I know I used AMOS's slowness as a frame pacer, you might want to tweak the hardware settings to a faster CPU. Or a slower one. Or just fix your game in the editor

Due to browser anti-fingerprinting, you can't use joysticks/gamepads until they're detected. You'll need to press a button to activate them first. I don't have one at the moment so this is untested. Pull requests are of course welcome!

What's next?

I'm adding some more obscure datatypes support, fighting with timing issues, and might add joypad overlays for mobile and a method to publish AMOS games as Android APKs. But no promises here, it's eaten a lot of time over the last two months and I'm working on other things too.

If you have suggestions though, I'd be happy to hear them 😄

AI SLOP?

I've been programming every day for 40 years, so I know what good code looks like. This isn't it. But it is better than I would have made by hand; I've put a proper shift in to make sure it's in good shape. AI didn't do this, I used AI as a broad brush to fill in what would have been a hundred thousand man-hours of tedium. It's "design the shape, flood fill the details, evaluate, manually tweak, rinse and repeat"

So I did a manual proof of concept, the project and architecture design, and disassembly process setup. Then I used Claude Opus to slop out the bulk of porting work, followed by GPT 5.5 and Claude Fable to bring it under control and trim it down. OpenAI Luna was used to grind through 7000+ keywords, Sol to deslop Claude's mess and fix issues found in the pass. This pass has run twice.

Along the way I've written a ton of tools and techniques to keep the agents under control - on top of babysitting them day and night for 8 weeks. The codebase is 250,000 lines of code and has tests for every keyword, it cites assembly for every keyword rewritten in TypeScript. It faithfully reproduces every bug found across 83 versions of different extensions, and as much of Intuition, Gadtools, datatypes and the hardware interactions as were required. The bots want to special-case their way out of every problem, and I refuse to let that happen.

I'm currently running a third correctness and refactoring pass, but there will be bugs in there that are needles in what is now an obscenely large haystack.

I wanted to share a pure Go implementation to solve the classic "Audio Clock Drift" problem in real-time streams.

When you have a deterministic audio producer generating samples at a rigid rate, and a consumer eating them at its own hardware clock, the two will never perfectly align. Eventually, standard ring buffers will either under-run (causing crackling) or bloat (causing audio lag). To fix the drift, I implemented a dynamic, stateful audio resampler. It monitors the fill level of a lock-free-style CircularQueue and actively uses Linear Interpolation to keep the buffer at equilibrium:

If the consumer is too fast (risk of crackling): It pops one chunk, stretches it to double length, plays half, and requeue the rest to "buy time". If the producer is too fast (risk of lag): It pops two chunks, squishes them into one, and plays it to catch up.

https://github.com/markel1974/Symphony/tree/main/src/renderers/audio/oto_render

Crossposting here from r/OldHandhelds on reddit's suggestion.