#30507 - ScottLininger - Wed Dec 01, 2004 7:12 pm
I have a large array of sprite meta data. I need to put it into EWRAM.
The problem is that when I do, the size of my ROM increases (as pointed out by the FAQ, DevKitAdv pads your binary with literal zeroes.) The array is just scratch space to store my sprite attributes during mode changes and such.
This is the syntax I'm using to post into EWRAM (from the FAQ):
| Code: |
typeSpriteMetaData scratchSpace[128] __attribute__ ((section (".ewram"))); |
Is there some other syntax I can use in DevKitAdv to store this in EWRAM without wasting ROM space?
If not, can anyone speak to how messy it is to move a project from DevKitAdv to DevKitArm? I've avoided doing this specifically to curtail last-minute bugs in my compo entry from a change in platform... But it's possible that those extra few bytes will make it worth it.
Thanks,
Scott
#30511 - sajiimori - Wed Dec 01, 2004 7:23 pm
The .bss section is for uninitialized data (which doesn't affect ROM size), but I bet it would still go in IWRAM. If there isn't a corresponding section for EWRAM, you might have to make one...
Personally, I'd use malloc(). ^_^
#30512 - ScottLininger - Wed Dec 01, 2004 7:31 pm
Yeah, I just tried the .bss section, and it's not going into EWRAM. Thanks for the suggestion, though.
I'm installing DevKitArm... we'll see if anything breaks. ;)
I thought about the malloc() approach... more code but it would certainly work.
-Scott
#30517 - abilyk - Wed Dec 01, 2004 7:58 pm
In general I'd recommend to write a simple EWRAM memory allocator, but that's probably overkill at this point. Are you using EWRAM for anything else? If not, this is a dirty hack, but it'll work. Just declare a pointer to one of your sprite data structures and have it point to the beginning of EWRAM.
| Code: |
typedef struct SpriteMetaData
{
...
}SpriteMetaData;
SpriteMetaData *sprite_meta_data = (SpriteMetaData *)0x02000000; |
If you are using EWRAM elsewhere in your project, you can still use this technique by figuring out where your EWRAM usage ends and using the following address for this pointer.
#30520 - DekuTree64 - Wed Dec 01, 2004 8:14 pm
What I like to do is make a global pointer to the end of EWRAM, and grow it downward like the IWRAM stack. Then you can just grab all your permanent memory chunks at bootup, and then have a nice big scratch pad, useful for various other things.
It could cause problems mixing with malloc though, if malloc's managed area gets initialized before taking all your permanent blocks. Even if you do write your own malloc and initialize it with the space leftover after claiming the permanent blocks, you wouldn't have the scratch pad benefit since it would grow down into the managed area. Then it's basically the same as letting the linker do it (except for the ROM soaking problem)
You can probably relocate the .bss section to EWRAM in your link script, but then you might get some problems with uninitialized globals that were previously in IWRAM getting mvoed into EWRAM. As far as I know, you can't have 2 .bss-like sections, so I'd say go with the stack approach since it sounds like you're not using malloc at all
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#30529 - ScottLininger - Wed Dec 01, 2004 8:54 pm
| abilyk wrote: |
| In general I'd recommend to write a simple EWRAM memory allocator, but that's probably overkill at this point. Are you using EWRAM for anything else? If not, this is a dirty hack, but it'll work. |
Awesome. Thanks, everyone. I used abilyk's "dirty hack" and it's good enough for now.
-Scott
#30537 - tepples - Wed Dec 01, 2004 10:38 pm
| ScottLininger wrote: |
Yeah, I just tried the .bss section, and it's not going into EWRAM. Thanks for the suggestion, though.
I'm installing DevKitArm... we'll see if anything breaks. ;) |
In devkitARM, the .sbss is like .bss but goes to EWRAM instead of IWRAM. Use it.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.