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++ > Getting started - manual compiling with the new devkitarm

#177502 - Bregalad - Thu Jul 12, 2012 11:15 am

I'm sorry if what I'm asking sounds trivial.

I'm trying to get started to GBAdev. Most tutorials for the GBA uses the old devkitgba instead of the new devkitarm.

Supposedly it's roughly equivalent but I have trouble following the tutorials, I'm trying to get started like they describe here.

Of course I replace "gcc" and "objcopy" by "arm-none-eabi-gcc" and "arm-none-eabi-objcopy" respectively.

I get no errors, but the resulting GBA rom refuses to run in an emulator.

This works fine using the devkitpro's template, BUT I don't understand how their incredibly complex makefile works, and I'd like to have the freedom to compile my files as I want (and not as THEY want).
(At a later stage I'd like to have different optimisation settings for different .c files, and chose which files are compiled in ARM or THUMB mode).

Thanks in advance for any help.

#177503 - elhobbs - Thu Jul 12, 2012 1:48 pm

using the default makefiles you can choose between thumb and arm by naming the file as *.arm.c or *.thumb.c - cpp works too.

A lot of the tutorials are really out of date. did you look at the examples that are installed with devkitarm/libgba? If you are just starting then optimizing is probably not super important at this point. get something that will run and then see if it needs to be optimized.

I am not sure who you think "THEY" are? The build system may seem a little complex but it does let beginners get started relatively quickly, without having to figure out how to turn the compiler output into something the system can run. if you are determined to make something on your own then the gba_rules file included at the top of the template makefile (and the base_rules which it includes) contains most of the logic. nothing nefarious. both of these file are in the devkitpro/devkitarm folder.

#177504 - Bregalad - Thu Jul 12, 2012 10:49 pm

Thank you for your answer,

Quote:
using the default makefiles you can choose between thumb and arm by naming the file as *.arm.c or *.thumb.c - cpp works too.

This is good to know.
Quote:

A lot of the tutorials are really out of date. did you look at the examples that are installed with devkitarm/libgba? If you are just starting then optimizing is probably not super important at this point. get something that will run and then see if it needs to be optimized.

You're probably right. In fact I'm not exactly just starting - I've been into GBA romhacking (I don't know if you've heard about FF5/6 Advance sound restoration) - I'm not new to the GBA hardware. What is new is that I'd like to try and compile my own things for the system.

Like I said I already got things working with their templates. However I really feel like I don't know what I'm doing when I'm using their makefiles, it's more like magic to me and I don't like this.

Quote:
The build system may seem a little complex but it does let beginners get started relatively quickly, without having to figure out how to turn the compiler output into something the system can run.

In fact it's exactly what I'd like to figure out !
After you boot the BIOS, how does the GBA know how to jump to your main() function ?

I already coded something for the NDS using devkitpro, and like I said the compilation really feels like magic, and not like something I made myself, which is a bit disturbing.

#177505 - elhobbs - Fri Jul 13, 2012 12:18 am

gba_rules references a spec file which in turn references a link script for memory layout/regions as will an asm file that defines the entry point and setups a minimal c run time. it calls the main function in the sources you provide. the link script is probably the most complicated part and there is no good reason to mess with it - unless it is broken.

the resulting elf file is run through objcopy and converted to binary. then a gbafix utility transforms the resulting bin to a runnable gba file.

#177506 - Dwedit - Fri Jul 13, 2012 12:20 am

The code inside crt0.s boots the game.
It copies sections to the correct locations in memory, and then calls main.

Sections include ".text" (most code, runs from ROM), ".iwram", ".ewram", ".data" (initialized variables put at the end of iwram), ".bss" (zero-filled variables put at the end of iwram), and there's some others too.

The code is found at "C:\devkitPro\devkitARM\arm-none-eabi\lib\gba_crt0.s"

The linkscript (found at "C:\devkitPro\devkitARM\arm-none-eabi\lib\gba_cart.ld") defines what the sections are, and how it glues the binary file together.

Edit: one more thing:
To call ASM code from C, you need to use this:
.global <functionname>
.type <functionname> STT_FUNC
Otherwise it won't generate the interworking code correctly. This is for the newer versions of the GCC toolchain. In older versions, you did not need to use .type xxxx STT_FUNC. So older code may need this fix to build correctly.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."