VDP transfer

tryphon · Post by **tryphon** » Sat Jul 25, 2015 9:47 am

I know this question has been debated, but I don't find where, and the answer may be splitted in several threads so here it is again:

How many patterns (genvdp's terminology : 8x8 tile) can you send in VRAM between 2 vblanks ?

Second question : is DMA the fastest way to do it, if the patterns are not necessarily contiguous in ROM ?

Stef · Post by **Stef** » Sat Jul 25, 2015 11:05 am

Usually you do your transfers to VRAM during VBlank as VRAM accesses are much faster during blanking period.
So in this case you can transfer at max 262-224 = 38 scanlines * ~205 bytes per scanline = 7.8 Kb of data per frame.
But you should consider 7 Kb (about 220 patterns) as a more realist maximum you can actually transfer per vblank. Also you have to consider than pattern data are not the only data to transfer (you may also have the sprite list or tilemap data).
Then now if you really want to transfer more than this, you can extend the blanking area or try to transfer during active period but then your transfers will be much slower (and using the DMA quite useless here).

tryphon · Post by **tryphon** » Sat Jul 25, 2015 1:21 pm

Thanks for your helpful answer, as usual

Stef wrote:Usually you do your transfers to VRAM during VBlank as VRAM accesses are much faster during blanking period.

I didn't know that. Interesting

So in this case you can transfer at max 262-224 = 38 scanlines * ~205 bytes per scanline = 7.8 Kb of data per frame.
But you should consider 7 Kb (about 220 patterns) as a more realist maximum you can actually transfer per vblank. Also you have to consider than pattern data are not the only data to transfer (you may also have the sprite list or tilemap data).

Yes, normally that should be enough. But I prefer to anticipate..

Then now if you really want to transfer more than this, you can extend the blanking area

I don't know what you're referring to. Have you a reference ?

Stef · Post by **Stef** » Sat Jul 25, 2015 2:07 pm

That means you reduce the vertical resolution to increase the blank area.
For instance you can force to enable blanking (= disable VDP) on scanline 224-16 = 208th and re-enable VDP on scanline 16th. This way you add 16 blank scanlines at the top and 16 blank scanlines at the bottom, reducing vertical resolution to 192 pixels but then you have now 32 extras scanlines for fast VRAM transfer (which is a lot, almost doubling your initial frame transfer budget)

To do that you need to use h-int (so you set code to disable / enable VDP on specific line).

ob1 · Post by **ob1** » Sat Jul 25, 2015 7:14 pm

Stef wrote:To do that you need to use h-int (so you set code to disable / enable VDP on specific line).

Can't we use the VDP status to guess line number ? Is it not precise enough ?

Stef · Post by **Stef** » Sat Jul 25, 2015 9:40 pm

ob1 wrote:
Stef wrote:To do that you need to use h-int (so you set code to disable / enable VDP on specific line).
Can't we use the VDP status to guess line number ? Is it not precise enough ?

Oh yeah you can use H-Counter but then you do a passive wait... probably not possible depending your code

tryphon · Post by **tryphon** » Sat Jul 25, 2015 11:27 pm

I'd like to keep my 224 lines safe anyway. But the trick is good to know, thanks

tryphon · Post by **tryphon** » Thu Jul 30, 2015 8:41 pm

Stef wrote:Usually you do your transfers to VRAM during VBlank as VRAM accesses are much faster during blanking period.

It leads to another question : what's the cleanest way to add code to VBLANK routine while keeping its behaviour?

tryphon · Post by **tryphon** » Fri Jul 31, 2015 12:52 pm

Edit : let me guess...

Code: Select all

void my_vblank_routine(void) {
    // my code
}

SYS_setVIntCallback(my_vblank_routine) ;

?

Edit2 : there's still something that bothers me. I use VDP_updateSprites(), so I suppose that SGDK maintains a sprite table in RAM, and that function VDP_updateSprites() copies this table to VRAM.

Is it done exactly when VDP_updateSprites() is called, or, for performances reasons, is it delayed to the next VBLANK (and thus VDP_updateSprites would only set a flag) ?

Is the later, won't there be a problem if, during VBLANK, the sprite table is copied BEFORE my DMA copy is done ? (because in _vint_callback code, it's clear that the custom VIntCallback is called after almost eveything but palette fading).

tryphon · Post by **tryphon** » Sat Aug 01, 2015 10:41 pm

I tried and it seems VDP_updateSprites ships the SAT immediately. So it was done before the patterns were actually sent.

So I moved the VDP_updateSprites inside my VIntCallback, and there are no problems. From the games I studied, most of the time, the copy of the SAT in RAM to VRAM is done during VBLANK, so I bet it's not totally wrong