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 > EWRAM + Overlaps errors

#126412 - outphase - Mon Apr 23, 2007 1:43 am

I tried compiling a program I have been working on for almost a semester, but when I added a few more files and data, I get the following errors at compile. All source files compile just fine but the elf throws up. I don't know where to go to fix the problem. Any thoughts?


Code:
...
linking rc.arm9.elf
/usr/local/devkitPro/devkitARM/lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: region ewram is full (/home/tien/projects/ee464/rc/arm9/rc.arm9.elf section .rodata)
/usr/local/devkitPro/devkitARM/lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: section .ARM.extab [02000000 -> 020001af] overlaps section .init [02000000 -> 0200023b]
/usr/local/devkitPro/devkitARM/lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: section .text [02000240 -> 020198d7] overlaps section .ARM.exidx [020001b0 -> 02000617]
/usr/local/devkitPro/devkitARM/lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: section .init_array [02000618 -> 02000637] overlaps section .text [02000240 -> 020198d7]
/usr/local/devkitPro/devkitARM/lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: /home/tien/projects/ee464/rc/arm9/rc.arm9.elf: section .init lma 0x2000000 overlaps previous sections
/usr/local/devkitPro/devkitARM/lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: /home/tien/projects/ee464/rc/arm9/rc.arm9.elf: section .ARM.exidx lma 0x20001b0 overlaps previous sections
/usr/local/devkitPro/devkitARM/lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: /home/tien/projects/ee464/rc/arm9/rc.arm9.elf: section .text lma 0x2000240 overlaps previous sections
collect2: ld returned 1 exit status
make[2]: *** [/home/tien/projects/ee464/rc/arm9/rc.arm9.elf] Error 1
make[1]: *** [build] Error 2
make[1]: Leaving directory `/home/tien/projects/ee464/rc/arm9'
make: *** [arm9/rc.elf] Error 2

#126413 - tepples - Mon Apr 23, 2007 2:02 am

"region ewram is full" means that your program is getting ready to surpass 256 KiB (on GBA) or 4 MiB (on DS). This means you have to start loading assets at runtime using libfat.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#158863 - gauauu - Thu Jun 19, 2008 7:35 pm

Bringing this back from the dead -- let me see if I understand this all correctly:

-so on the GBA, when I had huge chunks of data declared as const, they were kept on the cart rom (And had up to 32 meg available). By default other variables were put in iwram, unless you particularly specified that they'd go into ewram. Right?

-on DS, all your variables, const or not, end up in the same place, which has 4 meg available. The only way to have more storage available is dynamically loading stuff in at runtime?

#158865 - silent_code - Thu Jun 19, 2008 7:56 pm

Just like that. On the GBA, programs ran directly off the game cart (that's why the cartridges are {?} word aligned), but on the NDS, you have to load everything into main RAM (or other special RAM). I guess, they wanted to make the NDS cartridges cheaper (in production), so they designed it to be a block device.
After an NDS "executable" has loaded, all the global variables, data (in said variables) and instructions are present (minus overlays, if any are present in your program) in main RAM.
To load anything else, you have to take it off a file system.
Alternatively, if a person likes to restrict themselves violently, you can link all data into the executable, but that's nonsense for anything but simple and small games. At least I can't think of any game that had a reasonable content size and didn't use a file system - there might be one, though. Just think about 64k demos. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

#158868 - gauauu - Thu Jun 19, 2008 9:11 pm

silent_code wrote:
Alternatively, if a person likes to restrict themselves violently, you can link all data into the executable, but that's nonsense for anything but simple and small games. At least I can't think of any game that had a reasonable content size and didn't use a file system - there might be one, though. Just think about 64k demos. ;^)


Hehehe...well, I'm to port my game from gba as directly as possible, so I may do just that. On the gba, it linked everything in, so it'll be easier to just keep it that way if I can manage. Since the gba rom slid in at only a meg and a half, I'm guessing it won't bloat up to too big for the DS.

#159071 - HyperHacker - Wed Jun 25, 2008 3:18 am

silent_code wrote:
Alternatively, if a person likes to restrict themselves violently, you can link all data into the executable, but that's nonsense for anything but simple and small games. At least I can't think of any game that had a reasonable content size and didn't use a file system - there might be one, though. Just think about 64k demos. ;^)
Not even NES and SNES games? Super Mario World was a single 512K binary with all data linked in.
_________________
I'm a PSP hacker now, but I still <3 DS.

#159078 - tepples - Wed Jun 25, 2008 3:48 am

But do most hobbyists understand such compression, especially of level data?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#159082 - M3d10n - Wed Jun 25, 2008 4:37 am

silent_code wrote:
At least I can't think of any game that had a reasonable content size and didn't use a file system - there might be one, though. Just think about 64k demos. ;^)


I think most 16-bit didn't use any kind of filesystem. And having actual filenames stored on the card might've been a waste of valuable space on 8-bit consoles.

#159093 - silent_code - Wed Jun 25, 2008 11:21 am

I was (obviously ;^p ) talking about NDS HB games. ;^) ... and then adding something (obviously) unrelated. :^D Sorry for the confusion.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

#159096 - tepples - Wed Jun 25, 2008 12:55 pm

M3d10n wrote:
I think most 16-bit didn't use any kind of filesystem.

IBM PC? Macintosh?

Quote:
And having actual filenames stored on the card might've been a waste of valuable space on 8-bit consoles.

Commodore 64? Famicom Disk System?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#159121 - M3d10n - Wed Jun 25, 2008 9:07 pm

tepples wrote:
M3d10n wrote:
I think most 16-bit didn't use any kind of filesystem.

IBM PC? Macintosh?

Quote:
And having actual filenames stored on the card might've been a waste of valuable space on 8-bit consoles.

Commodore 64? Famicom Disk System?


Geez, you're relentless, aren't you? Ok 16-bit and 8-bit consoles using memory mapped ROM for storage. Maybe NeoGeo games...

Anyway, on the DS you need to handle files like you'd do on a CD-based console if you want your game to have more data than you can fit on the RAM. If it's just a small demo, I see no problem in directly linking data.