Una idea por pasos para depurar (me sirvió muchísimo cuando tuve que poner código directo de VDP):
1. Aisla todo el código de VDP en un solo punto.
2. Asegurate de que los DI/EI solo se usan en ese punto y tal vez al inicio del programa.
3. Si escribes o lees del VDP (DB 98 / D3 98), debes esperar 28 ciclos antes de cambiar la dirección (D3 99). Debes visualizar el código como una lista lineal de instrucciones.
4. Las escrituras (D3 99) afortunadamente no necesitan NOPS. Se sugieren 28 ciclos antes de poner a continuación el (DB 98 / D3 98)
5. Haz una lista de todas las llamadas, pudiera ser que una rutina llama a otra que era diferente antes.
6. Si sigue fallando, desactiva partes sospechosas del código.
Como referencia, los NOP ocupan 5 ciclos.
¡Ánimo!

¡Que buena noticia  !

Si hubiera visto tu post desesperado te hubiera pedido una volcado de la memoria para haberlo metido en mi emulador, porque no hubiera sido difícil añadirle algo de código 'ad hoc' para monitorizar que todas las escrituras al VDP fueran coherentes, no sólo la velocidad, si no que por ejemplo no se envíe un byte bajo de dirección de vram que luego no tenga efecto por una interrupción o un IN, o quizás listados de las posiciones que van tomando los punteros para poder revisar después, porque los fallos así intermitentes y aleatorios son puñeteros de pillar con un debugger normal

No sé si hay algo ya parecido en algún emulador, porque quizás sea una buena idea añadírselo al meisei como lo de escrituras rápidas.

(Ah, y muchas gracias por incluirme en los créditos  )

Me refería a modificar el emulador con código específico para acorralar el problema. Se puede hacer casi cualquier cosa desde dentro para intentar forzar el fallo, poner alertas todo lo complejas que quieras, trazar escrituras o lecturas, medir timings del vdp, acortar o alargar los ciclos por INT, contar ciclos...