Not onlyOriginally Posted by WILL
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
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 ]Originally Posted by Vincent
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.
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.
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:
You will get main.arm9.bin or main.arm7.bin, according to the apptype. The last step is to convert the binary with ndstool:Code:ppcarmnds.exe -g --gc-sections -Tnds main.pp
if your application is arm9 only code, orCode:ndstool -c main.nds -9 main.arm9.bin
if your application is both arm9 and arm7Code:ndstool -c main.nds -9 main.arm9.bin -7 main.arm7.bin
Since nds is in fpc svn, why not putting this stuff into fpc/packages/extra/ndsunits of the fpc svn?Originally Posted by Legolas
Maybe this call can be integrated into the compiler too?In order to make your code working:
You will get main.arm9.bin or main.arm7.bin, according to the apptype. The last step is to convert the binary with ndstool:Code:ppcarmnds.exe -g --gc-sections -Tnds main.pp
if your application is arm9 only code, orCode:ndstool -c main.nds -9 main.arm9.bin
if your application is both arm9 and arm7Code:ndstool -c main.nds -9 main.arm9.bin -7 main.arm7.bin
<a>http://www.freepascal.org</a>
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 )Originally Posted by FPK
If it is matter of building an arm9 only code, then no problem, but how about arm7 and arm9 mixed sources?Originally Posted by FPK
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?
Ok, though they could also get access to fpc svn dirsOriginally Posted by Legolas
The ndstool -c main.nds -9 main.arm9.bin call could be done if the apptype is arm9 to simplify things for starters, no?If it is matter of building an arm9 only code, then no problem, but how about arm7 and arm9 mixed sources?
No. You've to set the defines when the apptype changes.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?
<a>http://www.freepascal.org</a>
Bookmarks