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.
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:
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.
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?
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 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
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)
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.
> 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)
> 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.
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
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)
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.
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.
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?
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.
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.
The magic/more magic switch?
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
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)
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.
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.
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.
> 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)
How much faster is your C++ Linux kernel?
Other emulators exist that do more for performance. This is more of a simulator.
> 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.