--- title: The Commodore 64 hardware simulator: break chips and... description: c64-hw-simulator is a pin-level hardware simulator of the Commodore 64 motherboard (ASSY 250407), created by antirez. It models every chip's behavior at the... canonical: https://daily.dev/posts/the-commodore-64-hardware-simulator-break-chips-and-pins-see-the-results-gk0aj7x6h twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Commodore 64 hardware simulator: break chips and pins, see the results | daily.dev og:description: c64-hw-simulator is a pin-level hardware simulator of the Commodore 64 motherboard (ASSY 250407), created by antirez. It models every chip's behavior at the... og:url: https://daily.dev/posts/the-commodore-64-hardware-simulator-break-chips-and-pins-see-the-results-gk0aj7x6h og:image: https://api.daily.dev/og/posts/gK0AJ7X6H.png og:image:alt: The Commodore 64 hardware simulator: break chips and pins, see the results og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Commodore 64 hardware simulator: break chips and pins, see the results **[Hacker News](https://daily.dev/sources/hn)** · 7 min read · 0 upvotes · 0 comments ## Summary c64-hw-simulator is a pin-level hardware simulator of the Commodore 64 motherboard (ASSY 250407), created by antirez. It models every chip's behavior at the pin level using the board's real netlist, letting users lift chip legs, short pins to ground or +5V, pull chips from sockets, or break resistors, then observe the resulting effects on the screen, keyboard, and signals exactly as a real faulty board would behave. It's built on floooh's cycle-accurate 6502/VIC-II/CIA/SID chip cores and a KiCad-derived netlist, and is intended for learning how the C64 works internally or diagnosing a broken real C64 before desoldering components. It runs on macOS and Linux, is slower than real-time (31-48% speed depending on CPU), and does not simulate analog parts like video output or the SID filter. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How can I figure out which chip is broken on a Commodore 64 motherboard without desoldering everything? A pin-level hardware simulator called c64-hw-simulator models the C64's ASSY 250407 motherboard netlist and lets you simulate faults like a removed chip, a shorted pin, or an open resistor, then compare the resulting screen/keyboard/signal behavior to your real broken board. A matching symptom is a clue, not proof, since different faults can look identical, but it helps prioritize which chips to desolder first. _Repairers comparing real C64 symptoms against simulated faults can find deep dives like this on daily.dev._ ### Why does a Commodore 64 show garbled colors on only half the screen after reseating the color RAM chip? This matches a classic color RAM (2114) pin-17/A7 fault: lifting that address pin before power-on causes the CPU and VIC to alias to the same wrong address, so the chip boots looking healthy, but the half of the RAM never written then displays random colors once the pin is reconnected, as confirmed by both the real 2114 chip and a pin-accurate simulation. _Hardware debuggers tracing address-line faults like this often surface simulators like this one on daily.dev._ ### How fast can a software simulation of the Commodore 64 hardware run compared to real speed? A pin-accurate simulation of the C64's ASSY 250407 motherboard runs well below real-time speed: 31% of real speed on an Apple M3 Max, 39% on an AMD Ryzen AI Max+ PRO 495, and 48% on an Apple M5 Max, because every pin of every chip is simulated. It is built for fault diagnosis and learning, not for playing games. _Developers benchmarking hardware simulators against real-time constraints can track projects like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 3 discussions and 28 comments across hackernews (as of 2026-10-18). **TL;DR:** Commenters are impressed by the depth and educational value of this pin-level C64 simulator, but much of the discussion centers on its slow-than-real-time performance, with debate over whether that's an inherent cost of transistor-level accuracy or a sign of unoptimized (possibly AI-assisted) code. **Sentiment:** 40% positive · 45% mixed · 15% skeptical **The case for** - Seen as a genuinely useful tool for diagnosing real faulty C64 boards before desoldering. - Praised as a fun, educational project that rekindles interest in low-level hardware understanding. - One commenter suggested concrete stretch goals like simulating diagnostic carts and PLA timing capacitors, showing real practical interest. **The pushback** - Several argued the simulator is far slower than real-time and could be significantly optimized (no SIMD, no multithreading, naive CPU emulation). - The original chip-core author pushed back, explaining that transistor-level address decoding and memory access overhead make large speedups unrealistic. - Some questioned how much AI-assisted (vibe) coding contributed to suboptimal performance. - Debate over how far simulation fidelity should go sparked tangential, somewhat skeptical remarks about simulating RF interference and induction. **By community** - hackernews (mixed): Admiration for the project's ambition and educational value is mixed with a substantial technical debate about its performance and optimization potential. **Hottest debate:** Whether the simulator's slow-than-real-time speed reflects unavoidable transistor-level simulation overhead or simply unoptimized/AI-generated code. **Open questions** - Could the simulator be optimized to run closer to real-time without sacrificing pin-level accuracy? - Would the simulation be accurate enough to model complex cartridge hardware like an REU doing memory transfer tricks? - Is it possible to invert the tool, mapping a desired faulty behavior back to the underlying hardware breakage that causes it? **Highlights** > > Just glancing at the source you could do easy 100x performance improvements with simple fixes. Now that you said this you really are expected to do a proof-of-concept implementation that is 100x faster, but with the same low-level concepts ;) I think 2..3x might be achievable assuming the vibe-coded code quality is really badly optimized, but definitely not 100x. As far as I understand the simulation, it does the entire address decoding and memory accesses as a transistor-level simulation (which is the whole point!), e.g. everything that happens outside the CPU, CIAs, SID and VIC-II. That means every single memory access has significant overhead because it is essentially simulated from a transitor netlist similar to how visual6502.org simulates the CPU (which even in an optimized C simulation like https://github.com/mist64/perfect6502 is still about 30x slower than a real 6502 at 1 MHz). PS: Let's do some simple napkin math: the Antirez simulator is 3x slower than a real C64, 100x faster would mean around 30x faster than a real C64, e.g. like a C64 clocked at 30 MHz. That means on a 3 GHz host CPU you would have 100 host clock cycles to emulate a (30Mhz) C64 system clock cycle, and that's for 5 complex chips (CPU + 2xCIA + VICII + SID), so around 20 host clock cycles per emulated cycle for each chip, and that doesn't include address decoding and memory access (which is the expensive part in Antirez's simulator). And moving the chip emulators into threads won't help you much here, because you'd need to synchronise at least once per emulated clock cycle (maybe even twice per emulated clock cycle because of the C64's phi-1 and phi-2 'half cycles'). Good luck with that :) (e.g. squeezing a complete VIC-II clock cycle which renders 8 pixels and may have up to 8 active sprites into 20 host system clock cycles, even with perfect pipelining, SIMD, and no cache misses this isn't a lot of host CPU instructions compared to what a VIC-II needs to do each cycle). (disclaimer: I'm the author of the pin-based chip emulators used in this experiment) > — [flohofwoe on hackernews](https://news.ycombinator.com/item?id=50134493) > No, this implementation is just horribly optimized (as usual). Just glancing at the source you could do easy 100x performance improvements with simple fixes. ie no SIMD/SWAR anywhere; simulating things that literally don't need to be simulated; CPUs are emulated via monstrous instruction flooding cascades with ZERO reordering/speculative execution optimizations (this only improves performance, the underlying emulated program literally can't tell the difference, and with most emulators you'd get a FREE 5-20x improvement); cache trashing everywhere; zero multithreading (as far as I could tell, couldn't bother checking in detail) > — [rfgplk on hackernews · 4 comments](https://news.ycombinator.com/item?id=50134204) > Antirez definitely knows how to write efficient code given that he's the dude who made Redis and many other things, so I'm skeptical that you could "easily" get 100x performance, though it does seem like he used Claude to assist with this so there probably is some low hanging fruit fixes. > — [tombert on hackernews · 2 comments](https://news.ycombinator.com/item?id=50134289) > I remember Byuu (RIP) wrote an article around ~10 years ago talking about why BSNES/Higan was "slow", explaining that it's really not slow given what it's trying to do. The more accurately you simulate the chips, there is simply more over overhead involved with synchronization and whatnot. I remember in that article they mentioned a Pong circuit simulation like this that was getting something along the lines of 10FPS of gameplay, which astonished me. You don't get a lot simpler of a game than Pong and even on amazing hardware it was still unplayable if you want the truest form of emulation. > — [tombert on hackernews](https://news.ycombinator.com/item?id=50134233) > This is really cool, and a fantastic piece of work. It may come in handy when diagnosing / fixing C64 boards. Stretch goals: * Allow the simulation to run diagnostics carts. * On the 250407 board I have had timing edge cases with PLA replacements - the fix is often to fit a small (~100pF) capacitor on the /CASRAM line to slow it down a bit. The cap is fitted from the left leg of an existing 82 Ohm resistor and a nearby ground point close to 'RAM6'. Some boards actually have official space for the capacitor - designated C204. With some original PLA variants on real boards the capacitor may already be fitted. It would be good to be able to enable and disable this capacitor and set its value to see the effects. Write-up: https://linker3000.com/index.php/blog/poor64 > — [linker3000 on hackernews](https://news.ycombinator.com/item?id=50134087) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50127900) · 17 points · 2 comments - [hackernews](https://news.ycombinator.com/item?id=50100366) · 135 points · 26 comments - [hackernews](https://news.ycombinator.com/item?id=50116019) · 2 points · 0 comments ## Similar posts on daily.dev - [Emulating A Floppy Drive By Emulating The Drive Itself](https://daily.dev/posts/emulating-a-floppy-drive-by-emulating-the-drive-itself-y2ggss7oo) · Hackaday · 0 upvotes · 0 comments - [Visual 6502 in JavaScript](https://daily.dev/posts/visual-6502-in-javascript-xnvvgdyxv) · Hacker News · 0 upvotes · 0 comments - [Old Vintage Computing Research: 6o6 v1.1: Faster 6502-on-6502 virtualization for a C64/Apple II Apple-1 emulator](https://daily.dev/posts/old-vintage-computing-research-6o6-v1-1-faster-6502-on-6502-virtualization-for-a-c64-apple-ii-appl-poi3fwxyw) · Two Stop Bits · 1 upvotes · 0 comments --- Tags: [#c](https://daily.dev/tags/c), [#retrocomputing](https://daily.dev/tags/retrocomputing) [View this post on daily.dev](https://daily.dev/posts/the-commodore-64-hardware-simulator-break-chips-and-pins-see-the-results-gk0aj7x6h) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Commodore 64 hardware simulator: break chips and pins, see the results","url":"https://daily.dev/posts/the-commodore-64-hardware-simulator-break-chips-and-pins-see-the-results-gk0aj7x6h","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-commodore-64-hardware-simulator-break-chips-and-pins-see-the-results-gk0aj7x6h"},"datePublished":"2026-10-17T19:02:48.263Z","dateModified":"2026-10-18T00:48:39.051Z","description":"c64-hw-simulator is a pin-level hardware simulator of the Commodore 64 motherboard (ASSY 250407), created by antirez. It models every chip's behavior at the...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3cab94813076aa6877b9710b9de9dda6?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3cab94813076aa6877b9710b9de9dda6?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-commodore-64-hardware-simulator-break-chips-and-pins-see-the-results-gk0aj7x6h","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"c,retrocomputing","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"The Commodore 64 hardware simulator: break chips and pins, see the results"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-commodore-64-hardware-simulator-break-chips-and-pins-see-the-results-gk0aj7x6h#faq","mainEntity":[{"@type":"Question","name":"How can I figure out which chip is broken on a Commodore 64 motherboard without desoldering everything?","acceptedAnswer":{"@type":"Answer","text":"A pin-level hardware simulator called c64-hw-simulator models the C64's ASSY 250407 motherboard netlist and lets you simulate faults like a removed chip, a shorted pin, or an open resistor, then compare the resulting screen/keyboard/signal behavior to your real broken board. A matching symptom is a clue, not proof, since different faults can look identical, but it helps prioritize which chips to desolder first. Repairers comparing real C64 symptoms against simulated faults can find deep dives like this on daily.dev."}},{"@type":"Question","name":"Why does a Commodore 64 show garbled colors on only half the screen after reseating the color RAM chip?","acceptedAnswer":{"@type":"Answer","text":"This matches a classic color RAM (2114) pin-17/A7 fault: lifting that address pin before power-on causes the CPU and VIC to alias to the same wrong address, so the chip boots looking healthy, but the half of the RAM never written then displays random colors once the pin is reconnected, as confirmed by both the real 2114 chip and a pin-accurate simulation. Hardware debuggers tracing address-line faults like this often surface simulators like this one on daily.dev."}},{"@type":"Question","name":"How fast can a software simulation of the Commodore 64 hardware run compared to real speed?","acceptedAnswer":{"@type":"Answer","text":"A pin-accurate simulation of the C64's ASSY 250407 motherboard runs well below real-time speed: 31% of real speed on an Apple M3 Max, 39% on an AMD Ryzen AI Max+ PRO 495, and 48% on an Apple M5 Max, because every pin of every chip is simulated. It is built for fault diagnosis and learning, not for playing games. Developers benchmarking hardware simulators against real-time constraints can track projects like this on daily.dev."}}]} ```