#1370 - draigan - Fri Jan 17, 2003 8:03 am
I've recently starting programming for the GBA using the DevKitAdvance sdk. I'm curious as to the memory patterns on the GBA. From what I've read, the GBA has 96k VRAM, 32K Fast ram (WRAM?) and 256k of External RAM. That's in addition to the rom.
My question is this: in which memory locations are the following stored:
1) local variables
2) global variables and arrays (for images and tables)
3) executable code
I have a few more questions of course but this is a good beginning. Thanks.
#1374 - ampz - Fri Jan 17, 2003 9:34 am
That's up to you really.
Of course, VRAM is not a good place for code, but I don't think it's impossible to do, if you really want to...
#1378 - Touchstone - Fri Jan 17, 2003 11:17 am
I haven't used DevkitAdvance but I assume that this is how it is:
- Global variables: BSS segment, located in WRAM (Fast RAM as you called it, this is located in the CPU silicon)
- Local variables (local for a function): Stack or registers. Stack is most likely at the end of WRAM.
- Initialized variables and arrays: DATA segment, probably in external RAM but possibly in ROM
- Constant variables and arrays: Definitely ROM
- Executable code: ROM
When you link you can create a mapfile, just pass the -Map thenameofyourmapfile.map to the linker, that way you can look it up in your mapfile where all the symbols end up.
_________________
You can't beat our meat
#1379 - Quirky - Fri Jan 17, 2003 11:51 am
This is my understanding of it...
all non-const variables, certain code that you can define and the "stack" go in IWRAM. Intialised vars and arrays that are non const go here too, plus global variables and local ones. There was a bug I think with earlier releases of DKA where initialised vars were put in ROM, this meant that certain library functions were broken when tested on a Nintendo cart (they work "fine" on the flash advance as you could write to ROM!)
malloc, etc - allocates from EWRAM - 256kb of this - the "heap", because it's big. Apart from explicitly stating the EWRAM section in your code, this is the only way variables go in EWRAM. It isn't too good for commonly used stuff though, because EWRAM is actually slower than ROM under most conditions. This is also where "multiboot" games are stored too. So if you use the multiboot cable for testing games, then you have less ram available to dynamically allocate to your program later.
As mentioned, the only data that goes in ROM is constant data.
#1387 - draigan - Sat Jan 18, 2003 2:05 am
Okay, now another few questions:
I have my app setup in mode5... I want to paint a fullscreen background image (160x128x16bit). Obviously I can't store this in wram since it's too big. Should I store it in rom instead? If the eram is slower than rom, this seems like the best place right?
I'm using the Arm and not Thumb. Would I benefit in speed from using Thumb?
How can I put code into the Wram?
#1393 - draigan - Sat Jan 18, 2003 3:34 am
okay, I realize now how to put code in IWRAM.... what a speed improvement in Arm mode!
My question is... is it okay to store background images in ROM or would I see a speed improvement by moving it to .ewram? I'm asking this because I redraw this background image every frame. People say that ewram is slower than ROM but what if I can read 32-bits at a time from ewram and only 16bits to ROM? WOuld this speed difference still apply?
#1395 - Splam - Sat Jan 18, 2003 4:34 am
It's probably best to leave your background in rom (especially if it won't fit in ram ;) ). I know it was probably just a "what if?" question on your part but I don't see why you would limit yourself to 16bit reads from rom.
btw, just wondering why you draw your background each frame? You blitting other stuff over it or something?
#1397 - tepples - Sat Jan 18, 2003 5:14 am
| draigan wrote: |
| My question is... is it okay to store background images in ROM or would I see a speed improvement by moving it to .ewram? |
If you're repeatedly copying an image to VRAM, I'd advise storing it in ROM, enabling prefetch, and using a 16-bit DMA copy. This will give you the fastest copy. The only reason to store large constant data in EWRAM is if A. it's compressed, or B. you're making a multiboot program.
| Quote: |
| what if I can read 32-bits at a time from ewram |
EWRAM is 16-bit.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1398 - tepples - Sat Jan 18, 2003 5:16 am
| ampz wrote: |
| Of course, VRAM is not a good place for code |
Really? I'd think that if you're not using all of VRAM, it'd be a nice place to stash a couple Thumb subroutines. From my tests, even when the screen is turned on, reading and writing VRAM introduces fewer wait-states than reading and writing EWRAM or even reading ROM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1400 - draigan - Sat Jan 18, 2003 5:50 am
splam said
I know it was probably just a "what if?" question on your part but I don't see why you would limit yourself to 16bit reads from rom.
Well, I thought that ROM was 16-bit and therefore I could not read more than 16-bits at a time or otherwise introduce wait states... ie, it would be just as slow reading 32-bits at a time because it would have to fetch data in 16-bit chunks anyway. Please correct me if I'm wrong here.