Calculator Community > ASM

WikiTI

<< < (18/21) > >>

Runer112:
I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues)

For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles.

the_mad_joob:
40 is very generous, indeed =]

Anyway, there seems to be 2 methods :
- no reset : delay required between setting group and reading it
- reset : delay required between resetting and setting the group (delays a lot shorter, but you have to spend some cycles to actually do the reset)

I'm currently thinking of a safe way to know if the current group has been updated or not.
Maybe it's possible by using a trick, involving the blank group $7F...

the_mad_joob:
Still about the keyboard :

I finally found a little something.
The challenge was to find a way to know if the current group has been updated (similar to reading bit 7 of port $10 for the LCD).
It seems impossible, since reading port 1 doesn't actually give any infos about that.
But, fortunately, there is a way to know if : the group has been updated AND a key is being pressed on that group.
I believe it is compatible with all possible hardware types, for all CPU speeds.
There you go :

LD A,$FF
OUT (1),A
LD BC,$??01 < ?? = group to be checked
LOOP
OUT (C),B < using C to make the loop faster
IN A,(1)
INC A
JR Z,LOOP < JP maybe better, not sure...
< group updated & key(s) pressed
DEC A
< A holds the key map for the desired group, safe to check it.

Of course, that is the safe way, not necessarily the fastest.

/e : just corrected it

/e2 : realised that it only allows to test one group at once =/

Streetwalrus:

--- Quote from: Runer112 on May 12, 2014, 08:33:01 am ---I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues)

For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles.

--- End quote ---
Wow that's a lot. O.O is it for 15MHz compatibility ?

Runer112:

--- Quote from: Streetwalrus on May 12, 2014, 11:38:00 am ---
--- Quote from: Runer112 on May 12, 2014, 08:33:01 am ---I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues)

For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles.

--- End quote ---
Wow that's a lot. O.O is it for 15MHz compatibility ?

--- End quote ---

It is. If you look at the old data the_mad_joob collected, some people's calculators were recorded as needed up to 29 cycles of delay at the high CPU speed. So I overshot that to be safe.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version