Exactly. But I'm not able to find the condition that produces that. It is really interesting to know that something similar is happening to you.
I've spent some time this morning looking again at some captures and at the firmware sources. I've seen that:
- The CPLD seems to properly run the NMI detection check in $207. I can see how the NMI generator is turned on, then off, and a NMI pulse comes in between.
- Then I see how the NMI pulses for the upper blank lines are generated.
- Afterwards I can see the HALT pulses for the screen rendering.
- Then the bottom blank lines.
- Then back again the upper blank lines.
- Then the HALT (I assume the one in NMI-CONT)
- Then... silence.
But there's something weird here, for whatever reason, the pulse-train length of the bottom blank lines is quite different to the length of the upper blank lines. I've put some markers to find that from first NMI pulse to HALT (in NMI-CONT) they spend 3.2 ms and 2.1 ms respectively.
Looking at the period of the NMI pulses in both trains, they are also pretty different: 39,3 us versus 63,7 us (with the original ULA I measure 62,2 us). The NMI pulse width itself seems to be consistent (around 5.125 us). Take into account that I'm sampling at 16Mhz, so I assume that an error of ~ 0,06 us should be considered. I haven't found difference in the CPU clock frequency or duty cycle in these zones, so there should be another reason for this weird behaviour.
Sadly it seems that this is not consistent in all captures. I have another one where the period of the NMI pulses stays around 63,7 us and the NMI generation also get stopped suddenly. The weird thing in this case is that I can see the IOREQ/WR operation to disable the NMI, but I cannot see the previous HALT, even worse in this case I can only count 52 pulses in the pulse train.
Probably two different problems, no idea if related or not.