Swapping in/out background/sprite tiles

[iNCEPTIONAL]

How many [4bpp] background/sprite tiles can the Genesis dynamically swap in/out of VRAM each frame typically?

I'm just looking for a single number like it's around 10 tiles, 100 tiles, 50 tiles, however many tiles it is.

[TmEE co.(TM)]

Theoretical maximums in each resolution :

Code: Select all

Number of tiles that can be transferred per frame :
+---------+---------------------------+---------------------------+
|         |            50Hz           |            60Hz           |
|         +-------------+-------------+-------------+-------------+
|         |    V224     |    V240     |    V224     |    V240     |
|         +------+------+------+------+------+------+------+------+
|         | H256 | H320 | H256 | H320 | H256 | H320 | H256 | H320 |
+---------+------+------+------+------+------+------+------+------+
| Active  |  112 |  126 |  120 |  135 |  112 |  126 |  120 |  135 |
| Passive |  459 |  563 |  375 |  461 |  193 |  237 |    0 |    0 |
| A + P   |  571 |  690 |  496 |  596 |  305 |  363 |  120 |  135 |
| Blanked | 1633 | 2005 | 1633 | 2005 | 1367 | 1678 | 1252 | 1537 |
+---------+------+------+------+------+------+------+------+------+

*Active are the lines where VDP renders stuff
*Passive are border and blanking+sync area
*A+P is both combined
*Blanked is rendering turned off for entire frame

Bytes that can be transferred in Active vs Passive line :

Code: Select all

+---------------+------+------+
|               | H256 | H320 |
+---------------+------+------+
| Active scan   |   16 |   18 |
| Passive scan  |  167 |  205 |
+---------------+------+------+

[Matt Grum]

I have a different question if you don't mind. I assume the numbers in that table are for DMA transfers. I've seen a lot of people quoting the official SEGA development manual as saying:

The DMA is quite fast during VBLANK. About double the tightest possible 68K loop speed, but during active scan the speed is the same as a 68K loop.

From the quoted numbers it seems DMA is about 10 times faster when the display is blanked. Does this mean that writing data to the VDP using the 68K is also faster during V-blank, but only 5x faster not 10x?

Also if DMA is faster when the display is blanked, why is the amount of data that can be transferred slower when using the narrower 256 tile mode - I would expect H-blank to be longer in this mode.

[iNCEPTIONAL]

Theoretical maximums in each resolution :

Code: Select all

Number of tiles that can be transferred per frame :
+---------+---------------------------+---------------------------+
|         |            50Hz           |            60Hz           |
|         +-------------+-------------+-------------+-------------+
|         |    V224     |    V240     |    V224     |    V240     |
|         +------+------+------+------+------+------+------+------+
|         | H256 | H320 | H256 | H320 | H256 | H320 | H256 | H320 |
+---------+------+------+------+------+------+------+------+------+
| Active  |  112 |  126 |  120 |  135 |  112 |  126 |  120 |  135 |
| Passive |  459 |  563 |  375 |  461 |  193 |  237 |    0 |    0 |
| A + P   |  571 |  690 |  496 |  596 |  305 |  363 |  120 |  135 |
| Blanked | 1633 | 2005 | 1633 | 2005 | 1367 | 1678 | 1252 | 1537 |
+---------+------+------+------+------+------+------+------+------+

*Active are the lines where VDP renders stuff
*Passive are border and blanking+sync area
*A+P is both combined
*Blanked is rendering turned off for entire frame

Bytes that can be transferred in Active vs Passive line :

Code: Select all

+---------------+------+------+
|               | H256 | H320 |
+---------------+------+------+
| Active scan   |   16 |   18 |
| Passive scan  |  167 |  205 |
+---------------+------+------+

OK, that is very cool. You went above and beyond what I asked but still kept it actually understandable for me, which is ideal. Thanks for that.

So, 237 passive and 125 active in H320 V224 mode at 60 Hz seems like the most typical one that would be used there in say a normal Genesis fighting game, correct?

