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.

C/C++ > Can't seem to start properly

#48 - XyzZyx - Wed Jan 01, 2003 10:50 pm

I just started programming the Gameboy Advance, but I can't seem to be able to run the ROM images I produce. I'm using gcc from DevKitAdvance and BoyCott/PlayBoy as the emulator. When I try to run the image file, the emulator complaints about an invalid logo and it also shows messages about "Illegal BIOS calls". I opened the debug window and saw that it kept looping the same three or four opcodes over and over. Yes, I did compile it to an object file first, then copied it to a binary file using the program which followed gcc. What am I doing wrong? The emulator doesn't even seem to access the main function of my C program at all. I thought the compiler filled in the nintendo logo and the header stuff, but it obviously didn't. Have I missed something in the compilation process or forgotten to include a file or two? Thanks.

#52 - Dracula-X - Wed Jan 01, 2003 11:34 pm

Look in the gbadev.org website in TOOLS->HEADER TOOLS
and grab one of the many header tools that are there. Integrate one of them into a makefile (or do it manually by hand for now) so that it 'validates' your rom with the logo and crc properly. Most of the tools work just fine, I myself use fugbar+makefile so it validates my stuff automatically when I recompile.

-DX

#58 - Costis - Thu Jan 02, 2003 1:29 am

Hi,

Are you even using any SWI calls? If not, then you are probably running invalid code. Also, most emulators don't require for your GBA programs to have valid headers to run (VBA and Mappy for example).

Costis

#59 - Splam - Thu Jan 02, 2003 1:29 am

Fixing up the header shouldn't really be needed for emulators, only for hardware unless you've done something really wrong. Make sure you've got (and include) CRT0.s and probably romheader.s (not sure what devkit advance uses) as these define the boot code for the rom and include the header (logo, name etc, this is what the header tools will fix up to run on hardware).

#71 - AnthC - Thu Jan 02, 2003 7:07 am

Hi
Are you actually linking the object files into a ROM image?
Just curious - from what you say, it sounds like you're renaming object files to the BIN?
If you are still stuck, then pop into the channel sometime, i'm sure someone will help you.
Anth

#74 - XyzZyx - Thu Jan 02, 2003 7:54 am

No, I didn't just copy the object file to have a .bin extension, I'm using objcopy.exe from the DevKitAdvance. And no, I did not include those .s files, but it sounds as I can use a header-fix tool to do what they would have done? Well, thanks, I'll try it! Actually, the reason I went to this forum was that it was kind of bad response in the channel (but that might also partly be because I live where I do with timezones and stuff).

#76 - Costis - Thu Jan 02, 2003 8:12 am

Hi,

I don't really use GCC as a compiler, but I know that you need to actually link the object files in your project using the linker program, "ld". You shouldn't be converting the .o files into binary files with the "objcopy" program as that will just produce an invalid file. Oh, and you definately need the crt0.s file in your project as well.

Costis

#78 - Splam - Thu Jan 02, 2003 9:28 am

XyzZyx wrote:
No, I didn't just copy the object file to have a .bin extension, I'm using objcopy.exe from the DevKitAdvance. And no, I did not include those .s files, but it sounds as I can use a header-fix tool to do what they would have done? Well, thanks, I'll try it! Actually, the reason I went to this forum was that it was kind of bad response in the channel (but that might also partly be because I live where I do with timezones and stuff).


I think this all depends on your makefile, I'm pretty sure it will include crt0.s as standard unless you use the -nostarfiles switch on the linker (ld) check your makefile for that and if its there then you need to build your own crt0, that then includes the rom_header. You cant use the header tool to save you building crt0 because the header tool would effect the area of the rom where that should be and if it's not included in your build it won't be in the rom.

#79 - XyzZyx - Thu Jan 02, 2003 10:01 am

I don't have, don't know where to obtain and don't know how to use the crt0.s file (any tips would be appreciated). However, I think I am running the linker (the -ld option on gcc.exe).

#83 - imikeyi - Thu Jan 02, 2003 2:31 pm

Maybe an example will help. These are the steps I'd use to compile main.c into a gba rom with gnu tools:

arm-agb-elf-as -o crt0.o crt0.s
arm-agb-elf-gcc -nostartfiles -g crt0.o main.c -T lnkscript -o main.elf
arm-agb-elf-objcopy -O binary main.elf main.gba

crt0.s and the lnkscript are downloadable together from www.devrs.com/gba. You shouldn't have to change the crt0.s file (unless you want to handle interrupts yourself etc).

gcc performs the linking for you. The -nostartfiles stops gcc from using the default crt0.s

The third line strips the elf format stuff from the file, and makes it a plain rom.

Hope this helps :)

#86 - XyzZyx - Thu Jan 02, 2003 3:31 pm

Thanks, I have got the crt0.o and crt0.s files along with lnkscript now. But there's still something wrong; the linker gives errors about undefined references (which I think was defined in the file(s) excluded by the -nostartfiles): The line
C:/GBA/devkitadv/lib/gcc-lib/arm-agb-elf/3.0.2/libgcc.a(__main.o): In function '__do_global_dtors': __main.o(.text+0x74): undefined reference to '__EH_FRAME_BEGIN__'
comes out among others. When I don't include the -nostartfiles option, it pops out errors with "duplicate definitions" of other labels instead.

#108 - imikeyi - Fri Jan 03, 2003 1:03 am

You should post all the error messages.

Also, what code are you trying to compile? Depending on the crt0.s file, you'll probably have to define your entry point function as int AgbMain(void) rather than int main(void).

The -nostartfiles makes gcc not use the default c runtime file (crt.s), so you can specify your own. If you specify your own and don't include -nostartfiles, there will be duplicate definitions etc, resulting in the errors you are getting.

#125 - XyzZyx - Fri Jan 03, 2003 6:59 pm

Yep, the main method was it! Thank you everybody, you've helped a lot :-D