That bloody VLSI CRTC chip! Life would be a lot easier if we could just ship a Hitachi version to everyone who currently has the VLSI one!
Anyway ... Rich Talbot-Watkins, Tom Seddon, myself and others have been discussing this and thinking about ways to fix it.
It's worth emphasising that we're sort of shooting in the dark at this point, we *think* we have an idea what's going on but there's still a lot that is unclear.
That being said, the current hypothesis is that on the VLSI variant, you need to set R4 (vertical total) before the start of a frame. It looks like once a frame has begun, if you subsequently set R4, that value won't be honoured until the start of the next frame.
This is in contrast to the Hitachi/Motorola/Toshiba variant, which compares C4 with R4 at the beginning of every raster line. So when you set R4, that new value will be honoured from the start of the next line.
With reference to that rupturedebug.ssd sample code, this means that if you're on a VLSI variant, you need to set R4 *before* the frame starts ... but you still want to set R12/R13 *after* it starts. The code as written sets both R4 and R12/R13 after the frame starts.
The magic adjustment value -24 seems to work because it's the perfect amount to make the Timer1 IRQ fire earlier just enough that the code is setting R4 at the end of the previous frame and then R12/R13 at the beginning of the next one.
However, the timing is extremely tight which makes me nervous. So how do we fix this?
Simple. We move the setting of R12/R13 *after* we've reset the timer latch values and interrupt handler address. So both IRQ handlers now do "Set R4, then set timer latches and IRQ handler, and then set R12/R13" instead of "Set R4, Set R12/R13, set timer latches and IRQ handler".
When you do that, you get a bigger time window to play with. On VLSI CRTC values of between 22 and 36 seemed to work fine, and on Hitachi/Motorola/Toshiba it really didn't care either way by a larger amount.
Attached is a test SSD that contains an example program (thankyou creators of Owlet!) that asks for an adjustment value each time it's run. You can run it on a VLSI machine and confirm that values of 22 to 36 seem to work OK. My feeling would be to choose one which is more conservative, e.g. perhaps 34, but of course I have no idea whether this will actually work within Acorn Island!
Hope this is helpful!
You can also see this code using the Owlet link below. The only difference from rupturedebug.ssd is the addition of adjustment to t1%, and the moving of setting R12/R13 after setting all the other stuff in the two IRQ handlers.
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... ALSE%22%7D
. Will need to take a closer look but it sounds like I'm missing the frame start. I might put together a couple of options rather than doing one thing at a time.