#98902 - Outlaw - Fri Aug 18, 2006 11:18 am
Hi folks,
while searching for an small and nice to handle c compiler I have found the TinyC Compiler. This compiler is damn small and fast and compiles for Linux and Win32 - http://fabrice.bellard.free.fr/tcc/
In the documentation I found the hint that there is a project called tcc-arm which targets the ARM processors.
Does anybody have an idea where i can get it and if it is useful in the GBA development ?
Greetz
Outlaw
www.yakuza.de.be
#98999 - Sausage Boy - Fri Aug 18, 2006 11:57 pm
Do you mean actually running the compiler on the GBA? I doubt the GBA would handle that, though I havn't checked TinyC's requirements yet. Would be awesome to have a programming environment for the DS though. :P
Edit: Hmm, seems like it produces x86 code only, as far as I can see.
_________________
"no offense, but this is the gayest game ever"
#99067 - Outlaw - Sat Aug 19, 2006 12:57 pm
Hi,
in the introduction chapter of the online-documentation there is an Arm support mentioned ..
http://fabrice.bellard.free.fr/tcc/tcc-doc.html#SEC1
I'm not sure whether it runs in windows or linux and just creates ARM binaries or runs itself on ARM processors ..
So long
Outlaw
www.yakuza.de.be
#99224 - kashiwa - Sun Aug 20, 2006 4:13 am
edit configure file:
- build_cross="no"
+ build_cross="yes"
then you can build arm-tcc cross compiler with gcc. (I tested with gcc 3.4.2 mingw special)
I thought that there is no linker or loader for arm-tcc, you must use gcc (also devkitARM) to link object files.
#99337 - Sausage Boy - Sun Aug 20, 2006 8:01 pm
I think it's included in arm-tcc:
| Quote: |
| SMALL! You can compile and execute C code everywhere, for example on rescue disks (about 100KB for x86 TCC executable, including C preprocessor, C compiler, assembler and linker). |
Were you able to compile anything? I get errors about missing crt's.
_________________
"no offense, but this is the gayest game ever"
#99568 - kashiwa - Tue Aug 22, 2006 1:41 pm
I tested only compile... that code.
| Code: |
int main(void) {
printf("hello world!\n");
}
|
arm-tcc -c hello.c -o hello.o
arm-elf-objdump -D hello.o
it returns that
| Code: |
Disassembly of section .text:
00000000 <main>:
0: e1a0c00d mov ip, sp
4: e92d5800 stmdb sp!, {fp, ip, lr}
8: e1a0b00d mov fp, sp
c: e1a00000 nop (mov r0,r0)
10: e59f0000 ldr r0, [pc, #0] ; 18 <main+0x18>
14: ea000000 b 1c <main+0x1c>
18: 00000000 andeq r0, r0, r0
1c: ebfffffe bl 1c <main+0x1c>
20: e3a00000 mov r0, #0 ; 0x0
24: e1a00000 nop (mov r0,r0)
28: e89ba800 ldmia fp, {fp, sp, pc}
Disassembly of section .data:
00000000 <L.0>:
0: 6c6c6568 cfstr64vs mvdx6, [ip], #-416
4: 6f77206f swivs 0x0077206f
8: 21646c72 cmncs r4, r2, ror ip
...
|
I have been satisfied seeing the elf format obj generated.
#99572 - chishm - Tue Aug 22, 2006 2:18 pm
That is some ugly, ugly code. Data placed in the middle of executable sections and multiple unneeded nops make me think that compilers that do an add and subtract immediately after each other on the same register with constant data are doing a good job.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#99614 - sajiimori - Tue Aug 22, 2006 6:33 pm
Be sure to test something other than main() because many compilers insert extra unconditional code (that is not subject to optimization) inside that function, so it often looks really bad.
Of course, I'm not claiming that TCC will do any better -- maybe it's always that bad! ;)
#99690 - Outlaw - Wed Aug 23, 2006 10:08 am
Hi folks,
I'm a little bit confused .. did you find the arm-tcc package and could you use it ?
Btw. its easier to find a small C cross compiler for old homecomputers like ATARI800 than for the GBA. Sure, there is the almighty GCC for all platforms - but its not my way. If I had BeOS I could cross compile with ARM-LCC - isn't that funny :-)
I hope the tcc-arm project will help .. till than i write some stuff for 6502 processors with my neat cc65 Cross Compiler :-)
So long
Outlaw
www.yakuza.de.be
#99734 - sajiimori - Wed Aug 23, 2006 5:25 pm
LCC works on Win32.
#99831 - kashiwa - Thu Aug 24, 2006 4:33 am
I tried to build my old project with TCC according to the advice of sajimori.
Here is the bins and srcs. (including TCC 0.9.23 binary)
http://www.liarsoft.org/data/La_tcc.zip
I found some tips about arm-tcc.
1. TCC supports gas-like inline assembly (wow!), but ARM assembly seems to be not yet. I got error.
2. supports __attribute__((section)) but long_call isn't too.
3. The constants arranged by section ".data". To place in ROM, I wrote __attribute__((section (".rodata"))) instead of const.
4. signed char (not char) gets 0-255...
5. There is no crt0/ldscripts suitable for ARM, I used DevkitARM's.
#99855 - Outlaw - Thu Aug 24, 2006 9:48 am
Hi,
| sajiimori wrote: |
| LCC works on Win32. |
it's right - there is a LCC-version called LCC32 which targets Win32 and runs on Win32 Systems. http://www.cs.virginia.edu/~lcc-win32/
LCC itself is a multiplatform C Compiler which runs on a variety of hosts, but I don't now any project which uses LCC as CrossCompiler that runs in Win32 and targets ARM
http://www.cs.princeton.edu/software/lcc/
As I mentioned, for BeOS there is an ARM-LCC version
http://www.bebits.com/app/1501
@kashiwa: sounds great .. I'll give it a try.
So long
Outlaw
www.yakuza.de.be
#99867 - kashiwa - Thu Aug 24, 2006 12:25 pm
tell me why you don't click 'home page' button on that page. OTL
#99872 - Outlaw - Thu Aug 24, 2006 1:42 pm
Hi,
| kashiwa wrote: |
tell me why you don't click 'home page' button on that page. OTL |
???
#99909 - sajiimori - Thu Aug 24, 2006 6:52 pm
Outlaw, LCC is open source. If you can't find a binary that runs on Win32 and targets ARM, you can build one.
#99941 - tepples - Thu Aug 24, 2006 9:07 pm
| sajiimori wrote: |
| Outlaw, LCC is open source. If you can't find a binary that runs on Win32 and targets ARM, you can build one. |
LCC is not open source; its license has a "non-commercial" clause. If you have advertisements on a site from which you distribute LCC or programs linked with LCC's libraries, that might be considered selling LCC. If you resell a memory card containing LCC or programs linked with LCC's libraries, that might be considered selling LCC.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#99963 - sajiimori - Thu Aug 24, 2006 10:49 pm
By "open source," I mean the source code is available. I understand there are other meanings of the term, but I find them muddled as a result of propaganda from Richard Stallman and others.
http://www.cs.princeton.edu/software/lcc/cgi-bin/ls.cgi?dir=../3.6&title=lcc%203.6%20source%20code
#100001 - Outlaw - Fri Aug 25, 2006 9:18 am
Hi,
| sajiimori wrote: |
| Outlaw, LCC is open source. If you can't find a binary that runs on Win32 and targets ARM, you can build one. |
you're right .. but I never handled pojects like building Compilers or other big tasks; I have absolutely no idea what to take care of .. my prefered programming language was always assembly language - no IDE's, no make-files, no "projects" .. simply, clean software stuff ..
If someone like kashiwa has experiences how to manage, it would be nice if that people do that for the community ;-)
Btw. I installed the HAMDevKit .. is there any way how to shrink the executables ? I guess that 130 kb (!) for a small memory-register-test without using special libs is just to big ..
So long
Outlaw
www.yakuza.de.be
#100029 - sajiimori - Fri Aug 25, 2006 4:54 pm
Well if you avoid anything you've never done, how will you learn new things? ;)
#100350 - Outlaw - Sun Aug 27, 2006 2:33 pm
Hi guys,
so, after playing around for a while with HAM first I was disappointed about the great binary size.
But I found a way that is suitable to get minimized binarys:
just let HAM or GCC do the compilation. Take the assembly file and let it GoldRoad - the great GBA Assembler - compile.
The result: from a 32kb binary created by HAM (with everything stripped out) I got a running binary through GoldRoad with 56 Bytes ! Great job !
Of course this way is only acceptable (and only works ?!) with single-File projects without using any Libs brought to you by HAM or other people.
But my intention is to create some nifty demos/intros and I felt no longer like coding in assembly (just see the source of my simple Firecube) - its a torture to care about simple things like variables or structures ... that's why my interest for the smart TinyC compiler - all I needed was just a "assembly like" higher language. The rest especially adressing the registers, writing algorithms I'll do old-school like myself.
I'll tell you how far the GoldRoad Trick will work with my next project ..
So long
Outlaw
www.yakuza.de.be
#100363 - sajiimori - Sun Aug 27, 2006 3:54 pm
HAM is not a compiler.
The thing to realize is that the gcc command is a front-end for cpp (the preprocessor), cc1 (the compiler), as (the assembler), and ld (the linker).
You have as much control as you take over your projects. If you don't want to link in certain libraries, don't.
#100511 - Outlaw - Mon Aug 28, 2006 11:30 am
Hi,
| sajiimori wrote: |
HAM is not a compiler.
The thing to realize is that the gcc command is a front-end for cpp (the preprocessor), cc1 (the compiler), as (the assembler), and ld (the linker).
You have as much control as you take over your projects. If you don't want to link in certain libraries, don't. |
You're right, no question and I realized it ;)
If you can, show me a binary created by all that "GCC" stuff that is shorter than - lets say - 10 kb (unpacked) .. I guess as experienced with other Compilers / Linkers that this won't work. The only Compiler I know for example in Win32 is LCC32 that can handle this job .. I don't have any idea why this seems to be a hard task for Compilers to strip - everything - that isn't needed ..
So long
Outlaw
www.yakuza.de.be
#100512 - gmiller - Mon Aug 28, 2006 11:42 am
Just remember that compilers by default do not do full optimization so you need to turn on their optimizations with command line options. Their are also command line options for the link phase to optimize the output. Not that these steps automaticly do a great job but without them you optimization efforts require more work. You can tell the gcc compiler to keep all of it's work files so you can see all of the generated assembly. Looking at these files can help you do a better job at the C/C++ coding if you know ARM assembly. Every compiler has a different level of paranoia so the generated code from your source will reflex that. Pointer aliasing, type limiting, loop type and register optimization can impact the generated code.
#100523 - Outlaw - Mon Aug 28, 2006 12:55 pm
Hi,
| gmiller wrote: |
| Just remember that compilers by default do not do full optimization so you need to turn on their optimizations with command line options. Their are also command line options for the link phase to optimize the output. Not that these steps automaticly do a great job but without them you optimization efforts require more work. You can tell the gcc compiler to keep all of it's work files so you can see all of the generated assembly. Looking at these files can help you do a better job at the C/C++ coding if you know ARM assembly. |
I know - and I tried all official command line parameters that were given by --help. And as I mentioned before I took the generated asm file and passed it through GoldRoad-Assembler which created the expected small binary (there where only 20 lines of asm intructions). But "GCC" (or ld) created 39kb .. sure, "GCC" isn't the only DevKit that works that way; in earlier times Borland C or WatCom C (but not Turbo C!) or the pascal compilers created comparable big size binaries. I have no experiences in Linker/compiler creation so I can only guess its just the price for flexibility ..
| gmiller wrote: |
| Every compiler has a different level of paranoia so the generated code from your source will reflex that. Pointer aliasing, type limiting, loop type and register optimization can impact the generated code. |
I don't think so .. my mentioned example demonstrates that this can't be the reason .. the generated assembly-file just took 20 Lines of ARM instructions; the .c-source was around 6 lines. Goldroad just linked it to 56 bytes, ld to 39 kb ... the overhead is mysterious ..
Btw - to pass the .S-Files to goldroad some steps are to go which I'll describe later in a short tutorial ..
So long
Outlaw
www.yakuza.de.be
#100551 - sajiimori - Mon Aug 28, 2006 5:36 pm
Once again, Outlaw, you have as much control as you're willing to take.
| Code: |
C> echo void f() {} > test.c
C> gcc -c test.c
C> objdump -d test.o
test.o: file format pe-i386
Disassembly of section .text:
00000000 <_f>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 5d pop %ebp
4: c3 ret
5: 90 nop
6: 90 nop
7: 90 nop
8: 90 nop
9: 90 nop
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
C> objcopy -I pe-i386 -O binary test.o test.bin
C> dir test.bin
Volume in drive C has no label.
Volume Serial Number is 788D-C32A
Directory of C:\DOCUME~1\saji\Desktop\test
08/28/2006 09:35 AM 16 test.bin
1 File(s) 16 bytes
0 Dir(s) 20,024,975,360 bytes free
|
Note that the padding is to keep object files aligned to 16 bytes, which is important on x86.
#100552 - sajiimori - Mon Aug 28, 2006 5:39 pm
BTW, with -fomit-frame-pointer, the output is 'ret' plus padding.
#100555 - wintermute - Mon Aug 28, 2006 6:26 pm
| Outlaw wrote: |
I don't think so .. my mentioned example demonstrates that this can't be the reason .. the generated assembly-file just took 20 Lines of ARM instructions; the .c-source was around 6 lines. Goldroad just linked it to 56 bytes, ld to 39 kb ... the overhead is mysterious ..
|
There's something seriously wrong with your build process somewhere. If Goldroad can create a 56byte binary with the same code then so can gcc.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#100570 - gmiller - Mon Aug 28, 2006 8:16 pm
I agree with wintermute ... what is the command line to gcc ?
#100578 - Flood_of_SYNs - Mon Aug 28, 2006 8:40 pm
http://linuxreviews.org/man/gcc/
http://gcc.gnu.org/
http://gcc.gnu.org/wiki
_________________
Blue NDS v4 (FlashMe v7) - GBAMP V2 CF
?There is no shame in not knowing; the shame lies in not finding out.?
?The church is near but the road is icy, the bar is far away but I will walk carefully?
#100591 - tepples - Mon Aug 28, 2006 9:46 pm
| Outlaw wrote: |
| If you can, show me a binary created by all that "GCC" stuff that is shorter than - lets say - 10 kb (unpacked) |
AXE, from my DS page. In fact, that's two programs: one for ARM7 and one for ARM9, concatenated into one .nds file.
When linking on MinGW (GCC for Windows), if you use the -s switch, hello world will be a lot smaller. The following C one-liner from someone's board signature that generates a Sierpinski triangle compiles to a 5,632 byte file on my MinGW installation:
| Code: |
E:\develop>type cr.c
main(c,r) {for(r=32;r;)printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
E:\develop>gcc cr.c -s -o cr.exe
cr.c:1:75: warning: no newline at end of file
E:\develop>dir cr.exe
Volume in drive E is DEDODEDO
Volume Serial Number is 09D6-3A1F
Directory of E:\develop
08/28/2006 04:49p 5,632 cr.exe
1 File(s) 5,632 bytes
0 Dir(s) 5,566,922,752 bytes free
E:\develop> |
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#100595 - gmiller - Mon Aug 28, 2006 9:59 pm
Of course that command line uses no optimization at all adding -O2 or -O3 would be better plus a few more. But it depends on the goal .. you can optimize for space or speed and generally not for both but each compiler is different. gcc is not the best, nor the worst. It compiles for LOTS of platforms but is not really targeted for a specific one. The lexial analyizer and other code stuff is generic the code generation and optimizations are targeted at particular platforms.
#100625 - sajiimori - Tue Aug 29, 2006 12:09 am
Also, most of those 5,632 bytes for the one-liner are overhead from the .exe format. On my system, the raw binary compiles down to 119 bytes (which is padded to 128).
#100629 - Flood_of_SYNs - Tue Aug 29, 2006 12:28 am
Mainly for X86 Linux ELF binaries.
http://muppetlabs.com/~breadbox/software/tiny/teensy.html
_________________
Blue NDS v4 (FlashMe v7) - GBAMP V2 CF
?There is no shame in not knowing; the shame lies in not finding out.?
?The church is near but the road is icy, the bar is far away but I will walk carefully?
#100750 - Outlaw - Wed Aug 30, 2006 8:37 am
Hi folks,
okay .. you're right. It's almost a question of passing the right commandline options to the different stages of the compiling process.
After seaching for a short time I found the "real" C Parser CC1.exe somewhere hidden in lib-gcc directory of the HAM distribution.
It does a great job of optimisation of the code !
I checked the .asm-source with and without the -Os parameter.
Without optimisation it creates the same (ugly) code as TinyC Compiler does. But with that parameter - you can't do better when coding in assembly language ! Especially the usage of the conditional postfixes for all ARM instructions reduces size of the source.
But I didnt get into the linking process. Using the ld for the linking process (after as ;) didnt create a running GBA binary . Perhaps someone could show me the commandline options for that task.
(Btw. If some of you think, stripping the binary with objcopy and telling its only 110 Bytes would solve the problem or show, that ld can produce binarys smaller than 1kb .. guys, I didn't want the smallest "binary" itself, I wanted the smallest RUNNING binary .. the stripped out objectcode won't run 'cause there is no entry point defined (it's only needless when only having the main() function) ! GBA binarys start with a branch instruction (followed by the GBA-Header), that you won't find inside the created objcode)
So long
Outlaw
www.yakuza.de.be
#100796 - sajiimori - Wed Aug 30, 2006 5:07 pm
But Outlaw, you can run any code you want on a system without an OS. The hardware begins execution at some address -- you can drop whatever opcodes you want there and it'll be executed, entry points be damned! :)
The GBA doesn't know or care what you named your functions. The idea of "main" as an entry point is only mandated by the startup code that's linked in by default (typically called "crt0") which jumps to main at the end. Crt0 contains the actual code that's placed at the hard-coded address where the hardware begins execution.
But these are just conventions. Since you want to do away with all this silly "crt0" stuff, you're free to drop in any raw opcodes you please... including stripped object files.
Edit: This is all notwithstanding hardware copy protection or signing mechanisms.
#100883 - Outlaw - Thu Aug 31, 2006 10:45 am
Hi,
| sajiimori wrote: |
But Outlaw, you can run any code you want on a system without an OS. The hardware begins execution at some address -- you can drop whatever opcodes you want there and it'll be executed, entry points be damned! :) ..
|
That is not an answer/statement to my post.
I said - if you just strip the objcode you won't get a running binary.
See that example:
first the simple C source (just for testing purpose, doesnt make any sense ;-)
| Code: |
unsigned long testvar[100];
void test()
{
int t,t1;
*(unsigned long*)(unsigned long)0x06000000=(unsigned long)0;
testvar[10]=20;
t=testvar[10];
t1=28475;
if (t>t1) { t=t1+t*3; } else { t1=t*3;test(); }
}
int main(void)
{
*(unsigned long*)(unsigned long)0x06000000=(unsigned long)0;
test();
while(1)
{ }
}
|
Now the generated objcode - disassembled with objdump
| Code: |
test.obj: file format elf32-littlearm
Disassembly of section .text:
00000000 <test>:
0: mov r2, #0 ; 0x0
4: mov r3, #100663296 ; 0x6000000
8: str r2, [r3]
c: ldr r3, [pc, #8] ; 1c <test+0x1c>
10: mov r2, #20 ; 0x14
14: str r2, [r3, #40]
18: b 0 <test>
1c: andeq r0, r0, r0
00000020 <main>:
20: mov r12, sp
24: mov r2, #0 ; 0x0
28: mov r3, #100663296 ; 0x6000000
2c: stmdb sp!, {r11, r12, lr, pc}
30: sub r11, r12, #4 ; 0x4
34: str r2, [r3]
38: bl 0 <test>
3c: b 3c <main+0x1c>
Disassembly of section .data:
|
Now you see what I mean - branch addresses must be fixed to start - 0x0800000. But most important - if you run that objcode it starts in first line (with mov r2,#0), cause you have no "entry point".
The "entry point" has to be created by a branch instruction in the first line - and thats the Structure of GBA Roms 'cause after that you must have a ROM-Header.
So long
Outlaw
www.yakuza.de.be
#100907 - sajiimori - Thu Aug 31, 2006 5:29 pm
| Code: |
unsigned long testvar[100];
void test();
int main(void)
{
*(unsigned long*)(unsigned long)0x06000000=(unsigned long)0;
test();
while(1)
{ }
}
void test()
{
int t,t1;
*(unsigned long*)(unsigned long)0x06000000=(unsigned long)0;
testvar[10]=20;
t=testvar[10];
t1=28475;
if (t>t1) { t=t1+t*3; } else { t1=t*3;test(); }
} |
| Code: |
C> gcc -c test.c
C> objcopy --change-addresses 0x08000000 test.o test_adjusted.o
C> objdump -d test_adjusted.o
test_adjusted.o: file format pe-i386
Disassembly of section .text:
08000000 <_main>:
8000000: 55 push %ebp
8000001: 89 e5 mov %esp,%ebp
8000003: 83 ec 08 sub $0x8,%esp
8000006: 83 e4 f0 and $0xfffffff0,%esp
8000009: b8 00 00 00 00 mov $0x0,%eax
800000e: 83 c0 0f add $0xf,%eax
8000011: 83 c0 0f add $0xf,%eax
8000014: c1 e8 04 shr $0x4,%eax
8000017: c1 e0 04 shl $0x4,%eax
800001a: 89 45 fc mov %eax,0xfffffffc(%ebp)
800001d: 8b 45 fc mov 0xfffffffc(%ebp),%eax
8000020: e8 00 00 00 00 call 8000025 <_main+0x25>
8000025: e8 00 00 00 00 call 800002a <_main+0x2a>
800002a: c7 05 00 00 00 06 00 movl $0x0,0x6000000
8000031: 00 00 00
8000034: e8 02 00 00 00 call 800003b <_test>
8000039: eb fe jmp 8000039 <_main+0x39>
0800003b <_test>:
800003b: 55 push %ebp
800003c: 89 e5 mov %esp,%ebp
800003e: 83 ec 08 sub $0x8,%esp
8000041: c7 05 00 00 00 06 00 movl $0x0,0x6000000
8000048: 00 00 00
800004b: c7 05 28 00 00 00 14 movl $0x14,0x28
8000052: 00 00 00
8000055: a1 28 00 00 00 mov 0x28,%eax
800005a: 89 45 fc mov %eax,0xfffffffc(%ebp)
800005d: c7 45 f8 3b 6f 00 00 movl $0x6f3b,0xfffffff8(%ebp)
8000064: 8b 45 fc mov 0xfffffffc(%ebp),%eax
8000067: 3b 45 f8 cmp 0xfffffff8(%ebp),%eax
800006a: 7e 13 jle 800007f <_test+0x44>
800006c: 8b 45 fc mov 0xfffffffc(%ebp),%eax
800006f: 89 c2 mov %eax,%edx
8000071: 01 d2 add %edx,%edx
8000073: 01 c2 add %eax,%edx
8000075: 89 d0 mov %edx,%eax
8000077: 03 45 f8 add 0xfffffff8(%ebp),%eax
800007a: 89 45 fc mov %eax,0xfffffffc(%ebp)
800007d: eb 12 jmp 8000091 <_test+0x56>
800007f: 8b 45 fc mov 0xfffffffc(%ebp),%eax
8000082: 89 c2 mov %eax,%edx
8000084: 01 d2 add %edx,%edx
8000086: 8d 04 02 lea (%edx,%eax,1),%eax
8000089: 89 45 f8 mov %eax,0xfffffff8(%ebp)
800008c: e8 aa ff ff ff call 800003b <_test>
8000091: c9 leave
8000092: c3 ret
8000093: 90 nop
8000094: 90 nop
8000095: 90 nop
8000096: 90 nop
8000097: 90 nop
8000098: 90 nop
8000099: 90 nop
800009a: 90 nop
800009b: 90 nop
800009c: 90 nop
800009d: 90 nop
800009e: 90 nop
800009f: 90 nop
C> objcopy -I pe-i386 -O binary test_adjusted.o test.bin |
#100925 - tepples - Thu Aug 31, 2006 9:42 pm
- Please use arm-eabi-*, not your native tools.
- Unlike on the NES, the Game Boy Advance includes the 192-byte header into ROM space. Executable code starts at 0x080000c0, after the header, not 0x08000000.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#100931 - sajiimori - Thu Aug 31, 2006 10:12 pm
Adjust my example accordingly. If anyone wants to try it, also remember to move the data section to RAM instead of 0x00000000.
#100948 - wintermute - Fri Sep 01, 2006 12:02 am
| Code: |
#include <gba.h>
//---------------------------------------------------------------------------------
// Program entry point
//---------------------------------------------------------------------------------
int main(void) {
//---------------------------------------------------------------------------------
SetMode(MODE_0 | BG0_ON);
BG_PALETTE[0] = RGB5(31,0,31);
while (1);
}
|
Using devkitARM and libgba with standard template makefile results in a 904 byte rom image. This could be made smaller using -nostartfiles, -nostdlib and a custom crt0 but it's probably not really worth the effort if you plan on more complex applications.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog