View Full Version : GBA + FPC = Possiblility???
Well, I am currious... those of you that use FPC... would you be interested in Game Boy Advance development if it becomes a reality?
I see it as a great oppertunity to get into hard core game development as it's all 2D, really (no built-in 3D graphics hardware). And the CPU it's self is built for just raw power. It's old-school game programing at it's best. And it's very popular right now, plus it's portable. What more could you want for your game releases? It may be an 'in' for aspiring indie-game developers. ;)
cairnswm
01-12-2004, 04:53 AM
I suppose it could be interesting. I just dont have a GBA... And I dont really see the point of getting myself one - except I suppose if I could write games for it :)
Legolas
01-12-2004, 01:40 PM
Unfortunately Nintendo don't allows to sell indie projects, AFAIK... It need to be an official Nintendo developer. Except that, I tried some times ago to work with gba-gcc and it's pretty easy to make a simple game. :)
savage
01-12-2004, 01:48 PM
Almost anything that advances the Pascal game development community, in general, should be a Good Thang ( tm ).
My son has a GBA so I could tell him he's been bad and "conficate" it for R&D :). I am kidding of course.
Also it does not matter if you do not have a GBA, as you can use various GBA Emulators ( like http://sdlemu.ngemu.com/basdl.php ) to test out your Pascal GBA code before having to test it on a real GBA.
I would give it a try if an FPC/GBA port was available.
Adding a new target to FPC is no problem. However, as far as I can see, the GBA requires the usage of the thumb arm instruction set which is a reduced instruction set which isn't supported by FPC yet. If there is a real interest, the support of this instruction set can be added of course.
How can we show support FPK? I can count at least 5 people that want to be able to do this without thinking, right now all by name from this board alone.
We even have 1 member that is actively trying to get something together for it aswell. See this thread http://www.pascalgamedevelopment.com/viewtopic.php?t=1621
cairnswm
03-12-2004, 06:42 AM
FPK - how about windows mobile on the Smartphone!!!!
I've got the Motorola MPX200 and would be quite willing to help get it working - OK more than willing as it means I dont need to learn Imbedded VB or C++
Traveler
03-12-2004, 09:30 AM
Well to behonest, making games for pc (windows or linux for that matter) is already difficult enough. (For me anyways). And as "aspiring indie-game developer" i'd rather stick to this platform.
In my opinion its nice to see the possibilties for creating games on different platforms is growing, but I would be more pleased if we actually get to see more finished games.
Lightning
03-12-2004, 09:42 AM
Well guys, in case you don't know that, FPK made the FPC compiler
There is nothing he can't do, but he probably needs some hardware ;) and many people to use that compiler :) i already talked to him about SmartPhone(Symbian+ARM) on #fpc you can contact him there but he doesn't have much time, always talking about technical stuff :lol:
noeska
03-12-2004, 12:20 PM
I think al that is needed on how to modify free pascal for the gba is written here: http://linux.gbadev.org/gcc-gba/ .
The important part is crt0.s as this defines the gba (cartridge/executable) header. But even more improtant is the lnkscript that is used. As that glues together the crt0.o with your applicton .o file in a special way. Without that linked in to the executable nothing is going to work.
For direct memory access on the gba i believe pointername := pointer(memoryaddress) is possible. So using pure pascal code it should be possible to change graphics mode and write to video memory etc.
Thumb assembly is the least of the concerns to get things working, more important is pointing a pointer to a specific memory address as written above. PS i believe it possible (even on a gba) to switch between thumb and arm assembly...
savage
03-12-2004, 12:34 PM
So can FPK or anyone else clarify if it is a compiler or linker or both?
FPK, are you able to give any rough estimates on the time it would take to make a change to either the compiler or linker to support the crt0.s/crt0.o issue?
Also how much money would it take for you to give up your day job and to work on FPC full time :).
Lightning
03-12-2004, 11:16 PM
Much, much, money !!! (medical equipment, hi-tech stuff, verry well payed)
FPC must be able to run/compile on/for your CPU and the RTL must be compatible with the OS
I still think you should contact him on #fpc or #lazarus-ide (irc.freenode.org)
PS: FPK doesn't like talking too much, it leaves no time to code :)
Well the idea isn't to overload FPK, who has actually taken the time out of an interest in the idea purposed, with all kinds of spin-off ideas. That'll land us with nothing. :?
The memory access/pointers, linker and THUMB instructions issues need to be addressed and should be checked out well first hand. Noeska has done some great work so far. And I'll provide what I can.
I think it would be a much needed aspect of FPC to help it gain popularity.
If you know what to do, it takes one evening to add the gba as new target to the compiler. FPC uses the GNU Binutils to assemble and link, so it's mainly telling the compiler which asm and linker to use.
The next step is to make an rtl, another 1-2 evenings I guess.
Then 3-4 days debugging.
Now the hard part comes: maintain the port, i.e. handle bug reports, adapt it to compiler/rtl changes etc. This is little work, but requires permenant interest and it's the reason why ports like BeOS, NetBSD or OpenBSD died. Nobody maintained them.
However, this doesn't address the thumb problem, I don't know if the gdb needs thumb code or not.
noeska
04-12-2004, 12:04 PM
unfortunately i do not know how to add an port to free pascal. Trying to understand what is going on with linking gives me an headache. To spoiled with delphi i gues. It obviously is not as easy as linking in crt0.o.
If only the first part is done e.g. that the crt0 part is linked in correctly and starts the 'main' procedure. I can continue with my efforts, but without that i cannot continue. My developement pace is slow, i am trying to spend 1 hour evenings on it.
I have already downloaded a snapshot of free pascal, but i have no clue where to begin changing. e.g. the fakertl looks a place to start with rtl developement. But where should it go to?
So what is need to go on is:
A barebones freepascal compiler that proprly links in crt0.s. for the gba target. Or step by step instruction how to so from the cpp version.
Once again the link to how it is done for gnu cpp: http://linux.gbadev.org/gcc-gba/
FPK: There is an excellent book that covers ARM7 in one of it's chapters, though it is written for C programmers, I'm sure you'll be able to get some of what you need from it.
Here is the link to the book: http://www.jharbour.com/gameboy/default.aspx
You are looking for Chapter 11 - 'ARM7 Assembly Language Primer'.
I have also found Mr. Harbour to be quite responsive to topics discussed in his book and he knows Pascal aswell, perhaps he might be able to help with directly asked technical questions.
Anonymous
06-12-2004, 02:19 PM
Why not try to make a gnu pascal cross compiler? Maybe it could be easier than fpc :?:
Legolas
06-12-2004, 07:21 PM
Why not try to make a gnu pascal cross compiler? Maybe it could be easier than fpc :?:
Urgh... I'm sorry... I forgotten to logging in... :oops:
GNU Pascal is not a pure compiler... It's only an extension to GCC.
However... that doesn't rule it out. But, I personally would rather work with FPC since it is more capable and open. Which means much better support and control.
As a side-advantage the GBA roms might even end up being smaller.
Legolas
07-12-2004, 09:29 PM
Anyway I downloaded some documentation and sources... I think I'll try to make it, waiting for a freepascal crosscompiler. :rambo:
I thought Free Pascal did this already...?
Legolas
08-12-2004, 12:33 PM
Uhm... I don't think so. FPC crosscompiler currently does not compile code for gba. There is a version that can crosscompile from i386-linux to arm-linux, not to arm-elf.
Anyway I downloaded some documentation and sources... I think I'll try to make it, waiting for a freepascal crosscompiler. :rambo:
My response to this was that it already cross-compiles. :) At the least it is what I had meant.
As for the GBA port of FPC, why not contact Noeska and FPK(easier to reach on IRC at #fpc, check the FPC website for the server) and see what may help? Noeska is good for it and FPK is willing under the right conditions...
I think what FPK is getting at is not only does he want to see it actually being used, unlike his other BeOS and Solaris ports, but that someone will actually be required to maintain it and handle bug reports and the like aswell.
However I think that we have already established that there is a want and some will use it. I certanly will if it's available to me. But is a handfull of people enough? Maybe, maybe not... I'll definately be looking into this further.
Legolas
09-12-2004, 03:22 PM
Because of my little knowledge, I could only do some beta testing. :oops:
Maybe I can try to port some GBA C code (like libraries and so on) to Pascal.
If Noeska and FPC want a beta-tester, I'm here :D
Was there any further progress with this? Did FPK ever add it to the 'to do' list?
I'll see if I can search out some more information on this later on...
Legolas
01-01-2005, 12:16 PM
I don't know about freepascal, but with a bit of headache and a lot of attempts I built a gpc cross compiler from cygwin to arm-elf that (theorically) could compile gba code :)
At this time I'm trying to convert some simple code from c to pascal to do some testing... Stay tuned! :D
savage
01-01-2005, 05:49 PM
I think most of us are all ears!!!! Or should that be eyes?
Anonymous
05-01-2005, 04:31 PM
[quote="noeska"]I think al that is needed on how to modify free pascal for the gba is written here: http://linux.gbadev.org/gcc-gba/ .
The important part is crt0.s as this defines the gba (cartridge/executable) header. But even more improtant is the lnkscript that is used. As that glues together the crt0.o with your applicton .o file in a special way. Without that ]
im pretty sure the gba supports both thumb and arm instruction sets
iirc due to bus issues thumb is faster when running from cart but arm is faster when running from ram.
Legolas
05-01-2005, 04:59 PM
I can confirm that the gba cpu (arm7tdmi) can handle arm and thumb instructions set. AFAIK gcc for arm can switch between arm and thumb also, by compiling with -mthumb-interwork directive.
Anonymous
05-01-2005, 09:35 PM
Uhm... I don't think so. FPC crosscompiler currently does not compile code for gba. There is a version that can crosscompile from i386-linux to arm-linux, not to arm-elf.
If I understood FPK ok, there is one main problem compiler side:
- FPC supports ARM, but only normal 32-bit ARM assembler. ARM also has a shortened 16-bit THUMB chipset. (not every ARM chip has this, it is an added option). FPC doesn't support THUMB instruction generation yet.
Besides that, the typical other tasks that must be done for a new port:
- somehow create startup code (the already mentioned crt0.[o|as])
- Create something that can interface with the OS.
- Interface to other compiler's libraries (typical GCC) to get access to code.
- Do stuff that is special for that port. (e.g. for Windows: DLL support)
So it is safe to say that 2 things are required of Free Pascal.
1) THUMB instructions
2) a way to link the crt0.[o|as] startup code.
The rest seem like stuff that can be done by a modivated party, which does exist. noeska and {MSX} both have a keen interest aswell as many others.
If someone can confirm to me that this is all that is required, I can try to track down FPK myself or one of the other members of FPC's development team and make a solid requiest for this. OR the detailed information required to make it happen. Otherwise they will not want to do it for nothing.
noeska
06-01-2005, 06:28 PM
1) i am not sure about the need for thumb instructions it seems to me both can be handled although thumb is faster when running from cartridge.
2) linking in the proper crt0.as for booting. This is the part where i fail. If someone get this working i can continue..
I had a small chat with FPK in the #fpc and new #pgd channels...
<WILL> Umm... will I get hurt if I mention GBA? :)
<fpk> no, did you make an fpc port for it ;)?
<WILL> no, but I have interested parties! :)
<WILL> Seriously...
<WILL> noeska and MSX were quite interested....
<WILL> however didn't know what to do to do the required work for it.
<fpk> WILL: first, they must be able to compile fpc from sources
<WILL> ok
<fpk> http://www.freepascal.org/wiki/index.php/How_to_start may help
<WILL> it is FPC source right? it compiles it's self?
<WILL> ah...
<fpk> WILL: yes, see the mention page
<WILL> sorry didn't see it. Looking it over.
<fpk> WILL: then they need to make a fpc/compiler/systems/i_gba.pas and fpc/compiler/systems/t_gba.pas
<fpk> those can be hacked from the other files in that dir
<WILL> fpk: I think noeska is your man...
<WILL> he as looking through the source I think. Didn't know what files to add the THUMB instructions to
<WILL> I'll pass the information you just sent me over to noeska on the thread on PGD
<fpk> if you need thumb instructions, I think it's easier when I do this
<WILL> So you'd be willing to add the THUMB is what you're saying?
<WILL> provided that someone is able to maintain and work on the rest?
<fpk> yes
<WILL> ok
Does this provide you with any insight noeska?
As for the THUMB... if I recall one way is faster from the cart and another way is faster from memory... then agian it might havebeen something to do with types of memory access instead.
Next time I see FPK online I'll ask him about the crt0.as linking. But his best suggestion was that you manage to get a compiling version of FPC first and then you can make a port.
noeska
09-01-2005, 03:34 PM
I will try out the above in the next week. (if i can find time :-) )
The whole trick how to link etc. is done in the fpc/compiler/systems/*.pas files. So take one of the files there, e.g. the i_linux.pas and t_linux.pas and use them as template for t_gba.pas and i_gba.pas. fpc/compiler/arm/cpu.
Include them in the compiler by adding them to fpc/compiler/compiler.pas (i_gba.pas) and fpc/compiler/arm/cputarg.pas.
About thumb: I guess it's possible for now to make a gba port without thumb instructions first. When the compiler supports it, it can be easily used.
Thanks FPK, I'll try to do as you suggest, however I too am limited to my time. :?
I already downloaded the 1.9.6 source, unzipped the compiler sources and opened the i_linux.pas and t_linux.pas hoping for an easy task of just renaming or switching a setting here or there, well I can tell right now I'll be asking quite a few questions about the guts of these two bad-boys. :)
Am I mistaken in the idea that I should remove all other CPU platforms for the i_gba.pas and t_gba.pas?
Also what did you mean by adding "fpc/compiler/arm/cpu." at the end of your first paragraph? I got confused by what you were trying to say with that.
Anonymous
13-01-2005, 08:02 AM
I always first get crt0.c ported (the static prt0.as first, do the cprt one later), and check all structures (which should be a problem since FPC already supports one arm/linux).
So
- The first step is get crt + rtl running for a hello world program,
- the second the compiler itself.
- After that I do the target stuff, to ease compiling.
- and then advance to get shared linking with C working (cprt), and
create full snapshots.
noeska
15-01-2005, 03:36 PM
Like Will i have taken a good look at the i and t files, but i do not get an idea from it as to what to change inside it.
Also i still cannot make sense of the linker script that comes with crt0.s .
I post it below here in the hope that someone says i understand that (i do not, it obviously is not as simple as linking in crt0.o).
Also again a link to: http://linux.gbadev.org/gcc-gba/ .
/* Linker Script v1.3 by Jeff Frohwein */
/* v1.0 - Original release */
/* v1.1 - Added proper .data section support */
/* v1.2 - Added support for c++ & iwram overlays */
/* - Major contributions by Jason Wilkins. */
/* v1.3 - .ewram section now can be used when */
/* compiling for MULTIBOOT mode. This fixes */
/* malloc() in DevKitAdvance which depends */
/* on __eheap_start instead of end to define*/
/* the starting location of heap space. */
/* External global variable __gba_iwram_heap*/
/* support added to allow labels end, _end, */
/* & __end__ to point to end of iwram or */
/* the end of ewram. */
/* This file is released into the public domain */
/* for commercial or non-commercial use with no */
/* restrictions placed upon it. */
/* NOTE!!!: This linker script defines the RAM & */
/* ROM start addresses. In order for it to work */
/* properly, remove -Ttext and -Tbss linker */
/* options from your makefile if they are */
/* present. */
/* You can use the following to view section */
/* addresses in your .elf file: */
/* objdump -h file.elf */
/* Please note that empty sections may incorrectly*/
/* list the lma address as the vma address for */
/* some versions of objdump. */
OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
/* SEARCH_DIR(/bin/arm); */
/* By default this linker script will generate code */
/* for flash carts located at 0x8000000. In order to */
/* generate code that is compiled at 0x2000000 that */
/* will run on flash carts or in multiboot mode then */
/* you need to add the following variable to your main */
/* project file. It's value is NOT important but */
/* IT MUST BE A GLOBAL VARIABLE OR IT WILL NOT WORK: */
/* #define MULTIBOOT int __gba_multiboot; */
/* Then use it like this: MULTIBOOT */
/* By default this linker script will set the labels */
/* end, _end, & __end__ at the end of ewram. To force */
/* them to be set to the end of iwram then you need to */
/* add the following variable to your main */
/* project file. It's value is NOT important but */
/* IT MUST BE A GLOBAL VARIABLE OR IT WILL NOT WORK: */
/* #define IWRAMHEAP int __gba_iwram_heap; */
/* Then use it like this: IWRAMHEAP */
/* The linker script function "var1 += var2;" sometimes */
/* reports incorrect values in the *.map file but the */
/* actual value it calculates is usually, if not always, */
/* correct. If you leave out the ". = ALIGN(4);" at the */
/* end of each section then the return value of SIZEOF() */
/* is sometimes incorrect and "var1 += var2;" appears to */
/* not work as well. "var1 += var2" style functions are */
/* avoided below as a result. */
/* The linker script MEMORY directive is not used here due */
/* to the fact that __text_start is not always a fixed value. */
__text_start = DEFINED (__gba_multiboot) ? 0x2000000 : 0x8000000;
/* __ewram_start = 0x2000000; */ /* Removed in v1.3 */
__eheap_end = 0x2040000;
__iwram_start = 0x3000000;
__iheap_end = 0x3008000 - 0x400;
__sp_usr = 0x3008000 - 0x100;
__sp_irq = 0x3008000 - 0x60;
__intr_vector_buf = 0x3008000 - 4;
__sp_usr_offset = __sp_usr - __iwram_start;
__intr_vect_offset = __intr_vector_buf - __sp_usr;
SECTIONS
{
.text __text_start : /* ALIGN (4): */
{
*(EXCLUDE_FILE (*text.iwram*) .text)
*(.text.*)
*(.stub)
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
*(.gnu.linkonce.t*)
*(.glue_7)
*(.glue_7t)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0xff
/* laddr = ADDR(.text) + SIZEOF(.text); */
__text_end = .;
.rodata :
{
*(.rodata)
*all.rodata*(*)
*(.roda)
*(.rodata.*)
*(.gnu.linkonce.r*)
SORT(CONSTRUCTORS)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0xff
/* laddr += SIZEOF(.rodata); */
.ctors :
{
/* gcc uses crtbegin.o to find the start of the constructors, so
we make sure it is first. Because this is a wildcard, it
doesn't matter if the user does not actually link against
crtbegin.o; the linker won't look for a file to match a
wildcard. The wildcard also means that it doesn't matter which
directory crtbegin.o is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0
/* laddr += SIZEOF(.ctors); */
laddr = ADDR(.text) + SIZEOF(.text) + SIZEOF(.rodata) + SIZEOF(.ctors);
.dtors :
{
KEEP (*crtbegin.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0
/* laddr += SIZEOF(.dtors); */
laddr = ADDR(.text) + SIZEOF(.text) + SIZEOF(.rodata) + SIZEOF(.ctors) + SIZEOF(.dtors);
.eh_frame :
{
KEEP (*(.eh_frame))
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0
/* laddr += SIZEOF(.eh_frame); */
.gcc_except_table :
{
*(.gcc_except_table)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0
/* laddr += (SIZEOF(.gcc_except_table) + 3) & ~ 3; */
/* __iwram_lma = laddr; */
__iwram_lma = (ADDR(.text) + SIZEOF(.text) + SIZEOF(.rodata) + SIZEOF(.ctors) + SIZEOF(.dtors) + SIZEOF(.eh_frame) + SIZEOF(.gcc_except_table) + 3) & ~ 3;
.iwram __iwram_start : AT (__iwram_lma)
{
__iwram_start = ABSOLUTE(.) ;
*(.iwram)
*iwram.*(.text)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0xff
/* laddr += SIZEOF(.iwram); */
/* __data_lma = laddr; */
__data_lma = ADDR(.text) + SIZEOF(.text) + SIZEOF(.rodata) + SIZEOF(.ctors) + SIZEOF(.dtors) + SIZEOF(.eh_frame) + SIZEOF(.gcc_except_table) + SIZEOF(.iwram);
__iwram_end = . ;
.bss ALIGN(4) :
{
__bss_start = ABSOLUTE(.);
__bss_start__ = ABSOLUTE(.);
*(.dynbss)
*(.gnu.linkonce.b*)
*(COMMON)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
}
__bss_end = . ;
__bss_end__ = . ;
.data ALIGN(4) : AT (__data_lma)
{
__data_start = ABSOLUTE(.);
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
CONSTRUCTORS
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0xff
/* laddr += SIZEOF(.data); */
/* __iwram_overlay_lma = laddr; */
__iwram_overlay_lma = ADDR(.text) + SIZEOF(.text) + SIZEOF(.rodata) + SIZEOF(.ctors) + SIZEOF(.dtors) + SIZEOF(.eh_frame) + SIZEOF(.gcc_except_table) + SIZEOF(.iwram) + SIZEOF(.data);
__data_end = .;
PROVIDE (edata = .);
/* __data_lma = LOADADDR(.data); */
__iwram_overlay_start = . ;
OVERLAY : NOCROSSREFS AT (__iwram_overlay_lma)
{
.iwram0 { *(.iwram0) . = ALIGN(4);}
.iwram1 { *(.iwram1) . = ALIGN(4);}
.iwram2 { *(.iwram2) . = ALIGN(4);}
.iwram3 { *(.iwram3) . = ALIGN(4);}
.iwram4 { *(.iwram4) . = ALIGN(4);}
.iwram5 { *(.iwram5) . = ALIGN(4);}
.iwram6 { *(.iwram6) . = ALIGN(4);}
.iwram7 { *(.iwram7) . = ALIGN(4);}
.iwram8 { *(.iwram8) . = ALIGN(4);}
.iwram9 { *(.iwram9) . = ALIGN(4);}
} = 0xff
/* laddr += (SIZEOF(.iwram0)+SIZEOF(.iwram1)+SIZEOF(.iwram2)+S IZEOF(.iwram3)+SIZEOF(.iwram4)+SIZEOF(.iwram5)+SIZ EOF(.iwram6)+SIZEOF(.iwram7)+SIZEOF(.iwram8)+SIZEO F(.iwram9)); */
/* __ewram_lma = laddr; */
__ewram_lma = ADDR(.text) + SIZEOF(.text) + SIZEOF(.rodata) + SIZEOF(.ctors) + SIZEOF(.dtors) + SIZEOF(.eh_frame) + SIZEOF(.gcc_except_table) + SIZEOF(.iwram) + SIZEOF(.data) + SIZEOF(.iwram0)+SIZEOF(.iwram1)+SIZEOF(.iwram2)+SI ZEOF(.iwram3)+SIZEOF(.iwram4)+SIZEOF(.iwram5)+SIZE OF(.iwram6)+SIZEOF(.iwram7)+SIZEOF(.iwram8)+SIZEOF (.iwram9);
/* __iwram_overlay_lma = LOADADDR (.iwram0); */
__iwram_overlay_end = . ;
/* _end = . ; */
/* __end__ = . ; */
/* PROVIDE (end = .); */
__iheap_start = . ;
/* v1.3 */
__ewram_start = DEFINED (__gba_multiboot) ? __ewram_lma : 0x2000000;
.ewram __ewram_start : AT (__ewram_lma)
{
/* __ewram_start = ABSOLUTE(.); */
*(.ewram)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
} = 0xff
/* laddr += SIZEOF(.ewram); */
/* __ewram_overlay_lma = laddr; */
__ewram_overlay_lma = ADDR(.text) + SIZEOF(.text) + SIZEOF(.rodata) + SIZEOF(.ctors) + SIZEOF(.dtors) + SIZEOF(.eh_frame) + SIZEOF(.gcc_except_table) + SIZEOF(.iwram) + SIZEOF(.data) + SIZEOF(.iwram0)+SIZEOF(.iwram1)+SIZEOF(.iwram2)+SI ZEOF(.iwram3)+SIZEOF(.iwram4)+SIZEOF(.iwram5)+SIZE OF(.iwram6)+SIZEOF(.iwram7)+SIZEOF(.iwram8)+SIZEOF (.iwram9) + SIZEOF(.ewram);
/* __ewram_lma = LOADADDR(.ewram); */
__ewram_end = . ;
__ewram_overlay_start = . ;
OVERLAY ALIGN(4): NOCROSSREFS AT (__ewram_overlay_lma)
{
.ewram0 { *(.ewram0) . = ALIGN(4);}
.ewram1 { *(.ewram1) . = ALIGN(4);}
.ewram2 { *(.ewram2) . = ALIGN(4);}
.ewram3 { *(.ewram3) . = ALIGN(4);}
.ewram4 { *(.ewram4) . = ALIGN(4);}
.ewram5 { *(.ewram5) . = ALIGN(4);}
.ewram6 { *(.ewram6) . = ALIGN(4);}
.ewram7 { *(.ewram7) . = ALIGN(4);}
.ewram8 { *(.ewram8) . = ALIGN(4);}
.ewram9 { *(.ewram9) . = ALIGN(4);}
} = 0xff
__ewram_overlay_end = . ;
__eheap_start = . ;
_end = DEFINED (__gba_iwram_heap) ? __iheap_start : .; /* v1.3 */
__end__ = _end ; /* v1.3 */
PROVIDE (end = _end); /* v1.3 */
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
.stack 0x80000 : { _stack = .; *(.stack) }
/* These must appear regardless of . */
}
Legolas
15-01-2005, 07:18 PM
I found somewhere a couple of crt0.s a bit simpler than Jeff Frohwein's one:
@************************************************* *******************
@* crt0.s *
@ This file is a hack. It is not meant for serious work. *
@************************************************* *******************
.TEXT
.GLOBAL _start
_start:
.ALIGN
.CODE 32
@ Start Vector
rom_header: b rom_header_end
@ Nintendo Logo Character Data (8000004h)
.byte 0x24,0xff,0xae,0x51,0x69,0x9a,0xa2,0x21
.byte 0x3d,0x84,0x82,0x0a,0x84,0xe4,0x09,0xad
.byte 0x11,0x24,0x8b,0x98,0xc0,0x81,0x7f,0x21
.byte 0xa3,0x52,0xbe,0x19,0x93,0x09,0xce,0x20
.byte 0x10,0x46,0x4a,0x4a,0xf8,0x27,0x31,0xec
.byte 0x58,0xc7,0xe8,0x33,0x82,0xe3,0xce,0xbf
.byte 0x85,0xf4,0xdf,0x94,0xce,0x4b,0x09,0xc1
.byte 0x94,0x56,0x8a,0xc0,0x13,0x72,0xa7,0xfc
.byte 0x9f,0x84,0x4d,0x73,0xa3,0xca,0x9a,0x61
.byte 0x58,0x97,0xa3,0x27,0xfc,0x03,0x98,0x76
.byte 0x23,0x1d,0xc7,0x61,0x03,0x04,0xae,0x56
.byte 0xbf,0x38,0x84,0x00,0x40,0xa7,0x0e,0xfd
.byte 0xff,0x52,0xfe,0x03,0x6f,0x95,0x30,0xf1
.byte 0x97,0xfb,0xc0,0x85,0x60,0xd6,0x80,0x25
.byte 0xa9,0x63,0xbe,0x03,0x01,0x4e,0x38,0xe2
.byte 0xf9,0xa2,0x34,0xff,0xbb,0x3e,0x03,0x44
.byte 0x78,0x00,0x90,0xcb,0x88,0x11,0x3a,0x94
.byte 0x65,0xc0,0x7c,0x63,0x87,0xf0,0x3c,0xaf
.byte 0xd6,0x25,0xe4,0x8b,0x38,0x0a,0xac,0x72
.byte 0x21,0xd4,0xf8,0x07
@ Software Titles (80000A0h)
.byte 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
.byte 0x00,0x00,0x00,0x00
@ Initial Code (80000ACh)
.byte 0x00,0x00,0x00,0x00
@ Maker Code (80000B0h)
.byte 0x30,0x31
@ Fixed Value (80000B2h)
.byte 0x96
@ Main Unit Code (80000B3h)
.byte 0x00
@ Device Type (80000B4h)
.byte 0x00
@ Unused Data (7Byte) (80000B5h)
.byte 0x00,0x00,0x00,0x00,0x00,0x00,0x00
@ Software Version No (80000BCh)
.byte 0x00
@ Complement Check (80000BDh)
.byte 0xf0
@ Check Sum (80000BEh)
.byte 0x00,0x00
rom_header_end:
@--------------------------------------------------------------------
@- Reset -
@--------------------------------------------------------------------
.EXTERN AgbMain
.GLOBAL start_vector
.CODE 32
.ALIGN
start_vector:
mov r0, #0x12 @ Switch to IRQ Mode
msr cpsr, r0
ldr sp, sp_irq @ Set SP_irq
mov r0, #0x1f @ Switch to System Mode
msr cpsr, r0
ldr sp, sp_usr @ Set SP_usr
str r0, [r1]
ldr r1, =AgbMain @ Start & Switch to 16bit Code
mov lr, pc
bx r1
b start_vector @ Reset
.ALIGN
sp_usr: .word 0x3008000 - 0x100
sp_irq: .word 0x3008000 - 0x60
.ALIGN
.CODE 32
.END
and
# This code belong to the 'text' section
.section .text,"ax"
# All the following code is using ARM instruction set
.arm
# Align with word boundaries
.align 4
# Some external function used later
.extern main
# The startup code function
.global _start
_start:
b rom_start
# Above his the ROM header with dummy values
# and will be override with tools like gba-header
# Nintendo Logo (156 bytes)
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0,0,0,0,0
.byte 0,0,0,0,0,0
# Game Title (12 bytes)
.ascii "ABCDEFGHIJKL"
# Game Code (4 bytes)
.ascii "1234"
# Maker Code (2 bytes)
.ascii "_$"
# Fixed value (1 byte)
.byte 0x96
# Main unit code (1 byte)
.byte 0
# Device Type (1 byte)
.byte 0
# Reserved (7 bytes)
.byte 0,0,0,0,0,0,0
# Software version (1 byte)
.byte 0
# Complement check (1 byte)
.byte 0
# Reserved (2 bytes)
.byte 0,0
.align 4
rom_start:
# Set the User stack
mov r0, #0x1f
msr cpsr, r0
ldr sp, =0x3007ff0
# argc=0 and arg=NULL
mov r0, #0
mov r1, r0
# Jump to the main
bl main
# Just loop now (the program finished)
__loop:
b __loop
In the second I think you must replace all '#' with '@', according with your assembler.
In my gpc-gba attempt I have some problem with direct memory access. Seems like I can't write in $4000000 location when I try to set the screen mode. :(
noeska
16-01-2005, 11:11 AM
LEGOLAS: Did you try: pointer(pointername) := pointer($4000000);
Also using yours seems to get me a little bit further, but now i get warnings about:
FPC_INITIALIZEUNITS and FPC_DO_EXIT .
Legolas
16-01-2005, 12:14 PM
LEGOLAS: Did you try: pointer(pointername) := pointer($4000000);
Yes, I do, but no results :(
I tried by declaring:
var
mypointer: ^cardinal absolute $4000000
without results also. :cry:
Well for simplicity, here are the contents of these two files. They are located in the source's path 'source\compiler\systems\' Now, these are not the GameBoyAdvanced files you would have these are the Linux port that you'd have to duplicate and rename to t_gba.pas and i_gba.pas within the same folder.
t_linux.pas
clip
i_linux.pas
clip
Ok maybe that was a bit over-zealous :roll:
I have made a rough version of the i_gba.pas and t_gba.pas files... using the 1.9.6 (Jan 1st, 2005) source release.
The settings within i_gba.pas are not correct by a longshot, but I take it FPK or Synopsis can help me out with that one. ;) I have also tracked down the GNU tools for ARM binutils for win32 aswell.
http://www.gnuarm.org/
It seems like the initial support for GBA will be heavily relied upon GNU tools until this rumored assembler/linker they are working on comes to bare. :lol: Thats ok though it gets the job done. ;)
Here are the sources I created, the go right into the same folder as the rest of the i and t files (source\compiler\systems):
i_gba.pas
{ This unit implements support information structures for gba. }
unit i_gba;
interface
uses
systems;
const
system_arm_gba_info : tsysteminfo =
(
system : target_arm_GBA;
name : 'GameBoy Advance';
shortname : 'GBA';
flags : [tf_use_8_3]; // ?
cpu : cpu_arm;
short_name : 'GBA'; // ?
unit_env : ''; // ?
extradefines : ''; // ?
sharedlibext : '.dll'; // ?
staticlibext : '.a'; // ?
sourceext : '.pp'; // ?
pasext : '.pas'; // ?
exeext : '.tpp'; // ?
defext : ''; // ?
scriptext : ''; // ?
smartext : '.sl'; // ?
unitext : '.ppu'; // ?
unitlibext : '.ppl'; // ?
asmext : '.s'; // ?
objext : '.o'; // ?
resext : '.res'; // ?
resobjext : '.or'; // ?
staticlibprefix : ''; // ?
sharedlibprefix : ''; // ?
Cprefix : '_'; // ?
newline : #10; // ?
dirsep : '/'; // ?
files_case_relevent : true; // ?
assem : as_gas; // ?
assemextern : as_gas; // ?
link : ld_m68k_atari; // ?
linkextern : ld_m68k_atari; // ?
ar : ar_m68k_ar; // ?
res : res_none; // ?
script : script_unix; // ?
endian : endian_big; // ?
stackalignment : 2; // ?
maxCrecordalignment : 4; // ?
stacksize : 8192; // ?
DllScanSupported:false; // ?
use_function_relative_addresses : false // ?
);
implementation
initialization
{$ifdef arm}
{$ifdef gba}
set_source_info(system_arm_gba_info);
{$endif gba}
{$endif arm}
end.
t_gba.pas
unit t_gba;
{$i fpcdefs.inc}
interface
implementation
uses
link,
cutils,cclasses,
globtype,globals,systems,verbose,script,fmodule,i_ gba;
{************************************************* ****************************
Initialize
************************************************** ***************************}
initialization
RegisterTarget(system_arm_gba_info);
end.
Ok, I left out the GNU GPL stuff to keep it smallfor here, it's still there. Don't shoot! :shock:
as for the other files that FPK mentioned earlier...
source\compiler\arm\cputarg.pas now looks like this:
unit cputarg;
{$i fpcdefs.inc}
interface
implementation
uses
systems { prevent a syntax error when nothing is included }
{**************************************
Targets
**************************************}
{$ifndef NOTARGETLINUX}
,t_linux
{$endif}
{$ifndef NOTARGETGBA}
,t_gba
{$endif}
{**************************************
Assemblers
**************************************}
{$ifndef NOAGARMGAS}
,agarmgas
{$endif}
;
end.
and source\compiler\compiler.pas required me to stick in{$ifdef gba}
,i_gba
{$endif gba}just before
{$ifdef amiga}
,i_amiga
{$endif amiga}
{$ifdef atari}
,i_atari
{$endif atari}
{$ifdef beos}
,i_beos
{$endif beos}
etc...
Next is to set the parameters for GBA properly and get the ARM assembler and linker stuck in there. from there we can work on the crt0 issue after that... then on to the THUMB stuff, but that'll be on FPK :D
noeska, Legolas you guys following how this is coming together?
Legolas
25-02-2005, 04:36 PM
Because lack of spare time I suspended the work with gpc sources. At this time a new alpha version of gpc is out (it compiles with gcc 3.4.3), but I'm waiting for a more stable beta version. Incidentally, a new fpc rc is out... Now I'm downloading it to do some tries.
Forgot to mention that I updated the i_gba.pas to better match the system_arm_linux_info within i_linux.pas for accuracy's sake.
system_arm_gba_info in i_gba.pas looks like this now:
system_arm_gba_info : tsysteminfo =
(
system : system_arm_gba;
name : 'GameBoy Advance';
shortname : 'GBA';
flags : [tf_needs_symbol_size];
cpu : cpu_arm;
unit_env : 'LINUXUNITS';
extradefines : 'UNIX;HASUNIX';
sourceext : '.pp';
pasext : '.pas';
exeext : '';
defext : '.def';
scriptext : '.sh';
smartext : '.sl';
unitext : '.ppu';
unitlibext : '.ppl';
asmext : '.s';
objext : '.o';
resext : '.res';
resobjext : '.or';
sharedlibext : '.so';
staticlibext : '.a';
staticlibprefix : 'libp';
sharedlibprefix : 'lib';
sharedClibext : '.so';
staticClibext : '.a';
staticClibprefix : 'lib';
sharedClibprefix : 'lib';
Cprefix : '';
newline : #10;
dirsep : '/';
files_case_relevent : true;
assem : as_gas;
assemextern : as_gas;
link : nil;
linkextern : nil;
ar : ar_gnu_ar;
res : res_none;
script : script_unix;
endian : endian_little;
alignment :
(
procalign : 4;
loopalign : 4;
jumpalign : 0;
constalignmin : 0;
constalignmax : 4;
varalignmin : 0;
varalignmax : 4;
localalignmin : 4;
localalignmax : 8;
recordalignmin : 0;
recordalignmax : 4;
maxCrecordalign : 4
);
first_parm_offset : 8;
stacksize : 262144;
DllScanSupported:false;
use_function_relative_addresses : true;
abi : abi_default
);
Also, I had to modify source\compiler\systems.pas to include the new system_arm_gba_info so it'll actually compile.
Here is that change:
tsystem =
(
system_none, { 0 }
obsolete_system_i386_GO32V1,{ 1 }
system_i386_GO32V2, { 2 }
system_i386_linux, { 3 }
system_i386_OS2, { 4 }
system_i386_Win32, { 5 }
system_i386_freebsd, { 6 }
system_m68k_Amiga, { 7 }
system_m68k_Atari, { 8 }
system_m68k_Mac, { 9 }
system_m68k_linux, { 10 }
system_m68k_PalmOS, { 11 }
system_alpha_linux, { 12 }
system_powerpc_linux, { 13 }
system_powerpc_macos, { 14 }
system_i386_sunos, { 15 }
system_i386_beos, { 16 }
system_i386_netbsd, { 17 }
system_m68k_netbsd, { 18 }
system_i386_Netware, { 19 }
system_i386_qnx, { 20 }
system_i386_wdosx, { 21 }
system_sparc_sunos, { 22 }
system_sparc_linux, { 23 }
system_i386_openbsd, { 24 }
system_m68k_openbsd, { 25 }
system_x86_64_linux, { 26 }
system_powerpc_darwin, { 27 }
system_i386_EMX, { 28 }
system_powerpc_netbsd, { 29 }
system_powerpc_openbsd, { 30 }
system_arm_linux, { 31 }
system_i386_watcom, { 32 }
system_powerpc_MorphOS, { 33 }
system_x86_64_freebsd, { 34 }
system_i386_netwlibc, { 35 }
system_arm_gba { 36 }
);
Notice the { 36 } in the set? Thats our new GBA target for ARM.
So how do we get the rest incorporated into this bad boy?
I'm thinking:
:arrow: including the GNUARM binutils for win32(and any other platfor we wish to develop GBA in)
:arrow: get a good clean version of the crt0.s
:arrow: and getting FPC to use the binutils to assemble compiled ARM sources into ARM machinecode for both the program being developed and the crt0.s and take the resulting machinecode and linking them all together to make the resulting GBA ROM file.
:arrow: AFTER, ARM7(THUMB) instructions will need to eventually be included
:arrow: and units for development of aspects of the GameBoy Advance's hardware needs to be created, but I imagine that others will be headlong into this as soon as it is possible.
Am I missing anything?
Legolas
26-02-2005, 12:11 PM
Uhm... yes, I already modified source\compiler\systems.pas in this way and tried to make some small changes to i_gba.pas. Anyway the compilation failed, because it doesn't recognise arm-gba like a valid target. I think we need to make some changes to utils\fpcm\fpcmake.ini... :?:
Well it compiled for me. Maybe you missed a step or I forgot to list something I did. :/ Note I used the 1.9.6 release not the new one if that matters much for this here.
I added the system_arm_gba to the tsystem set type thats how it allowed it to recodnize my new specification inside of i_gba.pas. Then it compiled fine. Double check your work you may have missed something.
Legolas
26-02-2005, 10:34 PM
I'm an unlucky man... :D
I triple checked my steps and all seems to be ok. At this point I think I do some errors in making process. I do:
make all OS_TARGET=gba CPU_TARGET=arm CROSSBINDIR=/opt/GbaDevKit/bin BINUTILSPREFIX=arm-agb-elf-
where /opt/GbaDevKit/bin is my cross-binutils directory and arm-agb-elf- is the prefix of cross-binutils.
But, sadly: :cry:
Makefile:172: *** The Makefile doesn't support target arm-gba, please run fpcmake first. Stop.
Any suggestions? :)
I'm guessing you are under linux? :)
Unfortunately I don't know too much about make files. Rather than trying to modify them I'd trying to simply modify the ppcarm(.exe) compiler to include a GameBoy target so that you can have all the benifits of new updates to the compiler it's self rather than a different branch of the same project.
All I did was type "make PPC_TARGET=arm" and I got what I needed done. Of course I first had to kmake sure that I was using GNU make. If this doesn't work I don't know what to tell you. I'm running WinXP.
Legolas
26-02-2005, 11:30 PM
Wrong guess! :D I'm under w2k+cygwin (because of cross-binutils).
Like you, I don't know makefile stuff too... I'm only following some hints I found in buildfaq.pdf (the link is on the fpc wiki). :P
Oh ok. Us both being in win32 might help.
My hints are from FPK himself. ;) So I'm only really sure of what I have done up until now. Next is to figure out how to include the binutils(assembler and linker tools) from the GNUARM.org site's win32(cygwin) package and the crt0.s(ARM assembly code for the GameBoy Advance's bootup sequence) file so that it can be all done with the ppcarm.exe executible.
I assume that we can just stick it in a folder under source\compiler\gba\ and reference to it from there? Then the required binutils package can be stuck in the bin folder? But what are the exact files that we need?
When you go here: http://www.gnuarm.org/
And download from the Files page the Cygwin installer here: http://www.gnuarm.org/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.exe
Install it and when done you'll have the following folders that contain possible sets of the tools we want:
%GNUARM%\bin and %GNUARM%\arm-elf\bin
Which of these folders contain the files we need for the GBA compiling under win32 and what exact files are they?
Keeping in mind we are not trying to make Linux executables here, but those for GBA, we only need the proper tools for doing this under win32(to mirror those that are available already for the arm/linux port of FPC).
Legolas
27-02-2005, 04:16 AM
I think we should use the binutils in %GNUARM%\bin, that is the cross-binutils' directory. Maybe those binutils are prefixed with some prefixes like gnu-arm-ld.exe. But I'm not sure that the tools of gnuarm.org are useful for a gba compiler... :?:
Maybe we can try to use binutils from http://www.devkit.tk/, or try to build it from scratch (that's not so difficult) :D
You know what? I think this link here (http://www.gnu.org/software/binutils/) solves all our questions.
as is the Assembler
ld is the Linker
The best part is that the GNU Bintools already support ARM(and THUMB) amoung a ton of other processor platforms(including MIPS). So it's best to go with the trend as FPC already uses it for it's compiling in the arm/linux platform. We just need to include the win32 versions for the rest of us Dozers. ;) A Mac OS X version too maybe?
Now how do we get FPC to use these the way we need it to?
Almindor
27-02-2005, 09:22 AM
Just a tought here, but perhaps you guys should set up a CVS or atleast FTP repository for you FPC - GBA modified files so you can work together and see progress without this forums overhead.
Anonymous
27-02-2005, 12:36 PM
Just a tought here, but perhaps you guys should set up a CVS or atleast FTP repository for you FPC - GBA modified files so you can work together and see progress without this forums overhead.
Almindor: don't. Simply zip etc.
All that overhead of side projects only keeps time away of actual work.
How to create crt0.s; two possibilities:
- compile from source, but with -S (prefered)
- objdump an existing one.
Best is to do the first, and then crossref that with the objdump to find stuff like ELF identifiers, sections etc.
Anonymous
27-02-2005, 12:37 PM
Best is to do the first, and then crossref that with the objdump to find stuff like ELF identifiers, sections etc.
And if problems occur, objdump a minimal statically compiled C program.
(don't use hello world, but something like return 2+2 or so. You don't want a huge printf implementation in your asm source)
Legolas
27-02-2005, 01:13 PM
I have found some interesting infos here (http://www.stack.nl/~marcov/buildfaq.pdf): we can use -FDC:\somedir to pass binutils directory to fpc compiler. Another way is is to pass CROSSBINDIR=C:\xbinutilsdir to make, with BINUTILSPREFIX=some-prefix- if our binutils have a prefix.
At this point it can be useful to do a sort of planning. As a starting point we should use the same tools:
[1] Cross Binutils binaries from http://www.gnuarm.org or sources?
[2] FPC binaries 1.9.6 or 1.9.8?
[3] FPC sources 1.9.6 or 1.9.8?
Regarding [1]: binaries for the sake of simplicity, sources for a better gba "targeting"...
[2] and [3]: :?: :?: :?:
Gadget
04-03-2005, 12:06 PM
Tell you what would rock...
Pocket PC Dev Kit for FreePascal =D
You know... I think I can feel for the FPC Team on this one so with that I say ":P"
Seriously though, ideas and suggestions like these belong in their own thread. It's rather inappropriate to just pop in a 'Hey, lets do this instead!' esp. after seeing that people have spent a great deal of time and effort in getting something to work and still seeking assistance and feedback on that work in question. And personally a bit annoying. I don't mind the idea, but it belongs in it's own thread so it can be discussed on it's own not in the middle of a conversation thats already starting to get heavily involved in code and other intricate things.
savage
04-03-2005, 10:20 PM
I have started a new thread called Pocket PC Dev Kit for FreePascal (http://www.pascalgamedevelopment.com/viewtopic.php?p=12153#12153) for anyone interested in discussing and or working on this other possibility.
Anonymous
06-03-2005, 08:31 PM
simple mode 3 asm example
e.g. it does not work correctly as i only seem to be able to write to the whole screen on half of it?
needs goldroad assembler to compile
;; ------------------------------------------------------------
;;
;; Basic asm example
;;
@arm
;; ------------------------------------------------------------
;; program entry point
b gba_main
;; ------------------------------------------------------------
;;
;; variables
video_buffer @DCD 0x06000000 ; Screen memory address
display_control @DCD 0x04000000 ; Display register
color_white @DCD 0x0000FFFF ; White
mode3 @DCD 0x00000003 ; mode 3 (240x160x16bit)
bg @DCD 0x00000400 ; background 2
x @DCD 0x00000078 ; x (120)
y @DCD 0x00000050 ; y (80)
width @DCD 0x000000F0 ; screen width (240 px)
gba_main:
; set up screen
ldr r6,[display_control] ; Setup VideoMode
ldr r1,[bg]
ldr r2,[mode3]
orr r1,r1,r2
str r1,[r6]
; test putpixel ( video_buffer[y *width + x]=color )
ldr r0,[video_buffer] ;address of VRAM
ldr r1,[color_white]
ldr r2,[y]
ldr r3,[x]
ldr r4,[width]
mul r5,r2,r4
add r6,r5,r3
str r1,[r0,r6] ;store r1 in r0 with offset r6
; loop forever
loopforever:
b loopforever
noeska
06-03-2005, 08:48 PM
first, sorry for the previous anonymous post.
second i found a better crt0.s and makefile (at least it is smaller and easier to understand). take a look here: http://velvetfr.ath.cx/gba/tutorial/gba-tutorial1.html .
thirdly in the first test pascal sources we should not use variables as variables should be placed in a specific place in gba memory. i believe that the program starts up in rom and so all variables end up being in rom?.
Legolas
07-03-2005, 01:53 PM
Noeska, I think that could be cool (at least for me :P) if you put here a step-by-step-fpc-crossbuilding description :D
noeska
13-03-2005, 04:27 PM
I am still not able to link crt0.o in. However i was told that http://h-storm.tantos.homedns.org/gcc_arm.htm should hold and pascal compiler for arm (gnu pascal maybe) i am currently trying to download it, but it goes verry slooowly....)
PS the nintendo ds came out in europe this weekend and i was able to get hold on one of them. And it plays verry nice indeed... so i am not bored during download :wink:
Legolas
13-03-2005, 07:49 PM
I am still not able to ]http://h-storm.tantos.homedns.org/gcc_arm.htm[/url] should hold and pascal compiler for arm (gnu pascal maybe) i am currently trying to download it, but it goes verry slooowly....)
Yes, I know this project. It's a gpc-based crosscompiler... I tried it, but I have some errors in linking time with rtl. After a lot of attempts, I decided to recompile from scratch, with the sources that you can download (sloooooowly :shock: ) from http://h-storm.tantos.homedns.org. I suggest you to read this (http://www.gnu-pascal.de/crystal/gpc/en/thread11197.html) thread.
Anonymous
15-03-2005, 10:19 AM
You know... I think I can feel for the FPC Team on this one so with that I say ":P"
Seriously though, ideas and suggestions like these belong in their own thread. It's rather inappropriate to just pop in a 'Hey, lets do this instead!' esp. after seeing that people have spent a great deal of time and effort in getting something to work and still seeking assistance and feedback on that work in question. And personally a bit annoying. I don't mind the idea, but it belongs in it's own thread so it can be discussed on it's own not in the middle of a conversation thats already starting to get heavily involved in code and other intricate things.
Sorry, to be honest I thought it was relevant, since Pocket PC uses an ARM CPU.
noeska
15-03-2005, 05:35 PM
pocket pc and gba/ds are different things, they need different crt0 and different libraries. so they cannot be one project. personaly i was not bothered with your post.
I apologize if I sounded a little bit testy in that post. It was not meant to be as harsh as it might have turned out, but we are really far along and Pocket PCs are completely different issue.
Fact is that all we need to do now is figure out how we'll put the peices together I have collected an assembler and linker for the ARM for win32 (includes THUMB instructions aswell so FPC just needs to have it added to allow it) I'll try to upload and post a link to a self-made package of the files required.
Legolas
16-03-2005, 05:18 PM
Now we have a freepascal compiler that can call the right linker and assembler, right? According with a previous post of FPK, now it's then time to make a rtl. Maybe it's a job for fpc team :P
In the while, why don't organise a little team for maintaining/debugging purpose? :idea: AFAIR, FPK said that some fpc ports died because of lack of interest...
Anyone interested? I'm available to do this iob :D
noeska
16-03-2005, 06:15 PM
WILL: did you also manage to link in crt0.o ?
Legolas: This is a good idea. In fact wel collectively should apprach FPK and tell him we would like targetting for GBA in FPC to be official and we will maintain it, if he give us the proper support to do so. I have done a ton of research and work (for a guy that doesn't know GNU tools or assemblers/linkers in the first place -- Just ask 'em, the usual people there, fpcfan,fpk,Synopsis,etc they all seen me messaging like mad about it on #fpc) and if you guys can put in as much as this towards adding support, I'm sure that bit by bit we'll have a semi-functional (ready for an rtl and other GBA hardware device units) compile/assemble/link capability added to Free Pascal. Adding a section to the FPCWiki would be a great start to this effort to make it official aswell (cuz, FPK said so ;)).
noeska: I managed to assemble crt0.s into ct0.o only at this point. I sadly don't know how to link anything yet. I have been working on getting something to compile to have crt0.o linked to it as a test run.
HERE (http://www.pgd.netstarweb.com/gbaforfpc/fpcgba_win32_binutils.zip) is the package that contains the binutils I put together (got it from the GNUARM.org (http://www.gnuarm.org/) site)
THESE (http://www.pgd.netstarweb.com/gbaforfpc/fpc_mod_for_gba01.zip) are the modified FPC source files and a readme to tell you where to place them. This will bring all of you guys up to par with how far I have gone with this. Once you have FPC's 1.9.6 January Source compiled (You must use GNU Make to build it!) using my new modifications we will all be able to work collectively on a solution.
Legolas
17-03-2005, 12:44 PM
Ok, seems that we have the same result :D
I talked about a rtl because I have a "can't find unit System" in compile time :(
Same here, I'll message FPK or Synopsis soon and ask what is going on there.
savage
23-05-2005, 03:43 PM
So guys, any news???
There's an excllent article about pitching to publisher over at gamasutra - http://www.gamasutra.com/features/20050519/diamante_01.shtml and one of the points it states is to start off with a small GBA title, as they are lower budget, need less art resources etc.
Legolas
31-05-2005, 04:31 PM
No news here :(
Now that ver 2.0 is out, maybe FPK & Co. could have some spare time to put their hands on rtl, don't you think so? :wink:
Well considering that FPK is currently working with the CrossFPC team closely it is possible that we could use that to work in some kind of compatability with GBA targeting.
Legolas
01-06-2005, 04:07 PM
Some times ago I proposed to make a team for debugging-mantaining purpose. Maybe making it official (and affiliated to pgd, of course :wink:) could induce fpc team to do an effort in order to make a gba porting...
I would want to propose a sort of "petition" (maybe a poll?) to see how many people are available to eventually join this team or, at least, how many are interested in a fpc-gba porting.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.