A new open-source project called c64-hw-sim does something emulators normally don’t bother with: it simulates a Commodore 64 motherboard at the level of individual chip pins and electrical nets, rather than reproducing the system’s behavior in software shortcuts. You can lift a chip’s leg, short a pin to ground, pull a chip out of its socket, or break a resistor, then watch the real consequences play out on a simulated screen and keyboard, exactly as they would on a physical, failing C64.

The project is built by Salvatore Sanfilippo (known as antirez, creator of Redis) and is aimed less at playing games than at understanding how a specific, beloved piece of retro hardware actually breaks and why.

What makes this different from a normal emulator

Most C64 emulators reproduce the computer’s behavior at a high level: they interpret 6502 instructions, generate video and sound output, and aim for speed and compatibility so games and programs run correctly. They do not model individual pins, electrical contention, or what happens when a chip is defective.

c64-hw-sim takes the opposite approach. It knows the board’s full netlist — the actual electrical connections on the ASSY 250407 motherboard PCB — and models how each chip behaves pin by pin. Critically, the simulator has no built-in notion of what a “broken” C64 looks like. When a part is simulated as faulty and garbage appears on screen, that garbage is the computed output of the circuit under the fault condition, not a canned effect written by someone who already knew the expected symptom.

This matters because it means the simulator can surface authentic, sometimes subtle, electrical behavior. The project’s own example illustrates this well: lifting pin 17 (the A7 address line) of the color RAM before power-on still lets the machine boot and look healthy, because the CPU and the VIC chip end up writing and reading the same wrong address, so the RAM aliases without visible error. Put the pin back, and the half of the color RAM that was never written during that aliased state now shows up as random colors on screen. Lift the pin again, and the screen goes clean again. According to the project, a real Commodore 64 with a real 2114 RAM chip does exactly the same thing.

How the simulation actually works under the hood

The chip-level emulation cores come from floooh’s (Andre Weissflog) “chips” project, which models the 6502 CPU, VIC-II video chip, CIA I/O chips, and SID sound chip using pins as their interface rather than abstracted function calls. antirez credits this pin-based approach as the direct inspiration for the project, describing c64-hw-sim as taking that idea “to its logical extreme” by extending pin-level modeling to every other part of the board: RAM chips, ROM chips, logic chips, and the PLA (the programmable logic chip that handles memory mapping).

The board layout itself is derived from bwack’s KiCad replica of the 250407 motherboard, converted into C data tables by a tool included in the project (tools/kicad2c.py). That conversion produces 216 parts, their connection pads, and 249 distinct electrical nets, which together let the simulator know exactly how every component is wired to every other one. The PLA’s internal logic equations come from a separate effort to read out the original 82S100 chip, credited to Mark Smith and Marko Mäkelä.

Every pin in the simulation drives its connected net in one of several ways: strongly, weakly (as with a pull-up resistor), from a direct supply short, or not at all. When multiple pins try to drive the same net, the strongest signal wins; if two equally strong drivers disagree, that is treated as a contention, with the low signal winning, mirroring real digital logic behavior.

Watching failures happen in real time

The interface shows the board, a simulated monitor, a control panel, and an oscilloscope. Pins are color-coded like a logic probe: red for high, blue for low, yellow for pulsing signals, gray for floating pins, and magenta when two outputs are fighting over the same line. Clicking a pin puts it on the oscilloscope and lets you introduce a fault — floating, shorted to ground, or shorted to +5V. Clicking a chip pulls it from its socket; clicking a resistor, ferrite bead, or the crystal opens that component. A control panel lists all active faults with one-click repair buttons.

One demonstrated example involves pulling the character ROM (U5) out of its socket while the classic “10 PRINT” maze program is running. The CPU and RAM keep functioning normally and the program keeps executing, but the character shapes disappear, matching what real C64 repair technicians have long observed. With the oscilloscope on the ROM’s data line, the simulator shows the bus floating whenever the VIC-II chip tries to fetch a character shape that no longer exists.

The control panel can also load .prg program files, writing them directly into the DRAM chips the way a hardware “freezer” cartridge would, which means programs can be loaded even on a board that is simulated as damaged.

Performance, testing, and how to try it

This level of detail comes at a real performance cost. The project’s own benchmarks show the simulator running at only 31% of real C64 speed on an Apple M3 Max, 39% on an AMD Ryzen AI Max+ PRO 495, and 48% on an Apple M5 Max. The author is explicit that this is acceptable for the tool’s actual goal of studying hardware faults, but warns plainly that it is “not an emulator to play games with.”

The project includes a batch mode that runs four seconds (200 simulated frames) without opening a window, reading text off the simulated monitor as a person would and saving the resulting picture. A companion test suite, tests/faults.sh, runs 31 common hardware faults, each with an expected symptom documented in advance of running the simulator, serving as a form of regression testing against real-world repair knowledge.

c64-hw-sim runs on macOS and Linux (via X11) using OpenGL, built on the sokol graphics library and the nuklear interface library, both bundled in the project’s third_party directory. Input works through a regular keyboard, with ESC mapped to RUN/STOP, PgUp to RESTORE, TAB to CTRL, and left ALT to the C64’s distinctive C= key. The board design is used under CERN OHL licensing from bwack’s KiCad replica, and the chip cores are available under a zlib license via floooh’s c64-llm project.

Frequently asked questions

Is this meant to replace existing C64 emulators? No. It is far too slow for gaming and is explicitly positioned as a tool for understanding hardware faults rather than running software at speed.

Who would use this? Retro hardware repairers, electronics hobbyists, and anyone curious about how specific chip failures manifest on a real Commodore 64 would likely find it most useful, since it reproduces authentic fault behavior rather than scripted glitches.

Do I need real C64 hardware to use it? No, it is a software simulation that models the board’s netlist and chip behavior; no physical Commodore 64 is required to experiment with faults.

Source: The Commodore 64 hardware simulator: break chips and pins, see the results