alt Hacker NewsThe Commodore 64 hardware simulator: break chips and pins, see the results
Comments
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.
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.
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?
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.
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?
> 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.
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.
> 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. This is not a problem for the goals of this program, but be warned: it is not an emulator to play games with.
Sounds like an optimization opportunity. Might take a look.
Is the simulation accurate enough that if you had a simulated cartridge like the REU it would be able to do the memory transfer tricks that it does?
I have been designing a cartridge in the back of my brain, and if this could assist before I start letting magic smoke out of my c64 it would be awesome.