• Rise from your gwave!

Is VDP1 manual change possible with double-density interlace?

Discussion in 'Saturn Dev' started by mrkotfw, Oct 28, 2018.

  1. mrkotfw

    mrkotfw Member

    I'm running some tests and I have the following (VDP1+VDP2 normal resolution, non-interlace):

    0. Set up list of commands in H-WRAM
    1. Transfer commands from H-WRAM to VDP1 VRAM
    2. Draw. PTMR=1
    3. If drawing is done (Sprite End IRQ fired) before VBLANK OUT IRQ, perform FB change. FBCR=3
    4. Go back to step 0

    Essentially the above would allow me to perform as many "draw calls" as I like, and only change framebuffers when I'm done.

    As opposed to 1-cycle mode where I must always finish drawing before V-Blank OUT IRQ is fired.

    However, this doesn't seem to work for double-density interlace, as expected. Note above, I DO NOT call to erase the framebuffers (FBCR=2). Instead, the command list has a large polygon to erase the FB.

    How would I approach this? Do I check VDP2(TVSTAT) for even/odd field scan and set FBCR=8 (DIE) and FBCR=12 (DIE|DIL), respectively during VBLANK-OUT?

    I ran a test where I draw as normal (as explained above), and I go through two frames, each time setting FBCR=8 for even field, and FBCR=12 for odd field. No swapping of framebuffer.

    Though, this isn't working. I get massive flickering.

    How do I approach this? Draw twice? Does calling FBCR=8 and FBCR=12 swap the framebuffers for me?

    Any bit of info would help!
    Last edited: Oct 28, 2018
  2. mrkotfw

    mrkotfw Member

    I'm completely in the dark here. Is it only possible to render via PTMR=2 when double-density interlace is enabled?

    My goal is attempting to allow sub-30 FPS when double-density interlace is enabled by not swapping frame buffers. But now that I think about it, such a thing is not possible since both buffers are required to display a single frame.

    At VBLANK-IN, I'm seeing if VDP1 is still drawing. If so, I set PTMR=0, which causes flickering.

    Can anyone convince me that this is, or is not the case?
  3. mrkotfw

    mrkotfw Member

    Detect "transfer over" and perform pseudo draw continuation.

    I'm making this more complicated than it needs to be. What I proposed above would be good if I had a third buffer. But I don't. It really sucks that I can't choose where to render.

    It's really not easy to keep both VDP1 and VDP2 synced. It's a major PITA with timing, features, and all the edge cases...

    Any other suggestions/ideas/features, I'd like to hear them.

    Here is vdp_sync(). It doesn't yet include support for double-density interlace video modes.

    The idea is to send a command list via vdp1_sync_draw(). You can send the VDP1 as many lists, and for every call, it'll draw immediately. All command lists are sent via SCU-DMA as well.

    Then a call to vdp_sync() will "commit" VDP2 state and request to change VDP1 frame buffers.

    Is there a way to know what the cost is to stop/start VDP1 drawing?
    XL2 likes this.

Share This Page