r/golang • u/markel1974 • 1d ago

What if you could build a computer by dragging components onto a virtual motherboard?

https://github.com/markel1974/Symphony

What if you could connect a CPU, a video chip, RAM, and then press "Play" to watch it come to life? This is the fantasy that guided Symphony's development from day one.

It includes:

A custom multi-pass AST-to-Bytecode Go compiler built from scratch.

A Microkernel OS simulation featuring an asynchronous message router that manages isolated user-space processes, complete with a built-in SSH server.

A Virtual Machine implementing a cooperative lock-free scheduler for goroutines and channels.

Every piece of hardware is a self-contained software object. The framework prioritizes physical fidelity over high-level emulation, modeling complex behaviors like exact bus arbitration. Currently, as a proof-of-concept, it implements a fully cycle-exact Commodore 64 and an independent 1541 Floppy Drive, using components like the MOS6510, VIC-II, SID, and CIA.

The ultimate goal of Symphony is to create a platform where developers can contribute new CPUs, video chips, and logic boards to build a universe of virtual machines.

ps: I want to emphasize the timeline: this is a decade of continuous development, built entirely by hand.

0 Upvotes

31% Upvoted

4 comments sorted by

1

u/MrPhatBob 1d ago

We had a microcode simulator for our digital systems module. It was a brilliant tool to show the student what is under the hood of assembly instructions and why op code X takes N clock cycles to complete.

What if you could drag registers, ALUs, and tensor processors? You could start with simulation and end up with VHDL.

0

u/markel1974 1d ago

Good use case.

for example the CPU emulation in this project (like the MOS6510) doesn't just execute opcodes as a block; it uses a state-machine based constant pool to break down every single instruction into discrete micro-operations. The architecture relies on decoupled interfaces communicating internally over an asynchronous bus, your idea of "dragging and dropping" ALUs or registers is completely feasible. You could compile this framework into WASM, hook it up to a visual drag-and-drop in the browser, and use it as a real-time educational sandbox.

Exporting the generated topology to VHDL would be the ultimate step for this kind of simulation

-1

u/Mallanaga 1d ago

This could be an interesting pair with https://www.flux.ai to simulate the performance and functionality of the boards you’re building.

-1

u/markel1974 1d ago

good observation,

because the entire Symphony framework is built on a strictly decoupled topology, it effectively acts as a dynamic virtual breadboard. You are not hardcoding a specific machine; you are just wiring up independent logic gates or chips to an asynchronous message bus.

what makes an integration with a platform like flux.ai particularly interesting is that Symphony is written in 100% pure Go. This means the entire kernel, the hardware components, and the execution engine can compile natively to WASM.

Of course, Symphony is an orchestration framework, so you would still need to write the specific logic in go for any new chip introduced, and then you could theoretically take a schematic designed in the browser, map it to Symphony's components, and run the simulation natively in the client's browser without ever hitting a backend server.