PDA

View Full Version : another day, another problem (touchpad).



21o6
08-07-2007, 04:56 PM
Hi ... AGAIN. :)

I can not read the touchpad.

It worked before. before = yesterday, before i recompiled fpc ...

it's not the code, because it ran before and i also copied the code from
another thread from here.

it can't be my batch-file either (or are there any new compiler switches that
i need for the touchpad O_O).

here's the code anyway:


Program Touch;
{$APPTYPE ARM9}
{$DEFINE ARM9}
{$MODE OBJFPC}

uses
cTypes;

{$INCLUDE NDS.INC}

var
touchXY: touchPosition;

begin
consoleDemoInit();
videoSetMode(MODE_FB0);
vramSetBankA(vram_A_LCD);

irqInit();
irqEnable(IRQ_VBLANK);

lcdSwap;

while true do
begin
touchXY := touchReadXY();
If &#40;touchXY.X <> 0&#41; then
vram_A&#91;100 * 256 + 100&#93; &#58;= rgb15&#40;31,31,31&#41;;
end;
end. ... saved as touch.pp9

and...


program Touch;

&#123;$apptype arm7&#125; //...or arm7
&#123;$define ARM7&#125; //...or arm7, according to apptype

&#123;$mode objfpc&#125; // required for some libc funcs implementation

uses
ctypes; // required by nds headers!

&#123;$include nds.inc&#125; // headers!

var
tempPos&#58; touchPosition;

procedure CatchTheTouch&#40;&#41;;
begin
tempPos &#58;= touchReadXY&#40;&#41;;

IPC^.touchX &#58;= tempPos.x;
IPC^.touchY &#58;= tempPos.y;

end;

begin
// Reset the clock if needed
rtcReset&#40;&#41;;
irqInit&#40;&#41;;
irqSet&#40;IRQ_VCOUNT, @CatchTheTouch&#41;;
irqEnable&#40;IRQ_VCOUNT&#41;;

while true do
swiWaitForVBlank&#40;&#41;;
end. ... saved as touch.pp7

my batch-file looks like this:


@cls
ppcarmnds %1.pp9 -Sg
ppcarmnds %1.pp7 -Sg
ndstool -c %1.nds -9 %1.arm9.bin -7 %1.arm7.bin
j&#58;\nds\no$gba %1

-Sg enables Jumping
%1 = Parameter 1 for the batch-file

I have tried using px instead of x, which of course didn't make any difference, probably because there isn't any ipc happening at all.

i did not look at the asm-source yet. i could, but i do not have a reference
to compare with ... maybe if someone could compile the code and upload
the asm-source somewhere ... it could help me find the error.

any advise?

21o6
08-07-2007, 10:26 PM
so, i found something out.

This:


Program Touch;
&#123;$APPTYPE ARM9&#125;
&#123;$DEFINE ARM9&#125;
&#123;$MODE OBJFPC&#125;

uses
cTypes;

&#123;$INCLUDE NDS.INC&#125;


//arm9
var
touchXY&#58; touchPosition;

begin
consoleDemoInit&#40;&#41;;
videoSetMode&#40;MODE_FB0&#41;;
vramSetBankA&#40;vram_A_LCD&#41;;

irqInit&#40;&#41;;
irqEnable&#40;IRQ_VBLANK&#41;;

lcdSwap;


vram_a&#91;0&#93; &#58;= rgb15&#40;0,0,0&#41;;

vram_a&#91;10&#93; &#58;= rgb15&#40;0,0,0&#41;;
vram_a&#91;20&#93; &#58;= rgb15&#40;0,0,0&#41;;

while true do
begin
swiWaitForVBlank;
touchXY &#58;= touchReadXY&#40;&#41;;
If &#40;touchxy.X <> 0&#41; then
begin
iprintf&#40;#27 + '&#91;7;5H' + 'Touch x = %04X, %04X' + #10, &#91;touchxy.px, touchxy.py&#93;&#41;;
vram_A&#91;&#40;touchxy.py div 16&#41; * 256 + &#40;touchxy.px div 16&#41;&#93; &#58;= rgb15&#40;31,31,31&#41;;
end;
end;
end.

...WORKS. It's the code for ARM9 and it works... but it's strange, because:

1st:
i've read that the arm9 can't communicate with the touchpad directly and has
to do this via arm7 and ipc, BUT THERE IS NO arm7-code.

2nd: normally i used px/py without dividing and it gave me the exact
position of the pen, whereas NOW i have to divide px/py (like before in x/y,
which gave me unexact results) and x is increasing continously and y just stays empty.

what the hell is going on here??

Legolas
09-07-2007, 09:25 AM
Old versions of libnds required to write arm7 touch screen handling code by hand. New versions include a default handler that provides touhscreen access directly from arm9, so usually you don't need to do it by hand :)

