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 > Converting Goomba Color to compile on GCC

#124616 - Dwedit - Sat Apr 07, 2007 8:23 am

Right now I'm in the process of converting Goomba Color to compile on GCC. I've killed off all the register-relative labels, converted almost all of the ASM syntax, but there's still a long way to go. Gnu Assembler is crashing on me whenever I use a macro, and the code uses macros very heavily. I'm also getting some lovely errors like "Error: symbol definition loop encountered at `_address'"

I'm posting code and asking someone else to help me fix the build errors.

EDIT: Now links to thread: http://www.dwedit.org/dwedit_board/viewtopic.php?pid=1846#p1846
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."


Last edited by Dwedit on Sun Apr 08, 2007 7:04 am; edited 1 time in total

#124618 - keldon - Sat Apr 07, 2007 9:04 am

No end of line in mbclient.c, gbamp_cf.h, gba_nds_fat.c, cache.h, asmcalls.h, ui.h and sram.h (although it has comment).

#124619 - Dwedit - Sat Apr 07, 2007 9:10 am

Right now I'm not concerned with any of the C files, just the asm files.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#124652 - gmiller - Sat Apr 07, 2007 4:46 pm

The _address issue is related to "equates.h" where the symbol is used and redefined but no initial definition. These may be memory offset definitions but I am not sure yet. I am looking at boot.s as a start. The GAS manual at http://sourceware.org/binutils/docs-2.17/as/index.html has always been less that helpful in general. Was this code originally from the "golden rod" ARM assembler?

#124660 - tepples - Sat Apr 07, 2007 5:18 pm

"Golden rod"? Have you been playing Animal Crossing?

The code wasn't written for Goldroad. It was written for ARM SDT.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#124681 - Dwedit - Sat Apr 07, 2007 7:01 pm

Thanks for catching that I forgot to give an initial value to _address. My previous code used a GBLA (global arithmetic) declaration, which is not needed by as, but I never assigned the initial value anyway.
I think that solved the crash problems too.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#124686 - gmiller - Sat Apr 07, 2007 7:32 pm

tepples wrote:
"Golden rod"? Have you been playing Animal Crossing?

The code wasn't written for Goldroad. It was written for ARM SDT.


I forgot it was "Goldroad" , Oh well ... some brain cells do fail some times. Never played animal crossing ...

#124757 - Dwedit - Sun Apr 08, 2007 6:24 am

Status update: I've solved all assembler errors with the ASM code. In order to resolve deficiencies in Gnu assembler (ADR instruction can't cross files), I had to make one ASM file .includes all the other source code.

Still need to figure out the black magic that is makefiles and getting the damn thing to link.

Still need help: I need to modify the CRT files and possibly the linkscript for these features:
* In multiboot mode (booted from cartridge) or cartridge mode, get the address of the last byte in the binary (in rom), and store it to a variable. Also get the address of the last byte of EWRAM.
* In multiboot mode, remove the sections that do not stay in EWRAM. Also make sure there are no holes (all non-ewram content strictly comes after ewram content in the binary)
* In multiboot mode, move the appended content (initially stored after the end of the MB binary) over to what becomes the last byte of EWRAM. This removes the IWRAM content from EWRAM. Also store a pointer to the location the appended data was copied to.

Latest work posted at http://www.dwedit.org/dwedit_board/viewtopic.php?pid=1846#p1846 if anyone cares.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#124877 - gmiller - Mon Apr 09, 2007 2:06 pm

All of your inline assembly is not in GNU form so that will need to change. The symbols with $$ in them will need to change (or course these are ones you need changes for) and a pretty standard Makefile will work with some minor folder layout changes and a few changes to the .s assembly include directives. I have it linking with errors at this point using my standard Makefile layout (based on the standard ones wintermute included in devkitPro) I could give the current way I have it layed out if you want. Of course I commented out the inline assembly rather than convert it to save me time.

#128331 - tepples - Thu May 10, 2007 6:42 pm

Dwedit wrote:
Still need to figure out the black magic that is makefiles

Makefiles in general are not black magic. Wintermute's makefile is black magic intended to make use by beginners easier, but for complex projects, sometimes I find it it easier to scrap the makefile and start from scratch than to work around its limitations (For example, one of my projects uses an archive that depends on multiple LZ-compressed files, which in turn depends on a converted sprite sheet, which in turn depends on the original sprite sheet in .bmp format).

Fortunately, simple makefiles are still simple. They specify what file depends on what file, followed by what command to run to generate the file.
Code:
stuff.o: stuff.c
(tab)arm-eabi-gcc -O -mthumb -mthumb-interwork stuff.c -o stuff.o

Here, (tab) represents an actual tab character, not four or eight spaces.

Quote:
and getting the damn thing to link.

My technique is to start with hello world and make sure everything works after each stage.

Quote:
* In multiboot mode (booted from cartridge) or cartridge mode, get the address of the last byte in the binary (in rom), and store it to a variable. Also get the address of the last byte of EWRAM.

I made GBFS before I learned of this technique:
Code:
extern const u8 _end[];

size_t binarySize = &_end - (const u8 *)0x02000000;


Quote:
* In multiboot mode, remove the sections that do not stay in EWRAM. Also make sure there are no holes (all non-ewram content strictly comes after ewram content in the binary)

The map file generated from TOD shows that in the default crt0/linkscript, everything starting after __iwram_lma gets copied to IWRAM.
Code:
extern const u8 __iwram_lma[];


Quote:
* In multiboot mode, move the appended content (initially stored after the end of the MB binary) over to what becomes the last byte of EWRAM. This removes the IWRAM content from EWRAM. Also store a pointer to the location the appended data was copied to.

Make a version without this feature, and set a debugger to trap on accesses between __iwram_lma and _end to make sure that you aren't overwriting anything.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.