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.

Coding > (GBA)Issues comming from ewram during compile

#70157 - Kaiser - Sat Feb 04, 2006 8:05 pm

I've been working on a test project for the gba, I recently been adding data and more data for sprite display, sounds etc. When adding data, I used two raw data files converted to .o files (first file is 284,405 bytes, the other 119,314 bytes).
In my header (.h) file I have them setup as:
extern unsigned char data_file1[];
extern unsigned char data_file2[];

when trying to compile with these data files I get a ewram overflow error during compile.

here is a screenshot of the command prompt.

[Images not permitted - Click here to view it]

I am assuming that I am compiling too much data into the rom, but how can I get around this limit, and is there any docs that deals specifically with ewram?

I appriciate any feedback. Thanks

#70163 - keldon - Sat Feb 04, 2006 8:24 pm

You need to declare the data as const if you want it stored in ROM and not RAM.

#70169 - Kaiser - Sat Feb 04, 2006 8:55 pm

extern const unsigned char data_file1[];
extern const unsigned char data_file2[];


Error still occurs though. Same message. Is there a limit to the size of my binary files perhaps?


btw, here's a copy of my batch file that I use to compile the rom

Code:

@echo off
REM just add  .c file and  .o file to the next two lines
set CFILES= spriteTest.c
set OFILES= Data_File1.o spriteTest.o Data_File2.o


set GAME= spriteTest
set SPECS=gba_mb.specs

set DEVDIR=E:\devkitPro
set DATADIR=E:\devkitPro\GBATEST\include

PATH=%DEVDIR%\bin;%path%

REM set our paths so the linker knows were to look for the libs
set LIBDIR= %DEVDIR%\arm-elf\lib\interwork
set LIBDIR2= %DEVDIR%\libgba\lib

REM set our include directories so the compiler can find our include files
set INCDIR= %DEVDIR%\arm-elf\include
set INCDIR2= %DATADIR%

REM the compiler and linker flags
set CFLAGS= -I.  -I%INCDIR% -I%INCDIR2% -c -g -O2 -Wall -mcpu=arm7tdmi -mtune=arm7tdmi -fomit-frame-pointer -ffast-math -mthumb -mthumb-interwork

set CFLAGSARM= -I.  -I%INCDIR% -I%INCDIR2% -c -g -O2 -Wall -mcpu=arm7tdmi -mtune=arm7tdmi -fomit-frame-pointer -ffast-math -mthumb-interwork

set LDFLAGS=  -mthumb -mthumb-interwork -specs=%SPECS% -L%LIBDIR% -L%LIBDIR2% 




REM Compile the cfiles
E:\devkitPro\devkitARM\bin\arm-elf-gcc.exe  %CFILES% %CFLAGS%

E:\devkitPro\devkitARM\bin\arm-elf-gcc spriteTest.c  %CFLAGSARM%

REM link the o files
E:\devkitPro\devkitARM\bin\arm-elf-gcc.exe -o %GAME%.elf  %OFILES% %DFILES% %LDFLAGS%

REM gcc produces .elf exicutables...objcopy to .gba
E:\devkitPro\devkitARM\bin\arm-elf-objcopy.exe -v -O binary %game%.elf %game%.gba

E:\devkitPro\devkitARM\bin\gbafix.exe %game%.gba

REM remove all the ofiles
REM del %OFILES%
del %game%.elf

pause

#70177 - nmain - Sat Feb 04, 2006 9:40 pm

Code:

set SPECS=gba_mb.specs


This spec set tells the linker to put all your code in ewram. A short startup routine is then added in before the code runs that copies it all off the ROM and into ewram if it is in ROM.

That is, this spec set is for multiboot roms; they can be run directly in ewram off a cable after being downloaded by the BIOS. So if your program is more than 256K including assets, this won't work. You need to reduce the size of your included assets, or if your intent is not to make a multiboot compatible rom, link with the regular specs instead:

Code:

set SPECS=gba.specs

#70179 - Cearn - Sat Feb 04, 2006 9:43 pm

Kaiser wrote:

Code:
..
set SPECS=gba_mb.specs
...

In this case, everything ROMish will go into EWRAM. I'm not sure how much data you're putting in there exactly (sizeof(.o) != sizeof(binary), but it may be close), but if GCC says EWRAM is full, I guess it's too much. To solve this you can either
a) compile the data so it's smaller.
b) compile to real ROM using 'gba.specs' instead of 'gba_mb.specs'.

EDIT: cross-post. Sigh.

#70182 - Kaiser - Sat Feb 04, 2006 10:01 pm

It finally works heh.

Btw, I am still new to the GBA hardware so I am not aware what multiboot does.

Also I am just wondering, is it possible to actually access data though GBA memory, or the only way is by C arrays?

#70187 - Cearn - Sat Feb 04, 2006 10:18 pm

Kaiser wrote:
Btw, I am still new to the GBA hardware so I am not aware what multiboot does.

there are two modes of operation: cart-boot (or whatever it's called) and multiboot. Cart-boot is with a cartridge, which has a 32MB ROM section, but requires a flashcart for hardware testing. Multiboot is what's used to make 1-cart-multiplayer possible: code/assets are loaded into EWRAM by a multiboot cable, either by another GBA or from a PC using a homemade Xboo cable. It's a lot cheaper solution than buying a flashcard, but you're stuck with only 256kb of memory.

Kaiser wrote:
Also I am just wondering, is it possible to actually access data though GBA memory, or the only way is by C arrays?

Eh?

C arrays are memory, GBA or otherwise. All data and code is in the memory, because that's how computers work.

But in case you're asking if there is any other way of attaching and locating any kind of data, yes there is. Try tepples' GameBoy File System. FYI, locating is not the same as accessing. Access is easy: just make a pointer and point anywhere in memory. Whether you actually find what you were looking for (i.e., locating) is very doubtful.

#70200 - Kaiser - Sun Feb 05, 2006 12:11 am

Cearn wrote:

GameBoy File System. FYI, locating is not the same as accessing. Access is easy: just make a pointer and point anywhere in memory. Whether you actually find what you were looking for (i.e., locating) is very doubtful.


I'll toy around with that and see what I can come up with.

Cearn wrote:

Eh?

C arrays are memory, GBA or otherwise. All data and code is in the memory, because that's how computers work.



hehe, yeah I figured that would be the case
Thanks for the feedback :D