K051960: logic does not agree with software usage
jotego opened this issue · 1 comments
I am debugging weird sprite glitches on Aliens. They seem to be related to how the sprite DMA logic works. What I get from your RE research is that at the VB edge the active-low DMA enable register is latched (bit 4 of REG0), and from that moment on, the DMA triggers: an internal RAM buffer is cleared and then filled with the relevant sprite data for the next frame.
But Aliens sets REG0[4] high right after the VB interrupt and it starts writting to the sprite RAM soon after. According to the RE schematics/verilog, it looks like REG0[4] is ignored after the VB edge, which means that the DMA will run side by side with the CPU writting to the memory. The effect is that occasionaly corrupted data is shown on screen.
The waveforms show how REG0[4], called obj_enb in the sim, is always set for each sprite RAM update cycle. Check out the orange (CPU writes to sprite RAM) and red (obj_enb) waveforms. Also notice how the sprites are only updated every other frame.
obj_enb is set low again some 375us before the end of the blanking period. That's too short to copy the data to the internal buffer as just clearing the buffer takes 341us. Maybe the clearing can occur in parallel but copying the new data must wait for obj_enb to be low again? That would make more sense than leaving the old sprite data in the buffer and drawing it again.
So I do not know what is going on at the moment, but it looks weird. Maybe the flip flops you shown are actually level-enabled latches and the logic works in a different way?
Sorry, I think it was a false alarm. It looks like I had to invert the status bit that the CPU can read from the sprite chip. By doing that, the CPU writes the sprite data during the active video time, which makes sense:
