gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > BG Tile Memory clearification *Mystery solved*

#141585 - SaruCoder - Thu Sep 27, 2007 6:09 am

Ok, so this has been bugging me for awhile, and chose to neglect the real meaning behind the tile/map block memory allocation until now.

When I mean by block memory allocation, I mean the values that go into BG_TILE_BASE(n) and BG_MAP_BASE(n) when you setup the BGx_CR. Because it's been trial and error to get my backgrounds showing up properly. I think I've figured it out by thoroughly working out the numbers, but I came across another realization and I can't seem to figure it out.

If I have a 256x256 pixel 256-color bitmap, and turned it into a tile map (32x32 tile blocks), then it would require 540672* bytes (524288 bytes for the tile, 16384 bytes for the map). Now, where in memory is this data stored? Because I'm looking at the virtual video and VRAM tables, and I can't seem to figure out where it all goes, especially when I have the 256x256 pixel bitmaps going on both screens, and with sprites too.

Right, now I declared to use my banks as so (and things do work on hardware and emu) :
Code:
   
vramSetBankA(VRAM_A_MAIN_BG);
vramSetBankB(VRAM_B_MAIN_SPRITE_0x6400000);
vramSetBankC(VRAM_C_SUB_BG);
vramSetBankD(VRAM_D_SUB_SPRITE);


According to the docs I've read so far, Bank A & C only has ?128k? So, where is the rest of it going to?

*this can be further explained if anybody wants to know how I got that number

Last edited by SaruCoder on Fri Sep 28, 2007 3:02 am; edited 1 time in total

#141598 - Dark Knight ez - Thu Sep 27, 2007 10:08 am

I'm completely unaware where you got the 524288 bytes from. I mean, that's 512kb.
When a 256x192 background is used as bitmap, it'll cost you 48kb. If you'd use a 256x256 background used as bitmap, it'll cost you 64kb.
Making it a tiled background instead, the actual tiles (assuming you're not reusing tiles) would take up the SAME amount of space. It's not like they suddenly grow by a factor of 8.
Also, if you're not planning on reusing tiles, is there a particular reason why you want it as a tiled background when it costs even more VRAM this way due to also needing a tilemap?
_________________
AmplituDS website

#141599 - Cydrak - Thu Sep 27, 2007 10:31 am

Hmm, where do you get those numbers? Seems to me, 256*256*8bits/pixel is 64 Kbyte, and 32*32*16bits/tile is 2 Kbyte... Banks A through D are each 128 KB. So your pixels haven't run off, they probably fit in one bank as it is. I'll try to give an example...

But, backing up a bit first... There are three types of BG data, where RAM is concerned:

- Tiles (16 and 256 color). These are set using BG_TILE_BASE(0..15) and it counts in 16 KB steps. A full set of 1024 tiles is 32 or 64 KB.

- Tilemaps. With normal layers, these are divided into 32x32 tile map-blocks, with 16 bits/tile. For affine, they go in reading order (up to 128x128). Either way, you set them with BG_MAP_BASE(0..31), in 2 KB steps (the size of the smallest useful map).

- Bitmaps (256 color and 16 bit RGBA). Your garden variety, linear hunk of pixels. A single screen, 256*256, takes 64 or 128 KB, while the largest (512*512*16bits/pixel) can devour all 512 KB.. Set these up using BG_BMP_BASE(0..15), in steps of 16 KB. This is the only base you want for bitmap layers. They don't use tiles or tilemaps at all.

All the BG_*_BASE() values are relative to the beginning of BG ram (0x6000000 and 0x6200000 for MAIN_BG and SUB_BG respectively--the two cores are completely separate). So let's say you want a single screen 256 color bitmap and a couple 16 color layers on top. A typical setup might be:
Code:

videoSetMode(MODE_3_2D);  // Three normal layers, one bitmap/affine
BG1_CR = BG_PRIORITY(0) | BG_16_COLOR | BG_32x32 | BG_MAP_BASE(28) | BG_TILE_BASE(0);
BG2_CR = BG_PRIORITY(1) | BG_16_COLOR | BG_64x32 | BG_MAP_BASE(30) | BG_TILE_BASE(2);
BG3_CR = BG_PRIORITY(2) | BG_BMP8_256x256 | BG_BMP_BASE(4);

This should give the following ranges:
Code:

               Base         Size    Range
- BG1 tilemap: 28 *  2 KB    2 KB   56 KB - 58 KB
- BG1 tiles:    0 * 16 KB   32 KB    0 KB - 32 KB
- BG2 tilemap: 30 *  2 KB    4 KB   60 KB - 64 KB
- BG2 tiles:    2 * 16 KB   32 KB   32 KB - 64 KB
- BG3 bitmap:   4 * 16 KB   64 KB   64 KB -128 KB

There are also BG_TILE_RAM, BG_MAP_RAM and BG_BMP_RAM macros, as well as *_SUB versions. They match up with BG_*_BASE, except you can cast them to VRAM pointers.

Finally, if you're really cramped, nothing I'm aware of stops you from having the ranges overlap (as they do above). For example, you might steal part of a tileset for a map, or as Dark Knight hints... knowing the screen is 256x192, borrow the last quarter-bitmap for tiles.

#141616 - knight0fdragon - Thu Sep 27, 2007 4:24 pm

this is how I think he got his numbers 256x256x8bpp == 524288, which is in BITS, VRAM A has 1048576 BITS available to it. What he forgot to do was divide by 8 to get the BYTE count, which would be 64k and 128k
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

#141666 - SaruCoder - Fri Sep 28, 2007 3:01 am

Yeah, it seems that I did miscalculate my numbers at the start. My numbers were in bits, silly me. Everything makes sense again, thanks for the reply guys.