Background D020 updates late after raster interrupt?

[dansanderson]

A simple assembly language program that sets a raster interrupt for line 200, changes the border (D020) and background (D021) to black (0), counts down from 255 in a short busy-loop, then changes the border and background to white (1) demonstrates that the background does not change until just more than half way across the raster line, for both transitions. The border appears to transition on the first of the two raster lines. This is not explained by CPU cycles spent in the interrupt handler code, at 40 MHz.

I don't actually know if this is unexpected behavior for a C65 or a C64. Is there a known trick to this? Note that at 40 MHz there is no visible "stability" issue often discussed in the context of a C64 1 MHz interrupt.

raster_hwirq.asm.txt

[dansanderson]

I can get the background change position to flicker steadily by eight-ish pixels (just eyeballing) with minor code changes. It would be surprising if this is CPU cycle slop in the interrupt, and seems more likely to be related to when the VIC recognizes a new border color.

I also tried a version where I cycled through 16 colors across 16 adjacent lines, one interrupt per line, and saw an interesting pattern of variability, stable by line position. So that might also suggest the background color change happens at different times based on raster vertical position.

[ki-bo]

This is probably related to MEGA65 and no C65 behavior. My feeling is that you see pre-rendered characters where the bg color was still white when the rendering happened (chars are not rendered in real-time, but are rendered into the raster rewrite buffer first, and then those pre-rendered pixels are pushed to the video output later). Rendering of chars probably starts at the end of the previous raster line, and parts of the text are already ready when you change the bg color.