Now, what's the cost of swapping in/out new tiles during active if any? Does it corrupt sprites or backgrounds, take up the CPU, or any other stuff that might be an issue if trying to do this in the middle of a fighting game for example? Or is swapping in/out tiles during active basically free?

And would you speculate that the typical fighting game on Genesis is basically swapping out roughly the full 237 passive [and 125 active?] sprite tiles during each frame to animate both the fighters, which I guess also determines the max size the fighters can realistically be too?

Any other tricks you know about that are used or could be used to increase the amount of sprite tiles being swapped in/out per frame in a fighting game, or are all the Genesis fighting games basically working within the 237 passive and 125 active limit as far as you know?

Sorry for all the questions, but thanks for any insights here.

[TmEE co.(TM)]

In general you do not count Active lines as part of your budget since that is where your game logic runs and in general games do not try to update VRAM in that time but do their logic, wait for Passive scan to start and then start the necessary transfers. So that 237 tiles is the absolute maximum you can fully count on without doing any tricks.

Some games like Street Fighter blank the display early to boost VRAM bandwidth, each of those blanked lines counts as Passive and has maximum VRAM bandwidth available and without doing so there isn't enough time to update all the anims etc. in time. It is all game specific if that is needed or not. There are no corruptions etc., not with data itself as MD VDP will stall the CPU until all pending data gets written, unlike SNES where access at a wrong time will silently fail and data corruption is possible. Disabling rendering and reenabling it at the wrong time can cause some garbage pixels like seen under the screen split in Sonic2 2 player mode but this is not a concern when you letterbox the display.

In the end all that matters is that passive or blanked line has all 205 bytes available (disregarding any CPU overhead), but because video stuff and CPU run in parallel and if CPU manages to trigger the first DMA halfway through the line, half the VRAM bandwidth of that line is gone, the ship has already sailed essentially lol. A game that really wants to maximize things will try to synchronize itself with VDP and use fastest possible code to minimize gaps between the transfers so that there are least amount of wasted access slots. The 237 tile number from the table is only possible for one long transfer that is triggered right as the passive scan begins, several fragmented transfers will always reach a lesser number. This is true for every game console, the individual parts all run in parallel and if you miss the access window you lose it.

I have a different question if you don't mind. I assume the numbers in that table are for DMA transfers. I've seen a lot of people quoting the official SEGA development manual as saying:

The DMA is quite fast during VBLANK. About double the tightest possible 68K loop speed, but during active scan the speed is the same as a 68K loop.

From the quoted numbers it seems DMA is about 10 times faster when the display is blanked. Does this mean that writing data to the VDP using the 68K is also faster during V-blank, but only 5x faster not 10x?

Also if DMA is faster when the display is blanked, why is the amount of data that can be transferred slower when using the narrower 256 tile mode - I would expect H-blank to be longer in this mode.

There are 488.57 68K cycles per line, unrolled MOVE.L (A0)+, (A1) takes 20 cycles and can transfer 4 bytes which gives at most 97.7 bytes per line which is a bit under half the speed of what DMA can do in passive scan where it can hit every VRAM access slot (one every 2nd pixel for the most part, but there are few used up by VRAM refresh). If there's any overhead such as loop instruction the number will be far less compared to DMA but if you only have to write a static value or can fit some pattern into Dx regs you can have a little higher bandwidth but still not reaching DMA speed.

During active scan there are 18 access slots (in H320) per line, of which most are spread out in 16+16+16+32 pixel fashion and 68K can hit all of them so there won't be any difference in speed compared to DMA other than when DMA runs, 68K and its bus are off limits and Z80 will not be able to access ROM area which will mess up any careful timings on that side (bye bye clean PCM playback). In general you shouldn't be doing transfers in active scan unless you absolutely have to and not using DMA is the better way as it won't stall Z80 unless FIFO gets filled. For passive scan you should use DMA as much as possible, only case where 68K is faster is when DMA setup time takes longer than data transfer time in a 68K loop but this calculates to about 2 tiles worth of data at most so it only makes sense to use 68K for small updates such as setting scroll values etc.

[iNCEPTIONAL]

