another day, another problem (touchpad).

[21o6]

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;

{$apptype arm7} //...or arm7
{$define ARM7}   //...or arm7, according to apptype

{$mode objfpc}   // required for some libc funcs implementation

uses
  ctypes; // required by nds headers!

{$include nds.inc}  // headers!

var
  tempPos: touchPosition;

procedure CatchTheTouch();
begin
  tempPos :=  touchReadXY();

  IPC^.touchX := tempPos.x;
  IPC^.touchY := tempPos.y;

end;

begin
  // Reset the clock if needed
  rtcReset();
  irqInit();
  irqSet(IRQ_VCOUNT, @CatchTheTouch);
  irqEnable(IRQ_VCOUNT);

  while true do
    swiWaitForVBlank();
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:\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]

so, i found something out.

This:

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

uses
  cTypes;

{$INCLUDE NDS.INC}


//arm9
var
  touchXY: touchPosition;

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

  irqInit();
  irqEnable(IRQ_VBLANK);

  lcdSwap;


  vram_a[0] := rgb15(0,0,0);

    vram_a[10] := rgb15(0,0,0);
      vram_a[20] := rgb15(0,0,0);

  while true do
  begin
    swiWaitForVBlank;
    touchXY := touchReadXY();
    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]

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]

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]

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? 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 ), 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

[21o6]

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]

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]

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]

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 := (touchxy.px div 14) - 19;
touchxy.py := (touchxy.py div 19) - 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]

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