2 scrolling planes (1344–1808 tiles)

[Kirk_Johnston]

So, the Genesis/Mega Drive can have 2 scrolling planes with 1344–1808 [unique] tiles, as per segaretro: https://segaretro.org/Sega_Mega_Drive/Hardware_comparison

 

1. Is that 1344-1808 [unique] tiles per layer for a total of 2688-3616 [unique tiles] for both layers combined, or 1344–1808 [unique tiles] for both layers combined?

 

2. Also, because the backgrounds and sprites share the VRAM, I presume for every [unique] background tile you use, you're effectively cutting down the highest number of [unique] sprite tiles you can use by one (which segaretro says is 1280), and visa versa, correct?

 

3. Lastly, what are the variables that affect the number of [max unique] background tiles (be it per layer or for both layers combined), such that it's not a single number but a range from 1344-1808?

Edited August 16, 2022 by Kirk_Johnston

[Chilly Willy]

VRAM space is used up by the layer A and B name tables (which can be different sizes like 64x32 or 64x64), the Window layer name table, the VSCROLL table (if used), and the sprite attribute table. All of those are mostly variable in size, or may not be used at all. This takes away from the total number of tiles you can have. Tiles can fill all the rest of vram, and are shared by all layers and the sprites. Games like Sonic keep most of the tiles in vram, then load a few on the fly from rom as needed by where you are in the map.

[Kirk_Johnston]

On 8/17/2022 at 7:57 PM, Chilly Willy said:

VRAM space is used up by the layer A and B name tables (which can be different sizes like 64x32 or 64x64), the Window layer name table, the VSCROLL table (if used), and the sprite attribute table. All of those are mostly variable in size, or may not be used at all. This takes away from the total number of tiles you can have. Tiles can fill all the rest of vram, and are shared by all layers and the sprites. Games like Sonic keep most of the tiles in vram, then load a few on the fly from rom as needed by where you are in the map.

That about makes sense, but, just to check on the main question in the original post, is the "2 scrolling planes with 1344–1808 [unique] tiles" referring to the [rough] number of tiles per layer or for both layers combined?

Edited August 18, 2022 by Kirk_Johnston

[Chilly Willy]

Each layer (and sprites) can refer to any or all tiles. There are no tiles restricted to a specific layer or sprite... well unless you have the VDP hooked to 128KB of VRAM, but that is not a concern for the MegaDrive, only the TeraDrive. Tile 0 starts at 0x0000 in the vram, and tile 2047 starts at 0xFFE0 in the vram. The tile number is indeed just the address of the tile data in vram >> 5 (divided by 32, the number of bytes in a tile). Any vram not being used for something else (like a name table) can hold tile data and be used by anything that refers to tile numbers.

[+Gemintronic]

Not an answer but when I want to visualize/understand video memory I use "Gens r57shell Mod".  Google should turn up a good hit right away.

 

Others probably have better suggestions but it's what I've found that lets me see tiles as my homebrew runs.

 

In order to not hurt my small brain I just organize my games by blocks of 256 tiles.  So..

 

1st 256 = Font and UI

2nd 256 = Background and playfield

3rd 256 = Sprites

4th 256 = Special effects, title screens

[Kirk_Johnston]

On 8/20/2022 at 2:01 PM, Chilly Willy said:

Each layer (and sprites) can refer to any or all tiles. There are no tiles restricted to a specific layer or sprite... well unless you have the VDP hooked to 128KB of VRAM, but that is not a concern for the MegaDrive, only the TeraDrive. Tile 0 starts at 0x0000 in the vram, and tile 2047 starts at 0xFFE0 in the vram. The tile number is indeed just the address of the tile data in vram >> 5 (divided by 32, the number of bytes in a tile). Any vram not being used for something else (like a name table) can hold tile data and be used by anything that refers to tile numbers.

So, to be clear in a way the average person can understand easily, the 1344–1808 number in the original post above, as used in the context of the segaretro article regarding Genesis' specs and unique background tiles, is basically talking about a roughly maximum amount of possible unique tiles you can have available in VRAM for any/all background layers (plus sprites), once you take all the tilemap data and stuff like that into account too?

Edited August 22, 2022 by Kirk_Johnston

[Kirk_Johnston]

On 8/20/2022 at 3:34 PM, Gemintronic said:

Not an answer but when I want to visualize/understand video memory I use "Gens r57shell Mod".  Google should turn up a good hit right away.

 

Others probably have better suggestions but it's what I've found that lets me see tiles as my homebrew runs.

 

In order to not hurt my small brain I just organize my games by blocks of 256 tiles.  So..

 

1st 256 = Font and UI

2nd 256 = Background and playfield

3rd 256 = Sprites

4th 256 = Special effects, title screens

That would be 1024 tiles total. But that's not the [roughly] max you could have in VRAM to [practically] use for all those things though, right? What's the [roughly] max number of unique tiles you could have in VRAM to use onscreen at once? Is it the 1344–1808 mentioned in the original post above (once you account for tilemaps and the like too)?

Edited August 22, 2022 by Kirk_Johnston

[Chilly Willy]

1 hour ago, Kirk_Johnston said:

So, to be clear in a way the average person can understand easily, the 1344–1808 number in the original post above, as used in the context of the segaretro article regarding Genesis' specs and unique background tiles, is basically talking about a roughly maximum amount of possible unique tiles you can have available in VRAM for any/all background layers (plus sprites), once you take all the tilemap data and stuff like that into account too?

 

Yes. You start with 64KB, then start subtracting things. For example, a single name table in 64x64 mode takes 8KB of ram (64*64*2). If both layers are used in the same mode, that's 16KB from the 64KB total, so 48KB left. Let's say you use line mode for horizontal scrolling - that takes another 1KB of ram (256*2*2). Let's also say you use all 80 sprites, that's another 640 bytes of ram (80*8). Assuming nothing else, that leaves (64-16-1-.625)*1024/32 = 1484 tiles of ram left. If you don't use the line scrolling, you get more tiles. If you only use one layer, you get more tiles. If you use the Window layer for a HUD, you get fewer tiles. If you use more than 80 sprites (to make it easier to switch between which 80 display at any time), you get fewer tiles. Maybe you make the scroll layers 64x32 to save ram - then you get more tiles. You the programmer control the ram directly on hardware like this, and you need to plan just what you need vs what you have available.

 

 

[Kirk_Johnston]

5 hours ago, Chilly Willy said:

 

Yes. You start with 64KB, then start subtracting things. For example, a single name table in 64x64 mode takes 8KB of ram (64*64*2). If both layers are used in the same mode, that's 16KB from the 64KB total, so 48KB left. Let's say you use line mode for horizontal scrolling - that takes another 1KB of ram (256*2*2). Let's also say you use all 80 sprites, that's another 640 bytes of ram (80*8). Assuming nothing else, that leaves (64-16-1-.625)*1024/32 = 1484 tiles of ram left. If you don't use the line scrolling, you get more tiles. If you only use one layer, you get more tiles. If you use the Window layer for a HUD, you get fewer tiles. If you use more than 80 sprites (to make it easier to switch between which 80 display at any time), you get fewer tiles. Maybe you make the scroll layers 64x32 to save ram - then you get more tiles. You the programmer control the ram directly on hardware like this, and you need to plan just what you need vs what you have available.

 

 

OK. Thanks for that.