I have found and fixed abut in the TRB (Test Reset Bit) instruction. This is a handy little instruction for clearing bits in byte. For example, LDA #$01 / TRB $D030 will clear bit 0 in $D030, which on a C65 will bank out the second kilo-byte of colour RAM from $DC00 - $DFFF so that you can see the CIAs again. The correct calculation for the result is (memory and (not A)), but I had (memory and A), which has the effect of reseting all of the bits except the one(s) you wanted reset. Needless to say that wasn't working too well.
I also fixed some bugs with IO mapping. In particular, the SD card controller is visible to the CPU again, and Kickstart even gets as far as loading the master boot record from the SD card. There does seem to be an out-by-one error with the buffer addresses, such that the whole sector is rotated by one.
Here is Kickstart finding the SD card at 48MHz:
That looked a bit boring, so I wrote a little loop to do some raster effects:
loop LDA $D052 ; VIC-IV physical raster line low bits (range 0 - 1199)
The loop should increment and decrement $D020 just once at the start of each raster line. However it looks like the compare instructions are using a fixed value, instead of the operand, which is why there are a few rasters on which there are no bars, while the rest fail to properly compare the raster number with itself.
This is due to a bug in the compare instructions, which I have yet to get to the bottom of. My gut feeling is that it is some sort of timing bug, where the wrong value is read from the bus. I have seen it in simulation once or twice, which suggests that I should be able to analyse it fairly easily to find and fix the cause.
Meanwhile, it is interesting to look at the pattern and how narrow the stripes are. They are actually almost half the width that they seem at first when you look closer, because of the adjacency of the bars on successive raster. The following image makes this a bit clearer:
The VIC-IV runs at 4x the CPU clock, so every four physical pixels corresponds to once CPU clock tick. The logical pixels of the character generator are five logical pixels wide here, so one and a quarter CPU clocks wide.
INC and DEC take seven cycles on my CPU at the moment, due to the need to include wait-states to avoid back-to-back memory accesses at 48MHz. This should equate to 7x4 = 28 pixels, or about five and a half logical pixels, just over half a character wide, which is pretty much what we are seeing.
On a real C64 the same bars would be almost 10x wider, at six characters or 48 pixels wide. So even allowing for the massively higher pixel clock on the C65GS (192MHz versus 8MHz on the C64), there is certainly scope to do some pretty interesting tricks. Vertical raster bars and split screens should both be quite possible, although there are probably easier ways to get the same effects.