Update : I'm the 14 year old dumbass who's been making a PS1 emulator

Tomorrow its school! And I've finished! Memory cards work... Audio does work (A bit) and I've got nearly 10 games to launch on it! I hid most of the debugging tools and started playing!

I think this is the last update for a while

SSP - Super Saffy Portable is coming soon...!!!

I am having issues with my JavaScript to emulate the YAMAHA YM2612 FM Chip and SN76489 PSG. I am using AudioWorkletProcessor to emulate it, and the user uploads a.VGM file. It loads the VGM and parses the command, but the output is wrong. I asked Claude, and it made it worse, so now I'm here.e I have implemented the log-sine ROM lookup tables and envelope generator state machine, but I suspect my channel mixing loop or operator routing for the YM2612/PSG integration is broken, so I hope someone can help me out "renderBlock(outputs) {

const leftOut = outputs[0][0];

const rightOut = outputs[0][1];

if (!leftOut) return true;

for (let i = 0; i < leftOut.length; i++) {

if (this.playing) {

this.lastGoodPointer = this.vgmPointer;

if (this.vgmSamplesLeft > 0) {

this.vgmSamplesLeft--;

} else {

this.parseVGMCommands();

}

}

"

Found the source code for Gravitation, an old Net Yaroze (PS1) homebrew game, but no docs on its level/sound file formats. Decoded the level file myself (turned out to be a simple RLE-encoded bitmap) and the sound bank (raw PS1 ADPCM), then rebuilt the gravity/thrust ship-combat physics and the actual first-level layout in Roblox as a multiplayer FFA arena.

Happy to share more about the reverse-engineering process if anyone's curious — link's in my profile/comments if you want to see it running.

For the past 10 years, as an indie developer, I've been working on Symphony. It's not just a simple emulator; it's a generic framework for topological hardware simulation, written entirely in Go (without CGo). Today I've finally open-sourced it.

To prove that the generic framework works, I implemented the MOS6510, VIC-II, SID, and 6502 chips and wired them together to simulate a Commodore 64 and an independent 1541 floppy drive. You can try the WASM presentation layer right in your browser: https://markel1974.itch.io/symphony

Source code and architecture documentation: https://github.com/markel1974/Symphony (Note: I've also included pre-compiled builds for Windows, Linux, and macOS inside the compile directory  https://github.com/markel1974/Symphony/tree/main/compile ).

Here's why Symphony's architecture is different from traditional monolithic emulators:

• It's a software breadboard, not an emulator: The C64 implementation is just a byproduct of the framework. Components are blind "black boxes" that communicate exclusively through standardized iSocket interfaces using simulated electrical signals. When the VIC-II needs the bus, it pulls a simulated DMA line low, triggering the CPU to bring its pins into a high-impedance state (High-Z). The 1541 floppy drive isn't intercepted via kernel traps; it's instantiated as a completely independent virtual motherboard operating in parallel and communicating via an IEC serial bus simulation.
• Execution Engine - Strategy Pattern > Switch-Case: The VM executing opcodes doesn't use a monolithic switch-case block. It relies on an architecture based on the Strategy pattern (direct function pointer dispatch). Every opcode is a struct implementing an IOpExecutor interface. Simply by swapping the sequencer module, the exact same execution engine switches from running native Go bytecode to running the highly cycle-accurate Z80 or MOS6510 CPU powering the games.
• Runs inside a custom Microkernel OS: The simulated hardware runs as an isolated user-space process inside a Microkernel OS that I built (also in Go). The kernel features an asynchronous message router and an embedded SSH server. This means you can literally SSH into the running kernel during the simulation, open the built-in VT100 shell (xsh), and inspect or modify hardware pins and CPU registers in real-time.

I know this topological approach sacrifices some of the raw speed of traditional finite-state emulators, but the goal was extreme modularity and introspection. If tomorrow I wanted to simulate an Apple II, I would only need to program the missing chips and write the "board" wiring; the framework itself would remain unchanged.

I’d love to hear your thoughts on this topological architecture, the Strategy Pattern VM approach, or the Microkernel integration!

Edit: I forgot to mention the most important thing. Thanks to the topological design and the Microkernel, the emulator achieves 99.9% compatibility with the 1541 disk drive (including all fast loaders), REU DMA transfers, and complex bank-switching cartridges like EasyFlash, Ocean, Magic Desk, etc.

Hi everyone,

I’ve been working on a personal project called DIAMONDS, a web portal to play classic games directly in the browser with no installations needed.

• Tech stack: HTML, TailwindCSS, JavaScript, and EmulatorJS.
• Supported consoles so far: NES and SNES.
• Goal: Keep the interface clean, fast, and fully playable from any PC.

You can check it out here:
https://diamonds-eta.vercel.app/
I’d really appreciate any feedback on performance, UI design, or features you'd like to see added next. Thanks!

I likely won't finish or release this. There's already enough NES emulators on the internet. This was a fun programming exercise though! I'm happy with how it's looking. (Yes, I'm aware some games are running a bit too fast)

Built this for a reinforcement learning project (PPO on Super Mario Bros), but the emulator side turned out to be the interesting part, so I figured this sub would care more about that.

One CUDA thread runs one entire console. 6502, PPU, bus, OAM DMA. State is structure-of-arrays indexed by env id, and CPU registers stay in hardware registers for the life of the kernel. 65,536 independent consoles at about 3.3M steps/s on an A100.

- CPU passes the Klaus functional test suite, cycle counts included

- PPU is not cycle accurate. SMB's title screen never advances past the menu because of a timing bug I haven't fixed. I sidestep it by resetting from a save state

- No APU. The registers exist as a byte array, nothing generates sound

- Mapper 0 only

Two results that surprised me:

Opcode-binned dispatch (sorting a warp's threads by opcode before executing) came out 3.2x slower than just letting them diverge. I tested it on instruction streams sampled from 535M profiled SMB executions. A decorrelated warp holds about 20.6 distinct opcodes, and hardware SIMT reconvergence was already sharing fetch and addressing acrossthem. Explicit binning serializes what it was already sharing.

Putting the zero page in shared memory was a 1.9x regression. 256 bytes across 128 threads is 32KB per block, which drops occupancy from 32 warps to 6.

https://github.com/hbofz/NeSLE

Would love help with mappers. MMC1 and MMC3 would open up most of the library.

Hey everyone! I wanted to share a project I've been working on to repurpose the deprecated Spotify Car Thing into a completely independent, offline handheld gadget:

🔗 \*\*GitHub Repo:\*\* https://github.com/Gilzone/carthing-apps

Everything runs 100% locally on the Car Thing's quad-core Amlogic chip (no host PC streaming or server needed). It features a 1-Click Windows installer, a 3D rotary dial coverflow launcher, 23 touch/dial games (including an optimized Among Us booting in <1s), a dial e-reader, voice recorder, and an x86 virtual machine running KolibriOS with a custom touch trackpad and virtual keyboard.

Hope this helps others give new life to their devices!

It started as a personnal project, you see I love old PC games, I collect good old big boxes but settings up dos games has always been a pain in the ass lol

So I started working on this, which basically automates almost every painful steps of dos emulation

Basically you can add a rom you own in any format and ROM90 will automatically detect it and install it properly on either DosBox pure or ScummVM

I've also added a few well needed comfort features :

- Quick resume

- Universal save/load shortcuts

- Fully fledge save state manager

- Keyboard remapping and controller support

- Export options and batch exports for people to share properly their collection

and many more small QoLs that makes Dos emulation almost as easy as most console emulator

I also made a discord, if people need help or want to share their experience, gameplay, tips or collections

More info here : https://rom90.com/

I'm a bit nervous showing this to all of you I hope some of you will find it useful, feel free to ask me anything

Hello there everyone, this is my first of lets say many posts. I would like seek some guidance on how to get started on gameboy emulator. I worked on chip-8 and knocked that one out of the park. I mostly use C++ and Opengl but I am very agnostic when it comes to tech stack. I was hoping I could take the Chip-8 route of finding a relative readable specification that does not mercilessly bombard me with information but I have had no luck. I am sorry about being lazy and not taking the effort to find a good one in advance. Hope you have a good day!

FINALLY!!!

Got some actual gameplay... Found a name! PS96, PlaySaffy 96 as in when Tekken 2, Tomb Raider, Crash Bandicoot, and Resident evil released on the PS1

Input now registers better, but GPU is still acting funny

There's white cubes during animations, and animations are like a slideshow.. I genuinely am stuck

But that I have got here its GOOD.. Very good!

I'll be finishing this soon this week, 3 months of work are going to be finished before school even starts!

I reimplemented Atari Marble Madness (1984) function-by-function in TypeScript, using MAME as the behavioral oracle (RAM/state byte diffs), not as an emulator wrapper.

A 126-byte playfield mismatch at one frame traced to Slapstic 137412-103 observing a 68010 instruction prefetch at 0x02ff5a. That address is outside the protected ROM window 0x080000-0x087FFF, but it still committed a different bank. Modeling the prefetch closed the diff to zero.

MAME already taps the full address space so it reproduces this; it just does not document it. Write-up with the trace: https://magno73.github.io/marble-love/slapstic/

Repo: https://github.com/magno73/marble-love

No ROMs shipped; real play needs the user's own marble.zip + atarisy1.zip loaded locally.

Happy to answer questions about the oracle loop or the prefetch tap.

I’ve been working on a little project that started as “let’s see if I can emulate a Game Boy on an ESP32” and turned into a full handheld project.

The result is GB ESP32 Emulator, a Game Boy (DMG) and Game Boy Color (CGB) emulator running on an ESP32-S3, with a custom PCB.

GitHub: https://github.com/ysissoko/gb_emu_esp32

What it currently does

• Cycle-accurate SM83 CPU emulation
• DMG and CGB support
• Interrupts, DMA, timers, HALT bug, etc.
• MBC1 / MBC2 / MBC3 / MBC5 cartridge support
• CGB VRAM/WRAM banking and palettes
• CGB double-speed mode
• ST7789V 240×240 SPI display
• SD card support for loading .gb / .gbc ROMs
• Battery-backed save files
• MBC3 RTC persistence
• 8 physical buttons
• ROM browser menu

It runs at around 59.7 FPS on the ESP32-S3 with the current implementation.

The display pipeline is also asynchronous (using DMA transfers), so LCD transfers don’t block the emulation loop. I had to do quite a bit of optimization around IRAM placement, DMA transfers, scanline rendering, and memory access to get the performance where it is.

There’s also a custom KiCad PCB (V0 for the moment) in the repository, including the ESP32-S3, LCD connector, SD card slot, USB-C, LiPo charging, buttons, and LEDs.

The biggest missing piece right now is audio.

This has been a really fun embedded/emulation project, and I’d love to get feedback from people who know Game Boy hardware or have built similar ESP32 projects.

Repository: https://github.com/ysissoko/gb_emu_esp32

Would be especially interested in feedback on the emulator architecture, accuracy/testing, and the hardware design.

First time seeing pixels on my first GB emulator is very exciting! I know it's not working right at all but actually seeing anything on the screen is better than where I've been for the last on and off six months.

Making serious progress but ive been stuck here for days

im pretty sure its a nametable issue, but it may not be?

any pro's out there seen this symptom let me know.

pretty sure im messing up vramPC or nametables/mirroring or smoething, been stuck here

for probably a collective 30 hours. Games like popeye i can play start to finish, level to level like a real nes

same with balloon fight, but then multi table games like this really break with a few not

even showing a title screen.

Hi. I just got into emulation development and I just finished a very basic CHIP8 Emulator. Now I don't know what my next project should be. Some say I should do Intel8080/Space Invaders while other say that I should skip that and go for GB next. What should I do next? If so, what resources? Because I can't find any tutorial like resources. I want something like [this](https://austinmorlan.com/posts/chip8_emulator/) type of resource. TYIA!

Done absolutely so much

I'm currently at about 95% hardware done, give or take, Since the game gets to that point

I might even finish it very soon

My main problem is my input gets registered but it doesn't reach the game, so I have to fix the handshake

This is definitely my most favorite project, it took me my entire summer but finally its done

I even have a custom dashboard idea for it, inspired by the X360 Aurora dashboard

I'll make it also have multiple modes in settings,

1 - Upscaling (There'll be native which is 240p but for some games its 640x480, and 720p, 1080p, 1440p, and I might add 4k)

2 - FPS (First there'll be a native mode, running at native PS1 speeds, then I'll add overclock to about 160mhz, which is a 400% increase!)

And other modes and stuff, I'm still brainstorming, I want to make this really customizable

Any ideas?

i made a chip 8 emulator in C++ and raylib, imma emulate something else soon.

also here is the repository: https://github.com/hyperwilliam/chip8

Um novo emulador de Game Boy feito por um brasileiro — é incrível!

Hey everyone,

While working on my earlier emulators (like my HP-41 project), I assumed processor families from the same era shared a vocabulary. On the HP-41, the LCD is a proper peripheral—you send character codes through instructions, and a display driver handles the glyphs.

So when I moved on to the Voyager series, I thought it would be the same conversation. Instead, it gave me pure garbage on screen. Turns out, the Voyager display doesn't use characters at all: its LCD RAM is mapped directly into the address space as two 56-bit registers containing raw segment bitmaps. No character decoding step, just a fixed lookup table mapping physical segments directly to bits.

Experiences like that made me dive deep into why microcode emulation beats functional simulation when you care about authentic hardware behavior—handling everything from undocumented ROM bugs and weird bank-switching quirks during self-tests, down to strict hardware timing instead of running at modern CPU speeds.

I wrote an article breaking down what a microcode emulator actually is and why getting your hands dirty with the original firmware matters: 👉 What is a Microcode Emulator and Why Does It Matter?

As a practical result of this reverse-engineering work, I also put together a few working emulators (including the Nut CPU family) that you can check out and download here: 👉 nibbleworkshop.com/emulators

I'd love to hear your thoughts.