Symphony

Symphony is not just an emulator. It is a complete ecosystem for exploring, building, and introspecting computing systems, built entirely from scratch over 10 years.

You can try the WebAssembly build right now by playing Mayhem in Monsterland on a cycle-accurate C64 here: https://markel1974.itch.io/symphony

However, the game you see in your browser is actually running as an isolated user-space process inside a much larger architecture. Symphony is built upon three distinct but perfectly integrated pillars:

1. Topological Hardware Emulation

Hardware is not simulated via high-level software traps or monolithic switch-case loops. Symphony models hardware topologically—like a software breadboard. Components (like the VIC-II, SID, PLA, and 6510 CPU) are isolated "black boxes" that communicate exclusively through standardized socket interfaces via simulated electrical signals. For example, when the VIC-II needs the bus for graphics rendering, it pulls the DMA line low, triggering the CPU to put its pins into a High-Z state, just like real silicon.

2. A Microkernel OS with Live Introspection

At its core, Symphony acts as a microkernel operating system with an asynchronous message router. It comes with 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 (xsh), navigate a virtual filesystem, and read/write the registers of the emulated CPU or audio chip on the fly.

3. The Universal VM & Native Compiler

To power the OS, I wrote a multi-pass compiler that translates a large subset of Go into bytecode. The execution engine (the VM) uses the Strategy Pattern (direct function pointer dispatch) instead of a standard interpreter loop. This "Interchangeable Instruction Disk" design means 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 you play the games on.

Key Features for Developers:

• Fully Decoupled Renderer: The emulation core is completely headless. The presentation layer connects to it via interfaces, allowing the exact same core to run on OpenGL (Desktop), WebAssembly (Web), or Headless (perfect for server-side testing and CI/CD pipelines).

• Cycle-Accurate Timing: Components like the VIC-II respect the strict 63-cycle physical timing constraints of the original hardware, handling raster interrupts perfectly.

• 100% Pure Go: No CGo dependencies, ensuring memory safety and immediate cross-compilation.

GitHub Repository: https://github.com/markel1974/Symphony

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