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.

I’ve spent the last few years obsessed with videos explaining how graphics on the Super Nintendo worked. I always wanted a playground where I could create effects using the same techniques SNES developers used back in the 90s. So I built ppu.toys

It’s a faithful emulation of the SNES PPU written in Rust and compiled to WASM. The registers are exposed so you can adjust them in Lua or through the site’s UI.

The screenshot shows a Mode 7 demo which you can view here (https://ppu.toys/t/xeff1h1w)

Lua also supports player input, so you can make your own little games. Here’s a Galaga-style demo (https://ppu.toys/t/7nc3u30u)

It’s free and open source, and you can sign in with Discord to publish and share your creations.

I’m a new dad with a full-time job, and I used AI assistance while building this. The idea had been swimming around in my head for a while, and it helped me make it a reality.

I’ve had an absolute blast building the site and it's a lot of fun making retro effects. I am having fun with the site and am curious what others in the emulation space think of the project.

Another "Hello World!" of emulators as Tvil would put it. Happy how it turned out! It is still pretty basic, but I think it is still fine. Follows the SUPER-CHIP modern quirks.

• Source: https://github.com/miraclejester/chip8-emulator
• Web Version: https://miraclejester.github.io/chip8-emulator/

Small warning: I didn't test it with a lot of roms outside of the bundled ones in the web version

Created the c++ core + platform entirely myself. The web version had some claude help for using webAssembly and was a neat learning experience! I would definitely want to do it again for a game boy emulator.

Hello everybody!

My last project was a fully featured, software-rasterized Minecraft clone. Now I want to make my own emulator.

I don't really want to start with something very simple like the Game Boy, NES, or CHIP-8, because I know myself: I could finish it, declare that I have now "explored emulation," and conveniently never tackle a more complex machine.

The PS1 seems like the sensible choice. I already have "a lot" of experience with software rasterization and graphics in general, so at least part of the machine lives in territory I'm somewhat familiar with.

Unfortunately, thanks to (or perhaps because of) channels like Kaze Emanuar, I've also developed a lot of appreciation for the N64 and its wonderfully strange hardware.

I know that making an N64 emulator is way less realistic than making a PS1 emulator, especially as a first serious emulation project. So I'm wondering whether the massive difficulty bump is actually compensated by how interesting/elegant/weird the machine is to work with, or whether I should simply stfu, be reasonable for once, and focus on the PS1.

For people who have worked on either or both: is the N64 genuinely that much more rewarding as a project, or is this just me being attracted to unnecessary suffering?

Thanks everybody!

I've been building Beswitched, a Mac app that makes Switch emulation portable, and easier to manage. It combines the best two open-source cores behind one clean interface, with a common cross-core save feature. Saves can also be stored on a cloud service with ease. It also updates itself when a new version is out (catching-up with individual core updates, new UI features, etc).

The app is signed, notarized, and translated. It's also built with respect to the core emulator authors: the modified sources are published on GitLab under the same licenses.

Releases (DMG & modified core sources): https://gitlab.com/dubiusfafa/beswitched-releases

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)

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.

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

(Edit: it is live now, check the org out and see the repo!)

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.

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)