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.
Full mask sets for leading edge nodes cost tens of millions these days, and it takes months from committing to the design to actually getting the silicon in hand.
Companies that design CPUs today commonly simulate the designs on massive server farms to find bugs before they commit to building masks. Running purely on CPU, such simulations of leading edge chips struggle to reach 1kHz, which is a problem given how long it takes to just boot an operating system these days. (And this is at full scale-out -- dedicating sufficient compute to the problem that it no longer gets faster if you use more, due to communication latencies.)
Because of this, it is now common to use FPGAs to emulate better understood parts of the circuits, to get better speeds and do more validation work in software before committing to the masks. This can get them up to a MHz.
Pong had no CPU, so its board is filled with small chips that collectively work together. It's probably harder to emulate Atari Pong Arcade than a C64.
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:
> 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.
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)
> 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)
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.
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.
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.
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?
No, because the simulated computer does not exist in the real world. The host's physical characteristics only affect the simulation if they cause the host computer to malfunction.
Yes, and to see the faults, there is no telling how much deep the simulation needs to be closer to the physical world. May be in real life the thing would not work because of some signal EM interference. Then the simulation without including it would not catch it...
I feel like that matters less the slower the simulation runs. Simulated RF interference would operate at a much slower timetable than the host system, and I don't really think the host system's RF matters so much until you're at speed parity with the original system and hoping to interface with hardware peripherals.
Absolutely! Seems like if hardware run something simulated at 50% speed, and want to also simulate rf, would need to half the wavelengths of the rf, and some of it may enter into mush zone.
> 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.
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.
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
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.
Full mask sets for leading edge nodes cost tens of millions these days, and it takes months from committing to the design to actually getting the silicon in hand.
Companies that design CPUs today commonly simulate the designs on massive server farms to find bugs before they commit to building masks. Running purely on CPU, such simulations of leading edge chips struggle to reach 1kHz, which is a problem given how long it takes to just boot an operating system these days. (And this is at full scale-out -- dedicating sufficient compute to the problem that it no longer gets faster if you use more, due to communication latencies.)
Because of this, it is now common to use FPGAs to emulate better understood parts of the circuits, to get better speeds and do more validation work in software before committing to the masks. This can get them up to a MHz.
Pong had no CPU, so its board is filled with small chips that collectively work together. It's probably harder to emulate Atari Pong Arcade than a C64.
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?
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)
> 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.
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)
> 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)
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.
No, no, don’t you understand? This person glanced at the code. We’re talking about a full-on glance here. They know it’s horribly optimised.
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.
He also used Claude to get the fastest inference engine out there (Dwarfstar) for Apple hardware and the extremely efficient Array data type in Redis.
Other emulators exist that do more for performance. This is more of a simulator.
How much faster is your C++ Linux kernel?
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.
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?
You would eventually need to be simulating semiconductor physics, which is not exactly trivial.
The magic/more magic switch?
https://www.catb.org/jargon/html/magic-story.html
Yes and do you agree, the hardware running the simulator also would need to be characterized, and it's own conduction/induction/rf taken into account.
No, because the simulated computer does not exist in the real world. The host's physical characteristics only affect the simulation if they cause the host computer to malfunction.
> if they cause the host computer to malfunction.
It could, and that is the point running simulations. right?
The purpose is to see faults in the simulated system, not in the simulating system.
Yes, and to see the faults, there is no telling how much deep the simulation needs to be closer to the physical world. May be in real life the thing would not work because of some signal EM interference. Then the simulation without including it would not catch it...
I feel like that matters less the slower the simulation runs. Simulated RF interference would operate at a much slower timetable than the host system, and I don't really think the host system's RF matters so much until you're at speed parity with the original system and hoping to interface with hardware peripherals.
Absolutely! Seems like if hardware run something simulated at 50% speed, and want to also simulate rf, would need to half the wavelengths of the rf, and some of it may enter into mush zone.
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.
> 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.
I wonder if it's possible to have the reverse of this -- map a given result to breakage.
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.
Great pedagogical tool.
no online demo?
Paging Adrian Black
That was the first thing I thought of - Adrian's Digital Basement might find this project very interesting.