#1878 - loopy - Fri Jan 24, 2003 10:54 pm
I understand that the GBA's RAM is broken into two parts: CPU External Work RAM and CPU Internal Work RAM. My question is, if I am using devkit advance, into which parts of RAM are my resources going? Does the compiler already know what to do and where to put things? And if not, how do I chose where I want my resources allocated?
#1881 - NEiM0D - Fri Jan 24, 2003 11:43 pm
To define where your res is going :
<asm>
.section .iwram
.section .ewram
There's something similar in C, but with __attribute__ (( )).
I don't know what the default section is, but my guess is iwram.
#1885 - Touchstone - Fri Jan 24, 2003 11:56 pm
The old indian-trick is the generate a .map file when linking your exe, in that map file you can see where all your labels end up.
Add the '-Map nameofmapfile.map' option when linking and you're set.
With absolutely no experience of devkitadvance I'd guess your code and constant ends up in ROM (yeah!) and local and global variables in IWRAM.
_________________
You can't beat our meat
#1889 - tepples - Sat Jan 25, 2003 2:35 am
By default, everything declared 'const' gets placed in ROM, and everything else is placed in IWRAM.
Don't try using __attribute__ to put things in EWRAM; it'll bloat your binary with 0's. Instead, write static or dynamic allocators.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1897 - loopy - Sat Jan 25, 2003 4:38 am
Forgive me for asking, but how does one write an allocator for external RAM?
#1901 - tepples - Sat Jan 25, 2003 6:20 am
| loopy wrote: |
| Forgive me for asking, but how does one write an allocator for external RAM? |
Static allocation within C looks like this:
| Code: |
struct EWRAM_GLOBALS
{
struct Player foo;
int bar;
/* stick lots more variables here */
};
#define EW (*(struct EWRAM_GLOBALS *)0x02000000)
|
Then access variables in EWRAM with EW.foo, EW.bar, etc. If you're making a multiboot program, you will have to change EW so that it definitely comes after the end of your program. I tend to use 0x02030000, which gives me 192 KB for program and constant data and 64 KB for work RAM, and I use most of work RAM as a temporary area for decompressing data.
Here are examples of dynamic allocators: http://www.cs.colorado.edu/~zorn/Malloc.html
There's one built into Newlib (malloc() and free() from devkit advance's C library), but static allocation will step on its data structures, causing a hard crash if you use them together. You can fix this by moving the beginning of the EWRAM heap in the link script, but editing link scripts is a pretty advanced topic.
Just don't use garbage collection. It's overkill for an embedded system like the GBA. In fact, you can probably get away with an allocator that works with fixed size blocks of 1024 bytes or so.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1905 - loopy - Sat Jan 25, 2003 10:20 am
Thanks- that's really simple! I guess I could have figured it out had I not forgotten that all of the memory is accessible through simple pointers. Duh!
I probably won't be using library routines like malloc() on the GBA, especially not if I'm using static allocation already. But just in case I have to I've already messed with the link scripts in order to get a larger interrupt stack.
#2046 - MrMr[iCE] - Tue Jan 28, 2003 6:07 am
Thanks for the tip, that helped drop over 20k off the game im working on..very cool stuff.
_________________
Does the corpse have a familiar face?