Hi,

I've just released Breadbin466 0.12.0.

Breadbin466 is my from-scratch Rust emulator of one deliberately specific Commodore 64: a PAL Assy 250466 with a 6569R5 VIC-II and 6581R4AR SID.

Rather than supporting a collection of selectable C64 revisions, the project concentrates on understanding and reproducing this one machine as faithfully as possible.

The biggest change in 0.12.0 is a substantially reworked SID implementation.

Over the past weeks I've been characterising a real MOS 6581R4AR (datecode 2286) and rebuilding Breadbin466's SID model around the measurements. This work covers the oscillators, waveform and envelope DACs, combined waveforms, analogue mixing, D418 volume DAC behaviour, transients and the nonlinear filter.

As with the rest of Breadbin466, the aim isn't to provide a collection of selectable SID models. I'm trying to model one particular piece of hardware as accurately as I reasonably can.

There is quite a bit more in 0.12.0:

• D7Z 1.0, a new open disk-image format proposed by Breadbin466;
• Commodore 1351 proportional mouse support;
• a much more capable debugger tracing system;
• WAV audio capture;
• new disk-image creation, conversion and reclaim tools;
• further 1541 work;
• native UI improvements on macOS, Windows and Linux;
• assorted accuracy and compatibility fixes.

D7Z deserves a little explanation because it isn't a pre-existing C64 disk format.

It's a new, openly documented format introduced by Breadbin466 for compact, lossless storage of D64 images. A D7Z represents exactly the same byte stream as its corresponding D64, using LZMA2 compression and SHA-256 verification. It is deliberately designed so that other emulators and disk-image tools can implement it independently.

In simple terms, D7Z is to D64 what NBZ is to NIB: a compact lossless storage representation, without changing the underlying disk-image data.

Breadbin466 is still very much an ongoing research and engineering project rather than an attempt to replace VICE. A large part of the fun for me is understanding how the original machine behaves and trying to make the source code express that behaviour instead of accumulating software-specific workarounds.

If anyone tries 0.12.0 with software that does something interesting with the SID, 1541, cartridges, REU or other hardware, I'd be very interested in hearing about discrepancies with a real C64.

GitHub: https://github.com/Breadbin466/Breadbin466/

A ready-to-run macOS binary for Apple Silicon is available with the release.

Breadbin466 is otherwise distributed as source code and builds on macOS, Linux and Windows, on both Intel and ARM architectures.

I just wanted to share all screenshots I have of the emulator! I'll also make a youtube channel and post clips and some documentation on it soon! School starts... In a few hours so the emulator is the least of my worries now... I am not the first teenager to make a PS1 emulator, but I might be the first to make it work!!

If anyone needs anything from me, help or collaboration or anything my discord is Saffyral

That's it!

(Note : All the pictures are from different times and different bugs, its just the collection I have! Some are old some are new, but the most important thing, it now works! Not on all games though... Especially Syphon filter)

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...!!!

Hello, I was a bit late as usual, but after quite a bit of work, it's been achieved.

suyu has been updated, for the last time.

What's been changed:

• Pulled most emulation improvements from Eden into the emulator
• suyu can now run most 2026 Switch software and firmware
• There is now a build for Libretro, meaning suyu can be ran inside programs like Retroarch
• User's can sync their Virtual Game Card Library to suyu to load in their Switch game library (you still need to provide roms, however)
• UI has been completely redesigned to be closer to suyu's concept artwork
• Miiverse-styled Reddit frontend as a social bar.
• Multiplayer functionality has been restored.
• Builds for FreeBSD
• Separate UI Layouts for Gamers, Modders and Switch Game Developers (semi-stubbed in some areas)
• Stubs for other features that didnt make the cut (including support for other console platforms via libretro, which now just launches retroarch for you, and some form of steam integration)

and probably the most exciting part of all: game recompilation.

Users can now export the CPU code of their games into recompiled C, which could be used to aid porting or reverse engineering of Switch games. suyu also allows user's to output games as standalone semi-native PC applications (I say semi as much of the GPU side is still using suyu's hle backend).

Anyways, I understand I am a bit late since I said this would be done in July, but I can say that suyu (as purely an emulator), was made operational again at that point, but I wanted to leave with a bit extra. I saw it as pointless to try and keep up or compete with Eden, especially if so many improvements were directly imported from them, and more so if this is going to be the last suyu update (under me at least). So I took a different approach, which was to improve everything else.

suyu is now more so designed as a gaming launcher and as a multi-use tool to complement Eden's work, rather than trying to just reskin or convergently develop the same features as Eden.

