This could just be a issue on mono mode aswell. Though looking again, I see the scanline is starting to late and actually overlapped down to the next line. I thought it was just shifted to the right., not wrapping around to the next line. Thats like the shifter is not outputting data soon enough for some reason. Then the vertical count gets clocked and it finishes off the last 40 off pixels on a new scan line.
I assume here the MMU keeps count of when the shifter needs to output data, as opposed to just blank border space??
It could just be a mono related problem. The GLUEs video timings will be different, so syncing to the 2mhz clock is probably not timing right for mono mode. Maybe just swap it for a 4mhz clock and see what happens ?!
I also just realised the NAND used is using a NAND to invert the output, So really that should just be a AND gate ?
I have been reading this which gives a lot of good info http://alive.atari.org/alive9/ovrscn1.php
The MMU uses the Vsync signal to reset the video counter with the contents of $FFFF8201 and $FFFF8203.....The DE (Display Enable) signal tells the SHIFTER when to display the border
and when it has to display the usable screen. It also tells the MMU when to send data to the SHIFTER:
Those values can't be right for some reason. Maybe the DE is being driven when its not supposed to so those counters are not being reset ? Maybe that 2mhz input to the AND should be ORed with the Vsync signal ?
It may help if (arne) can measure DE in relation to Vsync. I don't know if DE is supposed to be LO or HI during the vsync pulse. Possible it does not care eitherway...