This model starts with the board
c64-hw-sim models the PAL Commodore 64 ASSY 250407 motherboard. A converter turns a KiCad replica into tables for 216 parts and 249 electrical nets. Chip models see pins and nets instead of a hand-written list of familiar failure screens.
The controls can float a pin, short it to ground or 5 volts, remove a chip, or open a resistor. The monitor, keyboard, logic probe, and oscilloscope show what follows. The project also has a headless mode for scripted faults and screenshots.
The simulator answers, "What does this model do when I break this part?" It does not answer, "Which part on my board is bad?"
The strongest idea is symptom independence
The fault script lists 31 scenarios. The expected physical symptom was written before each simulation was run. The simulator does not contain a special rule that turns a removed character ROM into garbage glyphs. That result must emerge from the board wiring and part models.
This is useful because a repair hypothesis becomes cheap to rehearse. If the modeled fault produces a different class of symptom, move it down the desolder list. If it matches, keep it as a candidate and measure the real board.
The cut lines are explicit
The README says floating-line thresholds, drift times, and crosstalk values are guesses. Analog video, the SID filter, the power supply, and the dot-clock phase-locked loop are not simulated. Bad memory cells, slow parts, and bridges between two nets are planned but not implemented.
The model also runs below real time on the machines reported by the author. That is a consequence of evaluating pins and nets. It does not make the omitted analog and internal-fault behavior appear.
The artifact was inspected, not run
We cloned revision 68a732cf9701f544487c37fbbd70a9d1e76f3053 and ran its documented make command on Linux. Compilation reached the graphical interface and stopped because this host lacks the OpenGL development header GL/gl.h. We did not install system packages to force a run.
The included fault script starts scenarios in background jobs. On this host it returned success even though the binary did not exist. A release harness should check that the binary exists before launch and collect each child process status. A printed scenario list is not a passing fault run.
test -x ./c64-hw-sim || exit 1 ./c64-hw-sim --headless 200 --text \ --fault U5:removed # Compare the saved screen with the named expectation. # Then measure the same path on the physical board.
Use four witnesses before heat
- Pin the board assembly, region, fitted parts, and visible symptom.
- Run one fault candidate at a pinned simulator revision. Save the command, text, and image.
- Measure the real signal at the same pin or net. Record the tool and expected range.
- Choose the least destructive next action. Keep alternate faults that can produce the same symptom.
The simulator is most valuable before the soldering iron gets hot. It turns a hunch into a cheap counterexample search. It cannot replace continuity, voltage, clock, bus, thermal, and component checks on the machine in front of you.