interrupts and VDP access

Yes that is correct.

The VDP can only perform one 'drawing related command' at a time, which should thus either come from your main loop, or from the interrupt handler.

If you want to do both somehow, you should wait for the currently running command to finish by checking the CE bit in VDP status register S2. But you can potentially waste a lot of CPU cycles in doing so, of course.

If the "main program" as well as the interrupt routine are completely in your own control, then you can set up some kind of a synchronization mechanism, for example to have the main program disable interrupts during all VDP access routines.

ok, thanks, I got also confused because of the implied ei in BIOS calls...

Accessing a VDP register is done in two steps, out (99H),value and out (99H),register, between those two steps no interrupt may occur because the ISR does an in (99H) (and potentially other VDP access) which interrupts the write sequence. So you di before the first out and ei after the second (or actually right before due to the 1-instruction delay of ei) to prevent issues with the ISR.

The standard ISR does not execute any VDP commands, but of course when you have a ISR hook which does then you need to take care using those in the main loop because they take time to execute and would make the CPU wait in the ISR for the currently running one to complete. Ditto if you’re accessing VRAM on both the main loop and the ISR. There’s no issue when you’re just modifying registers though, or executing only commands on the main loop and only accessing VRAM on the ISR, etc.

Yes, I’m positive. VDP status register reads clear any latched register write value. And a status register read is generally unavoidable on the ISR. So if you didn’t have any issues, you were lucky interrupts didn’t occur at a bad time.

Additionally, worth noting, palette writes use the same latch as register writes. So if you access any register on the ISR you also need to also disable interrupts between every pair of palette writes. You can’t interleave the register and palette write pairs either, but that’s probably not something one would commonly do anyway. And indirect register writes also use the latch, even though nothing actually needs to be latched.

I actually encountered the palette latch issue recently, getting a messed up palette at seemingly random depending on when exactly the ISR would occur :). Though thanks to openMSX emulation determinism between runs I was able to debug it easily.