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 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.
- 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 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.
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.
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.
Key takeaway is why FPGA is still useful. Even modern CPUs can't handle certain seemingly simple data processing tasks in realtime.
Sounds like an optimization opportunity. Might take a look.
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)
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)