c64-hw-sim adds cartridge diagnostics to C64 fault experiments

The Commodore 64 hardware simulator c64-hw-sim has gained diagnostic cartridges and checks that compare their reports with expected fault behaviour. For someone learning how a C64 fails, the useful change is being able to connect a deliberately broken virtual board with the kind of diagnostic output a repairer would investigate.

The diagnostic-cartridge commit is dated October 19, 2026. It follows Hackaday's October 15 introduction, which led to this article. October 19 is the date of these changes, not the project's first appearance.

Give a virtual fault a diagnostic consequence

The project models the ASSY 250407 motherboard through its connections and chip pins. According to its README, users can disconnect a pin, remove a chip or force a line to a supply level in the simulation. The resulting display is meant to emerge from those connections and component models.

The new commit includes Dead Test revision 781220 and Diagnostic revision 586220. The diagnostic test script checks cases such as removing individual memory chips in the model, opening a user-port contact and running with or without the diagnostic harness. The harness supplies loopback connections used by the tests; omitting it changes what the diagnostic software can observe.

That distinction matters when reading a failure report. A test that expects a connection can report its absence even when the component someone initially suspects is not the cause. Start with the healthy simulated configuration, change one condition, then compare both the visible symptom and the signals involved. This is an experimental method for the model, not a recommendation to disconnect parts on a powered real machine.

The maintainer reports that the added checks pass. TechKili has inspected the documentation and script, but has not executed the suite or independently reproduced those results.

Loading and typing become part of the experiment

A second October 19 commit adds a file browser for programs and cartridges and fixes keyboard input reaching the simulated C64. Its description also addresses a program loaded during boot being erased by the cold start.

These are practical changes for repeatable exploration. Loading the same diagnostic and applying the same fault gives a learner a more useful comparison than changing the program and board condition together. The commit documents the workflow changes; it does not establish that every cartridge format or C64 variant is supported.

Keep the circuit model inside its stated limits

The README describes macOS and Linux with X11 and OpenGL, and warns that the simulation is slower than real hardware. The project's implementation plan separates the implemented version from broader goals. Planned fault types should not be read as available features.

The documented limits include approximate floating-line behaviour and omitted analogue sections, including the SID filter and video-output circuitry. A familiar screen pattern therefore cannot prove that a particular physical chip is faulty. Different faults can produce similar symptoms, and a problem outside the model can be missed.

For a real repair, use the experiment to refine the next question you will check on the actual board. For learning, the immediate value is simpler: repeat a fault, follow its effects and restore the virtual machine without sacrificing an old computer.

Sources

• October 19 diagnostic-cartridge change

• Diagnostic checks in the project

• October 19 file-browser and keyboard change

• Current README and limits

• Implemented status and design goals

• Hackaday's October 15 report