Boulder Mark at 48MHz, with working sound

Boulder Mark seems to work now, even though I can't think what I might have fixed that would have addressed the problem it was having.  It does still crash occasionally, but it usually runs to completion.  

So I thought I would post a video of boulder mark running on it to give an idea of how fast the C65GS is.  That turns out to be about 500 frames per second in this test, which is very nearly 100x the score of a stock C64.  The vacuum-like sound is boulder mark making a noise every frame.

As I have mentioned before, boulder mark is a non-linear benchmark, because the first few hundred frames are much more work to draw.

So it is probably a better comparison between the C65GS and Chameleon, since both are fast enough that the slow frames are only a small fraction of the score.

On that basis, the C65GS is about double the speed of the Chameleon, rather than the 4x that SynthMark would suggest.  This makes sense, since SynthMark places a fairly heavy weighting on operations that read from IO and colour RAM, even though they are relatively rare operations.  So, depending on the workload, the speed difference is likely to be somewhere between 2x and 4x, if using normal 6502 opcodes.

First speed test of 48MHz CPU

I am continuing to fight with getting the reimplemented CPU and VIC-IV all settled down, however things are getting much closer.

As the following image implies, it can run the C64 ROM (not yet C65 ROM -- it gets stuck in the DOS somewhere).  It should be noted that the CPU performance here is not final, and some instructions might end up faster or slower than depicted here.  That said, the CPU is certainly quite a bit faster than the old 32MHz one.

44.36x is almost exactly 48mhz/32mhz = 150% the speed of the old CPU at 28.93x.  Pleasingly this is before I do anything to optimise the performance.  Also, whereas the old CPU filled the FPGA to capacity, with the new CPU about two-thirds of the FPGA remains free -- space for implementing sprites, a 1541 and other goodies as I get the chance.

Speaking of optimisations, one that I may attack in the not too distant future is a stack cache that allows RTS to execute in just 1 cycle.  While it will make some impact on the SynthMark64 score, it is more interesting for real-life work loads where JSR/RTS are very common instructions.  But otherwise there is no caching anywhere in this -- it is all raw, predictable cycle times, which helps make it feel like a simple 8-bit computer, albeit a very fast one.

What isn't entirely obvious here is that keyboard input has broken for some reason, with my PS/2 keyboard reader failing to detect key-release events.  Also, for some reason the CIA interrupts are not always happening as often as they should.  Combined with not being able to use the C65 ROM, this means I had to side-load SynthMark64 via the serial monitor, start it directly from the serial monitor, and then use the serial-monitor to stuff the ENTER key-press into the keyboard buffer.  So there is still a bit to go, but at least it feels like I am getting somewhere.