1. Adjusting the frames to have exactly the right number of raster lines (it was out by one before).
2. Making the video generator provide the PHI clock pulses to the CPU, so that there are always the right number per raster line. As the raster lines are not exactly the right length, this introduces a very small amount of jitter in the cycle durations. However, this will average out to zero over a few raster lines, and so shouldn't produce any audio artefacts.
3. Lots of other miscellaneous fixes.
Anyway, combined with the nice 4:3 digital output via the HDMI port, this means we are now creeping towards a really nice level of compatibility for display timing. Some tricks, like VSP, will take a while before they would be supported by the MEGA65's default FPGA core, but lots of other things should work well now, including most sprite multiplexors etc.
There are still a few rough edges to sort out, in particular there is a bug in the VIC-IV that is preventing it from numbering raster lines in the flyback properly. This stuffs up some raster interrupts etc, and will get fixed fairly quickly, I expect.
In fact, the video and CPU timing are now just about good enough to run the freeze-combined.prg test from the VICE emulator test suite. This nasty little program runs interrupts on both CIAs which are used to draw green and yellow raster bars. A separate raster interrupt runs, which draws a red raster bar. The yellow and green raster bars have accompanying bars drawn in the active part of the display, and to which they should stay lined up. This requires that the CIAs correctly count down, and that each video frame has exactly the right number of cycles, so that they don't drift up or down between frames. And that all now works on the MEGA65 :)
The only part that doesn't, is the grey and pink bars in the active part of the display creep upwards, indicating that the CPU is running slightly faster than it should. This is almost certainly because the MEGA65 always charges 40 clock cycles for a bad line, instead of between 40 and 43 as on the C64. Apart from making this display creep, it is unlikely to be a problem for most programs, as the timing is within 1%, and slightly fast rather than slow.
And finally, since the whole point of this test is to be able to demonstrate freezing and unfreezing without messing up the CIA to VIC to CPU synchronisation, I had a bit of a poke around to fix this. Basically I need to make the freezer always trigger on a fixed raster line, and then have the unfreezer always wait until that raster line before resuming the frozen program. In theory, that should be enough to restore the synchronisation to within a couple of clock cycles. To get an idea of how it should behave, and how it (usually) behaves right now, here is a short video I made:
Fixing this synchronisation will have to wait for another post.