21o6
09-07-2007, 11:16 AM
i don't really like the idea. there's no real benefit except i don't have to write
like what, 10 lines of code? it seems to me that the drawbacks weigh much
heavier than the benefits.

-> how do i write my own handler now?

-> why is x increasing, y empty and px/py now lacking any precision, which
they had before? (I still don't know how to calculate the correct values,
a simple div16 doesn't really do the trick but that's not the problem here).

-> "it's a lie". the arm9 can't communicate with the SPI, but the library
fools you in believing it can.

so ... how do i write my own handler, which gives me correct results,
which i actually expect? :D i don't care about that as long i can write
my own one (and pass stuff via IPC, which doesn't seem to work anymore,
because i can't even pass a simple 1 via ipc^.touchx, for example.)

i really appreciate your work and effort (i wouldn't be here without you
and wouldn't code my nds without you :D), but this really really reminds
me of "it's not a bug, it's a feature" ...

Legolas
09-07-2007, 12:21 PM
i don't really like the idea. there's no real benefit except i don't have to write
like what, 10 lines of code? it seems to me that the drawbacks weigh much
heavier than the benefits.
-> how do i write my own handler now?

Sorry, but I think you are aiming your arrows to the wrong target. This change is not my choice, but Wintermute's (the guy that created libnds).



-> why is x increasing, y empty and px/py now lacking any precision, which
they had before? (I still don't know how to calculate the correct values,
a simple div16 doesn't really do the trick but that's not the problem here).

I don't know. I got similar issues with emulators, while the same code worked as expected on real hardware.


-> "it's a lie". the arm9 can't communicate with the SPI, but the library
fools you in believing it can.

The way the lib works is: every VBlank, arm7 reads the input device state and stores them in the IPC struct in the shared memory. On the arm9 you can find some useful functions that read that shared memory. The arm9 can't communicate with the SPI, but can read the shared memory. The arm7 default code does the trick.


so ... how do i write my own handler, which gives me correct results,
which i actually expect? :D i don't care about that as long i can write
my own one (and pass stuff via IPC, which doesn't seem to work anymore,
because i can't even pass a simple 1 via ipc^.touchx, for example.)

Let me investigate a bit about that


i really appreciate your work and effort (i wouldn't be here without you
and wouldn't code my nds without you :D), but this really really reminds
me of "it's not a bug, it's a feature" ...
In fact, as you guess, it's not a bug, it's a feature :P

21o6
09-07-2007, 12:40 PM
i am sorry for ranting at you.

i really thought that was your idea, sorry for that too. i am just upset that
i always run into problems without knowing why.

i have tried the code on my phat nds and it works as in the emulator. now
i have to figure out how to calculate the right values (i don't know if i can
look that up somewhere, but actually i find that one out myself. i really
need more training to get back into coding :D).

thank you for taking time and investigating in how i can write my own
handler and stuff :D

oh and... i really consider this more a bug than a feature :D

(i will take a deep look into hardware/registers/memory layout now) ...

Legolas
09-07-2007, 12:56 PM
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:

21o6
09-07-2007, 01:09 PM
i didn't even recognize that it hangs the DS ... i've tested on a black screen
waiting for input from the touchpen ... lol

that explains why ipc didn't work, too.

ok, i go shoot myself now xD

seriously, if i can help in any way, please tell me :D

21o6
09-07-2007, 06:07 PM
i have fiddled around a bit with the coordinates.

it's not 100% exact, but it's waay better than only doing div 16 and really
sufficient when used on hardware.


touchxy.px &#58;= &#40;touchxy.px div 14&#41; - 19;
touchxy.py &#58;= &#40;touchxy.py div 19&#41; - 10;

this gives me the best result, the X/Y-range goes from 0..251:0..191.

Tested with no$gba and my phat NDS.
Please note that your emulator will probably give slightly different results.

i hope this will get obselete soon :)

oh and... does anybody actually need this stuff? 100+ views but nobody's posting.

technomage
09-07-2007, 06:50 PM
I would say the touch pad is really important.

I think you are breaking new ground here, that will expalin the lack of posts, I myself have played with the DS stuff, but I've had to put it to one side for now.

Keep up the investigation :)

21o6
09-07-2007, 07:19 PM
thank you for replying :D

i hope you get back to coding your ds soon, it's really fun :D

Legolas
09-07-2007, 07:54 PM
i have fiddled around a bit with the coordinates.

it's not 100% exact, but it's waay better than only doing div 16 and really
sufficient when used on hardware.


touchxy.px &#58;= &#40;touchxy.px div 14&#41; - 19;
touchxy.py &#58;= &#40;touchxy.py div 19&#41; - 10;

this gives me the best result, the X/Y-range goes from 0..251:0..191.

Tested with no$gba and my phat NDS.
Please note that your emulator will probably give slightly different results.

i hope this will get obselete soon :)

oh and... does anybody actually need this stuff? 100+ views but nobody's posting.

Sorry, but I don't get the clue... This code:

Program Touch;
{$APPTYPE ARM9}
{$DEFINE ARM9}
{$MODE OBJFPC}
uses
cTypes;
{$INCLUDE NDS.INC}
var
touchXY: touchPosition;
begin
irqInit();
irqSet(IRQ_VBLANK, nil);
irqEnable(IRQ_VBLANK);
videoSetMode(0);
videoSetModeSub(MODE_0_2D or DISPLAY_BG0_ACTIVE);
vramSetBankC(VRAM_C_SUB_BG);
SUB_BG0_CR^ := BG_MAP_BASE(31);
BG_PALETTE_SUB[255] := RGB15(31,31,31);
consoleInitDefault(pu16(SCREEN_BASE_BLOCK_SUB(31)) , pu16(CHAR_BASE_BLOCK_SUB(0)), 16);
while true do
begin
swiWaitForVBlank();
touchXY := touchReadXY();
iprintf(#27 + '[16;0H' + 'Touch x, px = %04X, %03i' + #10, [touchXY.x, touchXY.px]);
iprintf('Touch y, py = %04X, %03i' + #10, [touchXY.y, touchXY.py]);
end;
end.

gives to me your same results without dividing anything. On DS phat, for px and py I get values in the range 1-252, 1-192 :scratch:

21o6
09-07-2007, 08:27 PM
tested it on emulator and hardware ... x is increasing, y is empty and
px/py are way out of bounds.

so it's my compiler's fault?

Legolas
09-07-2007, 09:40 PM
tested it on emulator and hardware ... x is increasing, y is empty and
px/py are way out of bounds.

so it's my compiler's fault?

At this point I think so :think:
Please, try this (http://www.evilshare.com/f51ea0ba-7fb4-102a-847b-00a0c993e9d6) file on your ds

21o6
09-07-2007, 09:50 PM
yep, you'r .nds works.

oh great ...

now what? recompile fpc4nds AGAIN? i don't think that'll help...

Legolas
09-07-2007, 10:21 PM
yep, you'r .nds works.

oh great ...

now what? recompile fpc4nds AGAIN? i don't think that'll help...

Try to download the sources from SVN now, because I have uploaded some changes I had in my local SVN repository. If you have some compiling problems, please let me know and I'll try to help you ;)

21o6
09-07-2007, 10:48 PM
downloaded the new package 0809, recompiled fpc without errors...

result = the same

:(

Legolas
09-07-2007, 11:10 PM
That's very strange... Try to do a "make clean PPC_TARGET=arm" before compiling all stuff

21o6
10-07-2007, 11:16 AM
tried it. it did more stuff than before, but that didn't change anything.

21o6
10-07-2007, 11:32 AM
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.

directorys are:
d:\fpc for the fpc-source
d:\fpc4nds for youknowwhat
d:\arm-nds for binutils.

looking at the output when compiling fpc, there is no error, just a bunch
of warnings, for example something like tthread.inc is a stub and such.

my fpc.cfg, located in d:\fpc4nds\bin\arm-nds is:

-Tnds
-FuD:\fpc4nds\units\arm-nds
-XParm-nds-
-FDD:\fpc4nds
-FDD:\fpc4nds\bin\arm-nds
-FiD:\fpc4nds\libnds
-FlC:\devkitpro\libnds\lib
-FlC:\devkitpro\devkitARM\lib\gcc\arm-eabi\4.1.1
-FlC:\devkitpro\devkitARM\lib\gcc\arm-eabi\4.1.1\thumb
-FlC:\devkitpro\devkitARM\arm-eabi\lib
-FlC:\devkitpro\devkitARM\arm-eabi\lib\thumb

my batch-file for compiling arm9 is:

ppcarmnds %1.pp9 -Sg
@j:\nds\no$gba %1

... ppcarmnds is located in d:\fpc4nds\bin\arm-nds, which is included
in the path.

my batch-file for compiling arm9 and arm7 is

ppcarmnds %1.pp9 -Sg
ppcarmnds %1.pp7 -Sg
ndstool -c %1.nds -9 %1.arm9.bin -7 %1.arm7.bin
j:\nds\no$gba %1

PATH is:

PATH=c:\devkitPro\msys\bin;C:\WINDOWS\system32;C:\ WINDOWS;C:\WINDOWS\System32\Wb
em;C:\FPC214\bin\i386-Win32;D:\FPC4NDS\bin\arm-nds;c:\devkitpro\devkitarm\bin

... i have tried only with PATH=d:\fpc4nds\bin\arm-nds too.

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"

maybe that give's you a clue. the converted 3d-examples you provided
did work properly (didn't test anything else yet).

i guess that's it. only thing i can try now is formating my hdd and
reinstalling XP ... sounds like a great idea xD

Legolas
10-07-2007, 01:11 PM
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 :oops:
The trunk snapshot now is located at ftp://ftp.freepascal.org/pub/fpc/snapshot/v23/source/fpc.zip whereas my build batch indicates ftp://ftp.freepascal.org/pub/fpc/snapshot/v21/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
10-07-2007, 05:14 PM
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
10-07-2007, 06:15 PM
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
10-07-2007, 06:57 PM
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)

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 :D

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

However, glad you have solved

21o6
10-07-2007, 07:26 PM
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
10-07-2007, 07:33 PM
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 :oops:). Usually I'm a heavy emoticons user, but this time I forgot to add some smilies here and there to explain my intentions :D

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 :D
Edit: well, for some strange reason I added that call to fpc_cpucodeinit some times ago, so it should be removed safely :)

21o6
10-07-2007, 07:48 PM
and i thought i was harsh lol

fpc_cpucodeinit...

do you mean the floating-point-instructions?

Legolas
10-07-2007, 10:11 PM
Something related, I think: it activates dsp extensions (http://www.arm.com/products/CPUs/cpu-arch-DSP.html). The problem is that the ARM946E-S processor can handle these extensions (http://www.arm.com/products/CPUs/families/ARM9EFamily.html), but the ARM7TDMI does not (http://www.arm.com/products/CPUs/families/ARM7Family.html). 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 (http://www.pascalgamedevelopment.com/viewtopic.php?p=28580#28580).

21o6
11-07-2007, 09:16 AM
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
11-07-2007, 11:25 AM
FPC can identify the processor family (arm, i386, ...) but not the processor type, so there is no way to distinguish between arm7 and arm9

21o6
11-07-2007, 03:57 PM
i have searched for a cpuid-like instruction, but didn't find one (which doesn't
say anything, because i was short on time).

if i give you code to determine which processor is running the current
application, would that help?

21o6
11-07-2007, 05:01 PM
i've done it.

it's really easy :D

i've got environment-aware programs now (well ... at least it sounds good xD)

Legolas
11-07-2007, 05:31 PM
Nice! Please, explain now :D

21o6
11-07-2007, 05:59 PM
first i thought about a cpuid-like-instruction, but didn't find anything in the manuals... then i thought it's possible to measure the performance to determine which cpu the code is running on, but that's too complicated.

so i thought... each processor has features the other doesn't have, so i
tried this:


var
Dummy &#58; pcuint16 = pointer&#40;$06800000&#41;;
WhichAmI &#58; Boolean; // True = ARM9

begin
Dummy&#91;0&#93; &#58;= 2106;

If &#40;Dummy&#91;0&#93; = 2106&#41; then WhichAmI &#58;= True
Else WhichAmI &#58;= False;
End.

You see, the ARM7 can't write to bank A of VRAM, but it doesn't give
any error ... it just doesn't write there... so it's easily determinable
what CPU is running the code ... do you understand? :D

btw, tested in no$gba and on real hardware ... and worked.

does this help you?

edit: the actual code i've used is different. because i can't do printf on
arm7 i had to use ipc to tell arm9 if arm7 found itself, but as you want
the program to know on which CPU it's running, the code above should
give you what you need. :)

WILL
11-07-2007, 08:30 PM
*high five* 21o6! :D

Now thats the kind of pioneering that we love to see at PGD. Nice work. ;)

21o6
11-07-2007, 08:39 PM
are you making fun of me? :scratch:

i'm sorry, i'm really not used to forums :D

thank you :D

WILL
11-07-2007, 08:56 PM
No, I thought your solution was very innovative. Keep up what you're doing. :thumbup:

(oh and turn on BBCode in your posts if you want to see the smilies. ;))

21o6
11-07-2007, 09:28 PM
thank you :D

i hope legolas can use this :)

(and yeah, i forgot to turn it on. i normally don't like them, but the scratching
one was really appropriate :D)

Legolas
11-07-2007, 09:51 PM
The idea beyond your workaround is very good and seems that work fine :clap:
Btw, this is my modified function I have added to the rtl:
{ CPU detecting function (thanks to 21o6):
----------------------------------------
"You see, the ARM7 can't write to bank A of VRAM, but it doesn't give any
error ... it just doesn't write there... so it's easily determinable what
CPU is running the code"}
function IsARM9(): boolean;
var
Dummy : pword absolute $06800000;
begin
Dummy^ := $C0DE;
IsARM9 := Dummy^ = $C0DE;
end;

...

if IsARM9 then
fpc_cpucodeinit;
(Please, note the g33k value :cylon: :mrgreen:)

21o6
11-07-2007, 10:18 PM
\:D/

thank you for quoting me :D

using $C0DE was a great idea :DD