Home	Forums	What's new	Resources

Is VDP1 manual change possible with double-density interlace?

mrkotfw - Oct 28, 2018

		mrkotfw		Oct 28, 2018
			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!

		mrkotfw		Oct 28, 2018
			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?

		mrkotfw		Oct 29, 2018
			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?