Page 1 of 1

Confused about VRAM nametables (tiletables) sizes

Posted: Wed Apr 30, 2014 11:15 pm
by realbrucest
Hi guys!

I was having a look at Fonzie's "The VDP in 16 Pics" when I noticed about a "supposed" free-to-use 128 tile area I didn't know about:


That discovery made my day... for a while.

I made a quick test ... writing over that area brought no problem at all. Good, good.

And then I did another one ...

I tested the same, writing tiles at "1920 tile position" (VRAM 0xF000) but ...


My background became awfully glitched.

After a while I discovered that that thing was happening when my BPLAN tilemap heigh was exceding of 32 rows. And that made that "supposed to be a free-to-use area" to be filled whith some data belonging to BPLAN nametable.

This is a simplified test using sgdk:


OK with empirical then.

Anyhow, and looking back at Fonzie's VRAM table, I wonder how can it be like that (each plane consuming that amount of data) knowing that H-Scroll and sprite tables would be overwritten if APLAN (at Fonzie's table positioning case) has, for instance, 64 rows drawn.

Yup, I remain a bit confused :oops:

Posted: Thu May 01, 2014 1:08 pm
by Gigasoft
Obviously, Sonic 1 doesn't use 64x64 nametables, so there's no problem.

Posted: Thu May 01, 2014 9:19 pm
by realbrucest
That "VRAM dump" is taken from a demo, it's not an actual game.

My doubts are related with nametables sizes. Looking at that sample ... what happens if plane A is 64x64, will hscroll and sprite tables be overwritten?

I've coded a few demos where I fill both 64x64 planes and there's no problem nor with scroll neither with sprites. Then ... I guess I'm missing some info :-\

Posted: Thu May 01, 2014 9:41 pm
by Mask of Destiny
The VDP memory map is not fixed. It's controlled by a number of VDP registers. A layout that's used by a game that does not need large scroll tables may have conflicts if used for a game that uses larger scroll tables.

Posted: Fri May 02, 2014 8:46 am
by Stef
SGDK use some specific VRAM area for nametables and definitely you cannot compare from what you got in a demo. With the last version of SGDK you can redefine them without breaking internal SGDK methods (was not the case before as i was using constant for nametables address).

Posted: Sat May 03, 2014 10:49 pm
by realbrucest
OK. I'll take that ;)

Thanks guys anyhow.

I know about the posibility of placing VRAM data tables into different memory areas, I just was not sure about how large nametables could be so I though that the most common size I have been finding was "its propper size".

When I started to fill planes with more than 32 rows of tiles my troubles started to show up. Anyhow I know how to bypass my old problems. OK now.

Regarding relocation of nametables (and others) I recommend to have a look at Eternal Champions VRAM state. All tables are placed in the beginning of VRAM so that a continuous and huge chunk of memory are avaible for tiledata.

It's very interesting to look at how many games take advantage of VRAM empty gaps when programmer know exactly where and how big their nametables (and others) are.

Reiterating: thanks guys :)

Posted: Sun May 04, 2014 9:19 am
by Stef
Put nametables at beginning or ending of VRAM does not much different, it's all up about how you optimize the allocation, if you are using big large tilemap (64x64) or smaller ones (64x32). Also if you don't use the window you can totally ignore its nametable.