In general you do not count Active lines as part of your budget since that is where your game logic runs and in general games do not try to update VRAM in that time but do their logic, wait for Passive scan to start and then start the necessary transfers. So that 237 tiles is the absolute maximum you can fully count on without doing any tricks.

So, just to be clear on something I've never quite understood as a non-hardcore-programmer (I've just dabbled a little in some C variations and GML), is game logic being run during active, passive and blanked scanlines then, and that's how it typically works? If this is the case, I would still assume the bulk of the game logic is run during the passive lines normally then, since I would also assume nothing else is going on there otherwise, correct?

If that's not how it works, could you give me a very quick layman explanation of how it actually works in terms of when the logic is actually being run in those three places?

It's just something I've never really got, as I always assumed the image is drawn during active and pretty nothing else happens there because of that, the game logic and other code stuff is typically run during passive (the VBlank time, typically shown in visual examples as a big block of nothing off the bottom of the screen, and maybe HBlank if possible too), and you can force some more time for whatever code, logic and VRAM-type stuff with forced blanking, but obviously that's not quite right.

[TmEE co.(TM)]

Think of it this way :

VDP and CPU are two runners on a track, the track has the length of one frame and both of them start at the same time.
VDP does different things depending on what distance it has reached on the track and there are two major sections on the track for it :
*Active part - where it renders image output according to VRAM etc. content
*Passive part - where it does nothing but shows a solid color in normal circumstances

Both CPU and VDP start at the same time, and they're evenly matched and will always finish at the same time but for CPU to make VDP do something it wants it needs to do it at the right time.

Normally when VDP is doing active rendering and won't have much time for any CPU attention so you do stuff on the CPU that won't need attention from VDP such as processing input and calculating game logic and preparing all the things necessary for when VDP is available to use. This is more or less universal across different consoles, although Atari 2600 is one big exception, it works in a fundamentally different way lol.

If your game logic takes more time than length of the track you get slowdown and possble graphical glitches etc. if the CPU manages to do something to video system when it cannot accept stuff which may be the case on NES and SNES which are unforgiving to accesses outside the required positions during the frame/track. It is why your game logic needs to fit into one frame and be short enough that it won't spill into the passive scan where you lose out on massive amount of VRAM bandwidth, although a game that won't do much can possibly afford it.

You already know CPU has some control over what VDP actually does, such as early blanking to get all the bandwidth of a passive line so the race can change a little but they will always finish at the same time and run at exactly the same pace.

In a full console there's also the sound chip and any additional CPU or coprocessor at play too, all of which run simultaneusly with similar kind of limits and features. It is all a *realtime* system (and especially A2600 lol) and you got to know when something is available (or not) in reference to what all the things share, such as frame interrupt which tells when frame starts/ends. Frame interrupt is the only means of synchronization on NES for example, MD, SMS and SNES also offer line interrupts and even readback of which line and pixel is currently being rendered which can be used to one's advantage.

On a computer this is usually not possible to do because of wildly different configurations so assumptions that you have fixed amount of CPU cycles etc. all go out the window, there isn't any kind of consistency to rely on other than perhaps Vsync, which will still run anywhere from 60Hz to few hundred Hz lol

[iNCEPTIONAL]

Thanks for all the considered responses, TmEE. This is really helping me understand a lot of this stuff much better. I mean, it's still complex, but it's becoming more comprehensible.

"It is why your game logic needs to fit into one frame and be short enough that it won't spill into the passive scan where you lose out on massive amount of VRAM bandwidth, although a game that won't do much can possibly afford it."

So, just to check the bit above: That seems to be saying that the bulk of the game logic runs during the active scan for the most part (that's what you mentioned previously too), which begs the question, what's mostly done during the main passive scan period typically then (the VBlank time, right)?

I'm definitely seeing all of this stuff much differently to what I thought it was literally a day or so ago.

[TmEE co.(TM)]

Game does its logic, which probably finishes before Active scan is finished, then it waits until it does finish and Passive scan starts and does all the VRAM etc. updates, after than it waits for Passive scan to end and Active to start and the whole process repeats. That is the basic structure of the main game loop on pretty much all hardware that has to synchronize to video output.

[iNCEPTIONAL]

OK, cool. Thanks very much.