FPC4NDS: first raw demo

[Legolas]

Well as I mentioned to fpcfan (Vincent) in IRC the ARM7 was put into the NDS simply for backwards compatibility for GBA games so if you're gonna make a NDS game you might aswell just use ARM9.

Not only
Well, in fact the touch screen can be accessed only by arm7, though data are stored in a structure that can be accessed by arm9

[WILL]

ok refresh my memory again

ARM7 = newer than ARM9?

thus:

GB/GBC = z80
GBA = ARM7 + z80 (GBA SD = ARM7 only)
NDS = ARM9 + ARM7

Please correct me where I am in error.

[Legolas]

ok refresh my memory again

ARM7 = newer than ARM9?

ARM9 = newer than ARM7

GB/GBC = z80
GBA = ARM7 + z80 (GBA SD = ARM7 only)
NDS = ARM9 + ARM7

Yes, but:

GBA = GBA SP = ARM7 + z80
GBA Micro = ARM7 only

[WILL]

SP thats what it was!

Wasn't sure if the z80 was left out of the SP or not...

Micro for sure... smaller form factor.

[dmantione]

I (fpcfan) still don't understand it.

In what way is a the relation between ARM7 and ARM9 different from the relation between a Pentium and a 80386? Can't an ARM9 run ARM7 code? Are they much more different from each other than Pentium IV and 80386?

The NDS simply has two types of executables. If you make an ARM7 executable you can access the touch screen for example. The NDS firmware simply treats them in a different way. The difference between these two executables is in ]
Maybe the -P command line parameter is a better option then.
[/quote]

No, generating two different compiler executables doesn't look like it solves anything.

[WILL]

My theory is that it's simply nothing to do with instruction sets, but CPU speeds, cache, etc...

The fact that the double screen can only be accessed with the older CPU makes no sense though... wouldn't you want the most power for your dual screen games? :scratch:

Maybe I'm just falling into the PC developer's line of thinking.

[Legolas]

First libnds conversion attempt is available here:
http://sourceforge.net/projects/libndsfpc

Some TODOs here and there, but it should work... well, I get some errors on no$gba, but it works on Dualis emulator and - most important thing - on real hardware :mrgreen:

In order to work with libnds, you will need to install devkitPro for Nintendo DS (http://www.devkitpro.org).
You can grab the libnds pascal headers from SF SVN (ok, I'll find a way to generate a zipped snapshot ). My web page is down (for some strange reason does not process php and returns a scaring 500 ISE), but you can get fpc4nds from freepascal ftp (about 3.7 MB).

I suggest you to start from this tutorial, that explains very well all nds coding aspects.
libnds porting is 1:1, so converting c code should be a trivial task

A couple of hints:
[pascal]
program main;
{$apptype arm9} //...or arm7
{$define ARM9} //...or arm7, according to apptype

{$mode objfpc}

uses
ctypes; // required by nds headers!

{$include nds.inc} // headers!


// Some libs required by libnds (you will need to install devkitPro!)
{$linklib libc.a}
{$linklib libgcc.a}
{$linklib libsysbase.a}

{$linklib libnds9.a} //...or libnds7.a, according to apptype

begin

while true do; // Infinite loop, otherwise Dualis emulator will suddenly close!

end.
[/pascal]

In order to make your code working:

ppcarmnds.exe -g --gc-sections -Tnds main.pp

You will get main.arm9.bin or main.arm7.bin, according to the apptype. The last step is to convert the binary with ndstool:

ndstool -c main.nds -9 main.arm9.bin

if your application is arm9 only code, or

ndstool -c main.nds -9 main.arm9.bin -7 main.arm7.bin

if your application is both arm9 and arm7

[FPK]

First libnds conversion attempt is available here:
http://sourceforge.net/projects/libndsfpc

Since nds is in fpc svn, why not putting this stuff into fpc/packages/extra/ndsunits of the fpc svn?

In order to make your code working:

ppcarmnds.exe -g --gc-sections -Tnds main.pp

You will get main.arm9.bin or main.arm7.bin, according to the apptype. The last step is to convert the binary with ndstool:

ndstool -c main.nds -9 main.arm9.bin

if your application is arm9 only code, or

ndstool -c main.nds -9 main.arm9.bin -7 main.arm7.bin

if your application is both arm9 and arm7

Maybe this call can be integrated into the compiler too?

[Legolas]

First libnds conversion attempt is available here:
http://sourceforge.net/projects/libndsfpc

Since nds is in fpc svn, why not putting this stuff into fpc/packages/extra/ndsunits of the fpc svn?

Of course I'll put this lib on fpc svn. I have opened an account on sf in order to get some help in translation: there is a nice function for recruitment, and I can give writing permission to pgd people that want to help (well, when someone will ask )

In order to make your code working:

ppcarmnds.exe -g --gc-sections -Tnds main.pp

You will get main.arm9.bin or main.arm7.bin, according to the apptype. The last step is to convert the binary with ndstool:

ndstool -c main.nds -9 main.arm9.bin

if your application is arm9 only code, or

ndstool -c main.nds -9 main.arm9.bin -7 main.arm7.bin

if your application is both arm9 and arm7

Maybe this call can be integrated into the compiler too?

If it is matter of building an arm9 only code, then no problem, but how about arm7 and arm9 mixed sources?

Btw, a question: now I'm defining ARM9 after the apptype call, in order to make some ifdefs inside the headers working. There is a way to check the apptype at compile time, or maybe a way to declare a "global define" inside the nds compiler?

[FPK]

First libnds conversion attempt is available here:
http://sourceforge.net/projects/libndsfpc

Since nds is in fpc svn, why not putting this stuff into fpc/packages/extra/ndsunits of the fpc svn?

Of course I'll put this lib on fpc svn. I have opened an account on sf in order to get some help in translation: there is a nice function for recruitment, and I can give writing permission to pgd people that want to help (well, when someone will ask )

Ok, though they could also get access to fpc svn dirs

If it is matter of building an arm9 only code, then no problem, but how about arm7 and arm9 mixed sources?

The ndstool -c main.nds -9 main.arm9.bin call could be done if the apptype is arm9 to simplify things for starters, no?

Btw, a question: now I'm defining ARM9 after the apptype call, in order to make some ifdefs inside the headers working. There is a way to check the apptype at compile time, or maybe a way to declare a "global define" inside the nds compiler?

No. You've to set the defines when the apptype changes.