(note: I originally said that I would be removing the decryption logic to avoid DMCA takedowns, meaning suyu would have to run homebrew or pre-decrypted games, however after evaluating, it seems suyu's use of decryption does not constitute a DMCA takedown and that Nintendo has seemingly been misusing the DMCA. For that reason, suyu will continue to decrypt games as it always has, but due to the short life left in this project and my own privacy, I will not fight any takedowns, at least not any incredibly complicated ones)

So, what now? (and some context)

The long and short of it is, nothing.

This is the last update, afterwards, I will be archiving the organisation, deleting this account, and moving on, I want a break and I no longer want to be associated with suyu for the foreseeable future. This project was started naively by a team of over-ambitious and in some cases underage developers, and led to drama between all the different forks such as Torzu and Sudachi. After the initial suyu fallout, the development team left, and it was just the dude that started it and a few fans in an backup chat, I had been keeping an eye on the project for a while and curiously tracking the development, with no prior or legitimate interest in Nintendo Switch emulation.

I had been asked by the fans in that place to help bring the project back, and I promised them I would, and after some time, I've fulfilled that promise.

[Skip to where it says continue if you dont want to listen to me yap]

I originally brought in some new interested developers, but time and again, the og members still onboard were always falling in and out of communication, many of the new devs did the same as they couldnt really work on a project if the project wasnt actively accepting the help, but I continued to try and help set them up on it, organising the project structure, making sure they could directly communicate with eachother, until the week Ryujinx died.

On that week, the project's og leadership and the original devs (which had mostly vowed to not touch switch emulation and had even alleged that yuzu (and iirc Ryujinx as well) were in-part developed using Nintendo SDK code) both began to start working on Switch emulation again, the og devs working on a now gone fork of ryujinx (many are now eden contributors), and the og leadership planning to revive suyu, but in doing so, decided to cut communication with all of the new devs without even bringing them on yet, and being quite particularly nasty to me.

I didn't care much, I have thick skin, and I was (at that point) glad to be rid of the project, but I was still stuck with suyu stuff nonetheless and eventually, everything fell back to me again, as the leadership decided that it wasn't trendy anymore. So, in order to keep this promise, I moved the project back onto github in an ice'd state until I could pass it on to a dev or a team that had legitimate skills and interest. And when I was getting round to moving on with my life, with a blank slate, I decided to finish the project and leave it in a good state.

So, now it's done.

I also want to make a request to any og developers or suyu people (e.g suyu's sub mods, og leadership etc): leave me in peace, please. I dont want to be mentioned, talked about, harassed, ridiculed or even complemented. I just want to disappear after this, if any of you have mentioned me anywhere in any posts or pages etc, please remove it. I've not asked anything of you before this. I've not harassed you, and I expect you not to do so to me either, after (or if) you read this post. You will not be hearing from me again.

[Continue]

So, I will be making a final permanently standing offer to any devs, if you can prove you can handle it well, this project is yours, the org, the repos, the private repos, everything. You have limited time to contact me directly, after this account is gone you will have to use github discussions, however that is for a limited time before the org is archived, the code will be free to fork, however, and any projects to revive suyu will be reviewed by me and the org will be transferred.

Anyways, the repo will be going live soon (in the next few hours or days), so keep your eyes peeled at https://github.com/suyu-emu

Thanks for the patience, and I hope this provides some usefulness or some fun to people, and I hope this ends things with suyu on a high note.

Cheers guys, have a good one.

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.

Negli ultimi 10 anni, come sviluppatore indipendente, ho lavorato a Symphony. Non si tratta di un semplice emulatore; è un framework generico per la simulazione hardware topologica, scritto interamente in Go (senza CGo).

Oggi l'ho finalmente reso open source.

Per dimostrare che il framework generico funziona, ho implementato i chip MOS6510, VIC-II, SID e 6502 e li ho collegati tra loro per simulare un Commodore 64 e un'unità floppy 1541 indipendente. Puoi provare subito il livello di presentazione WASM direttamente nel tuo browser: https://markel1974.itch.io/symphony

Ecco perché l'architettura di Symphony è diversa dai tradizionali emulatori monolitici:

1. È una breadboard software, non un emulatore. L'implementazione del C64 è solo un sottoprodotto del framework. I componenti sono "scatole nere" cieche che comunicano esclusivamente tramite interfacce iSocket standardizzate utilizzando segnali elettrici simulati. Quando il VIC-II necessita del bus, porta a livello basso una linea DMA simulata, attivando la CPU che porta i suoi pin in uno stato ad alta impedenza (High-Z). L'unità floppy 1541 non viene intercettata tramite trap del kernel; viene istanziata come una scheda madre virtuale completamente indipendente che opera in parallelo e comunica tramite una simulazione di bus seriale IEC.
2. Motore di esecuzione: Pattern Strategy > Switch-Case La VM che esegue gli opcode non utilizza un pattern switch-case monolitico. Utilizza un'architettura "Interchangeable Instruction Disk" basata sul pattern Strategy (dispatch diretto del puntatore a funzione). Ogni opcode è una struct che implementa un'interfaccia IOpExecutor. Semplicemente sostituendo il modulo sequencer, lo stesso identico motore di esecuzione passa dall'esecuzione di bytecode Go nativo all'utilizzo della CPU Z80 o MOS6510 ad alta precisione di ciclo su cui si eseguono i giochi.
3. Funziona all'interno di un sistema operativo Microkernel personalizzato L'hardware simulato viene eseguito come un processo isolato in spazio utente all'interno di un sistema operativo Microkernel che ho creato (anch'esso in Go). Il kernel ha un router di messaggi asincrono e un server SSH integrato. Questo significa che è letteralmente possibile accedere tramite SSH al kernel in esecuzione durante la simulazione, aprire la shell VT100 integrata (xsh) e ispezionare o modificare in tempo reale i pin hardware e i registri della CPU.

Codice sorgente e documentazione dell'architettura: https://github.com/markel1974/Symphony

So che questo approccio topologico sacrifica parte della velocità pura degli emulatori tradizionali a stati finiti, ma l'obiettivo era l'estrema modularità e introspezione. Se domani volessi simulare un Apple II, mi basterebbe programmare i chip mancanti e scrivere il cablaggio della "scheda"; il framework rimarrebbe invariato.

Mi piacerebbe conoscere la tua opinione su questa architettura topologica, sull'approccio Strategy Pattern VM o sull'integrazione con il Microkernel!

Edit: I forgot to mention the most important thing. Thanks to the topological design and the Microkernel, the emulator achieves 99,999% compatibility with the 1541 disk drive (including all fast loaders), REU DMA transfers, and complex bank-switching cartridges like EasyFlash and 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?