SpritesMind.Net

I've been thinking about games where graphics data is transferred to VRAM repeatedly (namely Virtua Racing), and the slow speed of DMA really impacts things. But not much can be done about that.

Can somebody tell me if my calculations are off? Imagine this hypothetical scenario (I realize VR uses 32-cell mode instead):

40-cell mode, 256x192 centered viewport (just using Plane B, maybe A or the Window to mask the area outside it), screen is blanked for all other scanlines. 768 tiles are needed to define the display, that's 24K and let's double buffer it for 48K total. Now we can do DMA to one set of tiles while displaying the other.

So you get 263-192=71 lines of high-bandwidth access to the VDP. DMA to VRAM is 205 bytes/line in 40-cell mode, 71*205 = 14555 bytes/frame. That's not close to the 24K we need, going down to 30 FPS means we require only 12K per frame which is about 60 lines of DMA. Is this actually obtainable or are there other sources of delays?

To simply things, let's assume the 68000 isn't doing anything other than DMAing data to VRAM, CRAM, VSRAM, reading joysticks and sending the odd command byte or two to the Z80 once per frame. And the Z80 isn't accessing banked ROM. Maybe all the game logic is running elsewhere like the SVP's DSP or Sega CD's 68000.


Also, does the SVP render graphics data directly in the 4-bit tile format (I guess doing a lot of read-modify-write operations to insert new polygons), or is there some hardware assistance involved? I know on the 68000 side there are some memory areas that swizzle memory around, but nothing but the diagnostic code uses it and I don't know if the SVP has a similar "swizzled" window to the 128K RAM to assist in making tile-format data, which would otherwise have to be done in software.

For the first part i can reply that doing 30 FPS in this case is possible, i actually did it just to test the maximum VRAM transfert rate. I used the 40 cells mode with a very similar resolution and blanked the VDP to maximize the transfert capabilities... there is not any others delays i can think of and as 68k is locked until DMA complete you just have to take care about not accessing 68k bus from Z80.

I don't know about the SVP 4 bits rendering, i think a very simple hard logic exist to convert 8 bit to 4 bit tile as it's very uncommon to do software 4 bit tile polygone rendering... or it would be a big waste of performance :-/
I guess there is something similar to what we have in the Sega CD hardware.

in 50Hz you'd get near 24KB/sec transfer rathe though

MD sucks in 60Hz

Charles MacDonald wrote:Also, does the SVP render graphics data directly in the 4-bit tile format (I guess doing a lot of read-modify-write operations to insert new polygons), or is there some hardware assistance involved? I know on the 68000 side there are some memory areas that swizzle memory around, but nothing but the diagnostic code uses it and I don't know if the SVP has a similar "swizzled" window to the 128K RAM to assist in making tile-format data, which would otherwise have to be done in software.

It seems to render in 4bpp and uses hardware assistance for polygon overwrite and addressing (to do output in tiles). I could not find evidence of "swizzled" window on SVP side though. See 2.2.7 of my http://notaz.gp2x.de/docs/svpdoc.txt .

notaz wrote:See 2.2.7 of my http://notaz.gp2x.de/docs/svpdoc.txt .

Ah! I really should have read that first before posting! Everything is in there.

Stef, glad to hear you tested it and it really works, that means I don't have to do any programming now and can be lazy.

TmEE, good point, too bad no PAL-only games took advantage of such a high transfer rate somehow. But 50 Hz flickers too much for my tastes.

Charles MacDonald wrote:TmEE, good point, too bad no PAL-only games took advantage of such a high transfer rate somehow. But 50 Hz flickers too much for my tastes.

Some does, as Super Skimarks but they are rare...