My 10-year journey building a Topological Hardware Emulator inside a Go Microkernel

Hi everyone,

For the past 10 years, working mostly in the shadows as a solo developer, I’ve been slowly building a passion project. Today, I’ve finally published it to the open-source world, and I want to share the architectural journey with this community.

You can see the final result in action right now, running Mayhem in Monsterland via WebAssembly directly in your browser: https://markel1974.itch.io/symphony

The project is called Symphony. It looks like a cycle-accurate C64 emulator, but under the hood, it’s something entirely different.

The Problem with Black Boxes

When I started 10 years ago, I was frustrated by how traditional emulators were built. For performance reasons, they often rely on massive monolithic switch-case statements and high-level software traps. They simulate the results of the hardware, but not the hardware itself. I wanted to build a system where I could perform "open-heart surgery" on a running machine. I didn't just want an emulator; I wanted a software breadboard.

The Solution: Three Pillars of Symphony

After years of iterations, the architecture settled into three completely decoupled layers, written entirely in pure Go (with zero CGo dependencies for maximum portability).

1. The Topological Breadboard In Symphony, hardware components (like the VIC-II, SID, PLA, and 6510 CPU) are blind "black boxes." They communicate exclusively through standardized ISocket interfaces using simulated electrical signals. When the VIC-II needs the bus to draw graphics, it doesn't just read an array; it pulls the simulated DMA line low, which triggers the CPU to put its pins into a High-Z (high impedance) state, pausing execution just like real silicon. The 1541 Floppy Drive isn't a high-level API hack; it's a completely independent virtual motherboard running its own 6502 CPU in parallel.

2. A Microkernel OS with Live Introspection The C64 you play in the browser is actually running as an isolated user-space process inside a custom Microkernel. This OS features an asynchronous message router, a built-in SSH server, and a VT100 retained-mode window manager. You can literally SSH into the running kernel mid-game, open the built-in shell, and read/write the registers of the emulated CPU or audio chip on the fly, without stopping the simulation.

3. The Universal VM & Go Compiler To power this OS, I wrote a multi-pass compiler that parses a large subset of the Go language into bytecode. The execution engine (the VM) uses the Strategy Pattern (direct function pointer dispatch) instead of a standard interpreter loop. Because of this "Interchangeable Instruction Disk" design, the VM isn't hardcoded to its own bytecode. By swapping the sequencer, the exact same engine acts as the cycle-accurate Z80 or MOS6510 CPU emulator.

Why this matters for GameDevs

If you are into engine development or low-level optimization, you might appreciate the decoupled nature of this architecture. The core emulation is completely headless. The exact same core logic powers the OpenGL desktop build, the WebAssembly build on https://markel1974.itch.io/symphony, and the headless server build (which is great for CI/CD automated testing).

It’s been a massive 10-year marathon, but seeing the architecture finally come together into a stable, open-source framework is incredibly rewarding.

You can find the source code, the Component Tree diagrams, and the full architectural breakdown on GitHub here: https://github.com/markel1974/Symphony

And if you want to see it linked as a project here on GameDev, check out my Project page: https://gamedev.net/projects/336-symphony/

I’d love to hear your thoughts on the architecture, especially the cycle-accurate synchronization approach or the decoupled rendering system!