YHK - yet another hacker news clone

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

65 points antirez 2 days ago 12 comments

NikolaNovak 1 hour ago | parent

This is awesome!

I just got a commodore 64 ultimate last week to play with my son but also nerd out on - the more I use ai at work, the more I miss the pleasure of hand coding and fully owning / understanding a piece of hardware. I wrote my first BASIC program in 35 years last weekend, a version of wordle for his birthday with special birthday cake PETSCII art if his name is entered. I never really geeked put about hardware at such physical / electrical level, so this'll be fun to play with :).

There's so much AI slop everywhere, including c64 community now, but gems like this also come out so I suppose / hope it balances.

dwheeler 1 hour ago | parent

Amazing. Sadly, it can't run in real time even on strong real hardware. I wonder if its code could be optimized to run in real time?

rzzzt 1 hour ago | parent

The README mentions floooh's implementation which is a bit more simplified, there is no complete netlist so the smaller TTL glue chips will not be considered. It does work in real time though. The common interface between emulated ICs is a 64-bit integer that maps logic levels of interest at a given simulation step to its individual bits:

- https://github.com/floooh/chips/blob/master/README.md

- https://github.com/floooh/chips/blob/9e88298ce56319953ac7a43...

- https://floooh.github.io/tiny8bit/player.html?id=c64&dbg=1 (use the "Hardware" menu to get activity views similar to Salvatore's emulator)

kxrm 1 hour ago | parent

I have been working on this exact same thing. Using real hardware, I am trying to simulate down to the jail bars that are caused by the design.

LLMs make this kind of development really approachable.

What is fascinating is I can now build components that work through an Arduino to interface with real accessories and C64s.

clhodapp 54 minutes ago | parent

This is really cool but... At some point, don't we have to start simulating things like internal interference in the conductors, induction, and sending/receiving radio signals?

varispeed 50 minutes ago | parent

> Please note that even on fast computers this program struggles to simulate the C64 hardware at real speed. A real C64 is simulated at 31% of its speed on an Apple M3 Max, 39% on an AMD Ryzen AI Max+ PRO 495 (Gorgon Halo), and 48% on an Apple M5 Max

Key takeaway is why FPGA is still useful. Even modern CPUs can't handle certain seemingly simple data processing tasks in realtime.

rfgplk 35 minutes ago | parent

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)

tombert 27 minutes ago | parent

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.

cactusplant7374 18 minutes ago | parent

I'm working on building a JIT for an emulator and there is no end in sight. Running plenty of experiments though. So I guess that is something. LLMs are not good at building emulators unless they have a reference implementation in the training data.

linker3000 47 minutes ago | parent

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

tombert 32 minutes ago | parent

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.