VDP1 manual change/erase.

[mrkotfw]

I'm pretty confused with how this all works. The VDP1 manual isn't terribly clear either.

At VDP1 initialization, go from 1-cycle mode to change-mode.

1. At the start of VBLANK-OUT (when the VBLANK-OUT IRQ is fired), set PTMR=0, VBE=0, and a FB swap will occur IF we set VBE=FCM=FCT=1
2. Poll until at the start of VBLANK-OUT and perform application logic, between scanlines (0,224/240)
3. At the start of VBLANK-IN (when the HBLANK-IN IRQ is fired) , set VBE=FCM=FCT=1 under two conditions
   1. We're at the 224/240th scanline
   2. The application is ready to draw (a flag can be set to indicate this)
4. When the application is ready and we're at the 224/240th scanline, write to VDP1 VRAM, then set PTMR=1 to draw
5. Loop to step 1

Is this correct?

What confuses me is when I can actually access VRAM. The case that I'm thinking of is when the application logic goes past VBLANK-IN and onto the next frame. If the application logic stops at say, scanline 150, then would I have to wait until the start of VBLANK-IN in order to write to VRAM? Wouldn't I just see if BEF=1 and CEF=0 for the EDSR register? This effectively avoids any bus conflicts?

So to bypass the issue above, I would check if I did a frame change. If so, wait for the start of VBLANK-OUT, otherwise, poll for BEF=1 CEF=1, then perform step 4?

What about the case where the VDP1 is still drawing and the FB is swapped?

 

[mrkotfw]

I figured it out.

I'm seeing now that the bottom 40 pixels don't get erased. The manual states that if there is not enough time to clear the rest of the back framebuffer, I have to use polygons to do the rest. In the VDP1 manual, there is a section that denotes how many pixels the VBLANK erase/write can handle. It's much less than the amount that is on the screen. It decreases very much as the resolution increases.



What surprises me is why 1-cycle mode doesn't have this issue. Anyone know why?