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 > Storage in EWRAM

#43081 - LOUD NOISES - Wed May 18, 2005 9:54 pm

I'm trying to store some information in the EWRAM and I'm running into trouble. Whenever I declare a variable stored in EWRAM the compile takes about 5 times as long as normal and produces a 24 MB file. I'm declaring the variable like so

static unsigned char grid[192][256] __attribute__ ((section (".ewram"))) = { 0 };

Any ideas?

#43091 - tepples - Thu May 19, 2005 12:02 am

Try this first:
Leave off the " = { 0 }" at the end of the declaration.

If that doesn't work:
Using the section ".ewram" will cause the compiler to actually copy the array into the binary. If you just want a big zero-filled array, try putting it in a section that the linker script considers zero-filled and destined for the Nintendo DS's 4 MB EWRAM. Try the names ".bss" or ".sbss"; I haven't read the Nintendo DS link script myself, but extrapolating from the GBA link script and what I've read in this section, one of those should work.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#43102 - LOUD NOISES - Thu May 19, 2005 2:43 am

Using the section ".sbss" seems to be working perfectly. Thanks for your help.

#43138 - Mollusk - Thu May 19, 2005 12:46 pm

what exactly is .sbss ?

#43147 - tepples - Thu May 19, 2005 2:53 pm

".bss", or "block storage section", is the name of a memory section used by the linker. Like ".data", it is writable, but unlike ".data", the contents of ".bss" are not stored in the executable; rather, they're zero-filled before the startup code calls main().

".sbss", or "second block storage section", is a term referring to a second zero-filled section on some platforms, similar to ".bss" and usually in a larger, slower area of memory. For instance, on the Game Boy Advance, ".bss" goes in IWRAM (32 KB, 32-bit, 0 wait state), and ".sbss" goes in EWRAM (256 KB, 16-bit, 2 wait states unless overclocked through an officially undocumented register).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#43148 - Mollusk - Thu May 19, 2005 2:58 pm

Ok, thanks a lot ! It's really clear now for me :)

#43168 - LOUD NOISES - Thu May 19, 2005 7:41 pm

It's strange that .bss didn't work for me. Although the program compiled fine (unlike using .ewram), the program results were pretty screwy until I tried .sbss. Here's what I tried (these are all global):

unsigned char grid[192][256];
(compiled fine, but program crashed on the hardware (just two black screens) although it worked for the most part on the iDeaS)

static unsigned char grid[192][256];
static unsigned char grid[192][256] __attribute__ ((section (".bss")))
(both of these resulted in the same problem (below))

static unsigned char grid[192][256] __attribute__ ((section (".ewram")))
(compiled into a 20+ MB file)

static unsigned char grid[192][256] __attribute__ ((section (".sbss")))
(worked correctly)

As for the screwy output... if I filled grid with 50 lines of red, 50 of blue, 50 of green, and 42 with purple, then copied grid into BG_GFX (or sub) with background 3 set to extended rotation background in mode BG_BMP8_256x256, only about half of the image would be displayed.

Toward the middle of screen (after red and blue) the image would get would have bits of black here and there then go completely black. Then toward the botton the image would seem to start over (red and blue again).

I can't get extended backgrounds to show up in ideas, so here's a crappy mspaint example what seems to happen:

http://img212.echo.cx/img212/8469/pic8yv.jpg

After switching to .sbss everything worked fine, but if I could get it into faster memory it would be nice.

#43169 - LOUD NOISES - Thu May 19, 2005 7:44 pm

Oh wait, that's 48 kb. That must explain the problem with IWRAM.