another day, another problem (touchpad).

[Legolas]

maybe there's something i forgot to tell. let's see:

i am using your build_fpc4nds.bat.
i have updated devkitpro with it's automated installer.
i am using the latest source of fpc (using the address from the batch-file)
and the latest libndsfpc.

That batch file needs some updates, I guess ops:
The trunk snapshot now is located at ftp://ftp.freepascal.org/pub/fpc/sna...source/fpc.zip whereas my build batch indicates ftp://ftp.freepascal.org/pub/fpc/sna...source/fpc.zip that was the right address when I wrote it
Better should be to get the sources directly from SVN, by using something like TortoiseSVN.

oh, btw ... i can't compile the snow-demo you've made.
it says:

snow.pp(46,19) Error: Duplicate identifier "QRAN_SHIFT"
snow.pp(47,41) Error: Duplicate identifier "QRAN_MASK"
snow.pp(48,26) Error: Duplicate identifier "QRAN_MAX"
snow.pp(49,24) Error: Duplicate identifier "QRAN_A"
snow.pp(50,27) Error: Duplicate identifier "QRAN_C"
snow.pp(258,40) Error: Identifier not found "VRAM_A_MAIN_BG_0x6000000"
snow.pp(259,40) Error: Identifier not found "VRAM_B_MAIN_BG_0x6020000"
snow.pp(260,39) Error: Identifier not found "VRAM_C_SUB_BG_0x6200000"

That's because I have added that random number generator inside the library, so now it is defined in two places. I guess you have downloaded the demo from my site, that's a bit outdated. Please, try the updated demo shipped with libndsfpc

[21o6]

as expected v23 didn't change anything.

i wonder how many are actually using fpc4nds, because i really wonder why
i am the only one with this problem :D

and i REALLY wonder why i can't use any arm7-code anymore.

now i will try something different and will report after that. if you've got an
idea, just scream! :D

[21o6]

finally. :D

it is simple. very simple.

it's not a libnds-problem, as far as i can tell.

just use the arm/nds-version of fpc214, and ALL PROBLEMS VANISH!
-> http://www.freepascal.org/down2/arm/nds.var (select an appropriate mirror)

i will never ever recompile this shit again (sorry :).

oh and legolas... i think it would be best to point users to this version, than
rather let them compile their own one.

btw ... didn't you say you couldn't use arm7?

No problemo ;)
Uhm... combining arm9 and arm7 hangs the ds here too. Maybe it's an
arm7 related bug, because combining fpc made arm9 and dkp made arm7
works fine :scratch:

maybe YOU should stick to that version too :D

[Legolas]

finally.

it is simple. very simple.

it's not a libnds-problem, as far as i can tell.

just use the arm/nds-version of fpc214, and ALL PROBLEMS VANISH!
-> http://www.freepascal.org/down2/arm/nds.var (select an appropriate mirror)

And you (as user) always should use a stable version. When you popped here stating that nothing worked anymore, I supposed you was using 2.1.4 release, so I suggested to try the trunk version (that I use regularly and that has a lot of bug fixes). My fault.

i will never ever recompile this shit again (sorry .

###!!!Censored!!!###

oh and legolas... i think it would be best to point users to this version, than
rather let them compile their own one.

From my site:

Download :
fpc4nds 2.1.4 - Binaries from Free Pascal server (3.93 MB)
Sources are available on Free Pascal SVN repository

btw ... didn't you say you couldn't use arm7?

No problemo
Uhm... combining arm9 and arm7 hangs the ds here too. Maybe it's an
arm7 related bug, because combining fpc made arm9 and dkp made arm7
works fine :scratch:

maybe YOU should stick to that version too

Yes, I said. And no, I don't: I need to solve that bug on 2.3 trunk.

However, glad you have solved

[21o6]

i am sorry if i said something and stepped on your toe's, that really wasn't
my intention (this is the third time in my life i am posting more than one
post in a forum, so please forgive me.)

thank you for your help and stay tuned, i am looking forward in releasing
something within the next week :)

[Legolas]

i am sorry if i said something and stepped on your toe's, that really wasn't
my intention (this is the third time in my life i am posting more than one
post in a forum, so please forgive me.)

thank you for your help and stay tuned, i am looking forward in releasing
something within the next week

Woops... For the second time in a single thread I have looked harsh (sorry for that ops. Usually I'm a heavy emoticons user, but this time I forgot to add some smilies here and there to explain my intentions

However, I'm pretty sure I have found that bug, or at least, I have found the call in the rtl that breaks arm7 code (hint: system.pp - fpc_cpucodeinit). Now I need to check what that call does and if is safe to remove it
Edit: well, for some strange reason I added that call to fpc_cpucodeinit some times ago, so it should be removed safely

[21o6]

and i thought i was harsh lol

fpc_cpucodeinit...

do you mean the floating-point-instructions?

[Legolas]

Something related, I think: it activates dsp extensions. The problem is that the ARM946E-S processor can handle these extensions, but the ARM7TDMI does not. In order to get all working, I need to deactivate dsp both for amr7 and arm9, because fpc can't retrieve the target at compiling time.

[21o6]

oh i've read the wrong procedure ... fpc_cpuinit instead of fpc_cpucodeinit.

why can't you identify the processor during runtime in fpc_cpucodeinit
(or somewhere else, i didn't go through all of it yet) and act accordingly?

[Legolas]

FPC can identify the processor family (arm, i386, ...) but not the processor type, so there is no way to distinguish between arm7 and arm9