Emulating a keypress in sys_RPL???
f...@waikato.ac.nz
How do I emulate a key-press in sys_RPL?
That is, if I have a keycode in level 2 and a key plane in level 1,
giving the location of a key that is always a menu key, how do I
get the 48 to believe that key has been pressed and evaluate whatever
function is assigned to the menu key at the time?
What I have tried are the sequences: Key>StdKeyOb DoKeyOb
and: Key>StdKeyOb EVAL
I have had limited success with these. If the menukey has some global
user variable name, such as that of a directory, a program or a list
both the above sequences work fine.
However, if the menukey is for some built-in function, like PICT, the 48
will hang on trying either of the above sequences. Things that make you
go mmmmmmhhhh...
To obtain more info I left out the DoKeyOb and EVAL from the above and
only executed Key>StdKeyOb and both object types worked fine and left
something on the stack, which when decompiled, using Detlef's RPL lib,
gave the following secondary:
":: PTR 40828
PTR 3FF9
PTR 41934
;"
I can't find these entries in ENTRIES.A, except PTR 03FF9 appears to
be a binary integer ONE. (Incidentally, the menukey I was trying i both
cases was the first one, ie: keycode #1).
Any ideas for how to achieve a reliable key press emulation? Why are
built-in objects causing trouble?
Regards,
Conan.
-----------------------------------------------------------------
Conan J. Fee _ f...@waikato.ac.nz
Centre for Technology (_)o
University of Waikato, Hamilton /\ \ Phone: +(64)(7)8384206
Private Bag 3105, New Zealand Fax: +(64)(7)8384218
-----------------------------------------------------------------
william j. levenson
Have you seen the entries lists that were posted by Mika Heiskenan to
seq.uncwil.edu in the hp48/Uploads directory? These lists contain many
commented entry, both supported and unsupported (by hP, that is). These
"entries" lists are a valuable tool for exploring the various
undocumented sys-RPL commands. For example, entries.3+ (I think this is
the latest, although I think Mika has made one in entries.a format for
use with the RPL tools) has the entry at 40828 (PTR 40828) described as:
:: TakeOverGETPORC
@ get object bound to menu key (key number follows)
The (::) in the above example indicates that the entrie is an RPL
program and the name (TakeOverGETPROC) was made up by whoever discovered
this particular entry, I guess. The (@) indicates that the following is
a comment regarding the function of the address. Many, many entries are
covered in these lists (Thanks, Mika!) to varying degrees of
thouroughness. Some are left to you to decipher.
This can be done using the <-RPL-> library for RPL routines and MLDL for
machine code routines (at least that's how I've been doing it). To use
the rpl library, let's take PTR 40828 as an example.
1: "PTR 40828" ->RPL ---> 1: "82840"
where ->RPL is in the <-RPL-> library. "82840" is merely the address of
the pointer in a string and reversed. So, you can type the string in
directly if you like. Next,
$-> ---> 1: External External
where $-> is a command in the RPL library. What has just happened is
that the $-> routine has just put whatever is at the address in the
string (backwards, that is) on the stack. Now, you can decompile that
with the RPL-> command to get
1: " :: TakeOver 'R GETPROC ; "
Now you may have to dig deeper to figure out GETPROC, but that's the fun.
Eventually, all the commands lead to machine language routines and
that's another story. But, usually you can figure out what is going on
before you run into ML. If not, try MLDL for some more fun!
Combining all the above tools, you can learn a lot about this machine and
how HP programmers think. Keep in mind, I am NOT an expert at this. In
fact, when I started playing with this stuff about six months ago, I
didn't even know what machine language was! I am just an ignorant
aerospace engineer who didn't get enough comp sci in school. But, I have
learned plenty from this machine. Primarily, I've learned how little I
know. But I am having fun!
I hope all this helps. Let me know
Bill Levenson
Mr S J Liddicott
>Hi Conan!
>
<etc>
>
>:: TakeOverGETPORC
>@ get object bound to menu key (key number follows)
>
>The (::) in the above example indicates that the entrie is an RPL
>program and the name (TakeOverGETPROC) was made up by whoever discovered
>this particular entry, I guess. The (@) indicates that the following is
>a comment regarding the function of the address. Many, many entries are
>covered in these lists (Thanks, Mika!) to varying degrees of
>thouroughness. Some are left to you to decipher.
>
>
>Bill Levenson
>
I think this is a table of what Bill was talking about.
I had it in my file of handy facts. here goes:
From: akcs.j...@hpcvbbs.cv.hp.com (Joseph K. Horn)
Date: 21 Feb 92 07:40:11 GMT
Message-ID: <29a4a0c5:648.3comp.sys.hp48;1...@hpcvbbs.cv.hp.com>
Newsgroups: comp.sys.hp48
James Gentles {j...@hpqtdla.sqf.hp.com} writes:
> Unfortunately the syseval you give enters the Matrix Writer
> application, buy DOES NOT take the object in level 1 of the stack.
> It assumes you wish to start editing a new object. Can anyone help
> me further? I have checked on a couple of ftp sites for lists of
> useful SYSEVAL's like the ones above but with no luck. Your help
> would be appreciated. If the above data came from a larger list, I
> would appreciate a copy.
Here's the *complete* list:
ENTRY POINTS FOR EVERY HP 48 KEY
rc.p .1 .2 .3 .4 .5 .6
-- ----- ----- ----- ----- ----- -----
11 3FFDB 3FFF4 4000D 654CD 65583 7A929
12 4003F 40026 40058 654D4 6558A 7A968
13 40071 4008A 400A3 654DB 65591 7A96F
14 400BC 400D5 400EE 654E2 65598 7A976
15 40107 40120 40139 654E9 6559F 7A97D
16 40152 4016B 40184 654F0 655A6 7A984
21 3AD57 3AE33 1EE53 654F7 655AD 7A98B
22 3AE1A 3A6E5 21FD1 654FE 655B4 7A992
23 3AB72 3ADA2 3ADBB 65505 655BB 7A9A0
24 3AF37 3AD70 3AD89 6550C 655C2 7A9A7
25 3A93D 3AE6F 3B00E 65513 655C9 7A9AE
26 3A71C 3A735 3B211 6551A 655D0 7A9B5
31 3A69A 1A15B 1A140 65521 655D7 7A937
32 3A992 20D65 20B40 65528 655DE 7A9BC
33 1A3BE 1F9C4 1A5E4 6552F 655E5 7A9CA
34 3A834 1E2BA 3AFE6 65536 655EC 7A9D1
35 3A645 3AE4C 3AF69 6553D 655F3 7A9D8
36 3A8DE 1FBBD 3A80C 65544 655FA 7A9DF
41 1B4AC 1B6A4 1EF7E 6554B 65601 7A9E6
42 1B505 1B72F 1F1D4 65552 65608 7A9ED
43 1B55E 1B79C 1F2C9 65559 6560F 7A930
44 1B374 1B426 1B185 65560 65616 7A961
45 1B02D 1BA3D 1B9C6 65567 6561D 7A9FB
46 1B278 1B905 1B94F 6556E 65624 7AA02
51 3A7F3 3AF50 3B068 3A7F3 7AA48 7AA4F
52 3AA82 3A7C6 3B12B 65575 6562B 7AA09
53 3AC3A 3B15D 3B18F 6557C 65632 7AA10
54 3AB09 3B1DF 3AAEB 3AB09 7AA3A 7A999
55 3A5F0 1FBD8 1FCEB 3A5F0 7AA41 7A9F4
61 3AA0A 3B0DB 3B081 3B036 3E5EE 3E5AF
62 65495 3AE88 3BE54 65495 3F167 3F17B
63 6549C 3ADED 48FD6 6549C 3F18F 3F1A3
64 654A3 3AB59 47B5A 654A3 3F1B7 3F1CB
65 1AF05 3A6CC 3AC08 6545D 3A6CC 65433
71 3A893 3A8AC 3A893 3AA37 3AA50 3AA37
72 65480 3A7A3 47AE7 65480 7AA56 7AA17
73 65487 3AEB5 3AEE2 65487 7AA1E 7AA25
74 6548E 3AF05 3AF1E 6548E 7AA2C 7AA33
75 1ADEE 3ABA4 3A6B3 6543A 3ABA4 6568D
81 3A8C5 3A8C5 3A8AC 3AA69 3AA69 3AA50
82 6546B 3B1CB 3B1B7 6546B 7A953 7A94C
83 65472 3ACF8 1A604 65472 654B8 654C6
84 65479 3ACBC 3A6FE 65479 7A93E 7A945
85 1AD09 3ABD6 3AC21 6544F 3ABBD 6542C
91 3A5CD 1A8BB 3A9CE 3A5CD 1A8BB 3A9CE
92 65464 1A8D8 22FEB 65464 654BF 65639
93 3A753 3A77B 3ADD4 3A753 3A77B 3ADD4
94 65686 1AABD 6564E 65686 65671 6564E
95 1AB67 3AB8B 3ABEF 65441 3AB8B 654AA
Caution: The addresses that begin with 7 are in the "hidden" ROM
(bank switched with the native 32K of RAM). Do NOT use SYSEVAL on
these!
Example: The VISIT key has rc.p code (RowColumn.Plane) of 52.3; look
at row 52, column .3 above; see 3B12B. This means that pressing the
VISIT key is the same as executing #3B12Bh SYSEVAL.
So, you say you want to send a matrix into the Matrix Writer? Well,
you'd press the down-arrow key to do it from the keyboard. That
key's rc.p code is 35.1; see above that its entry point is 3A645.
Try it: [ 1 2 3 ] #3A645h SYSEVAL.
This table was generated by a version E machine. Its validity for
other version HP 48's has not been checked.
The table is 59 lines long and fits nicely on one printed page.
-Joseph K. Horn- EQU akcs.j...@hpcvbbs.cv.hp.com
_________________
I think it explains itself;
--
*----------*-------------------------------------------------------------*
| Sam Jam|"Never underestimate the importance of a cheap laugh"- |
| Liddicott| ph...@csv.warwick.ac.uk | I WAS IN IDAHO | Plucky Duck TTA |
*---------------It's a thing that makes me go hmmm...--------------------*
Detlef Mueller
>How do I emulate a key-press in sys_RPL?
>
>That is, if I have a keycode in level 2 and a key plane in level 1,
As BINTs ?!
>giving the location of a key that is always a menu key, how do I
>get the 48 to believe that key has been pressed and evaluate whatever
>function is assigned to the menu key at the time?
>
>What I have tried are the sequences: Key>StdKeyOb DoKeyOb
> and: Key>StdKeyOb EVAL
>
>I have had limited success with these. If the menukey has some global
>user variable name, such as that of a directory, a program or a list
>both the above sequences work fine.
This should work in general, but I would suggest to use the former sequence
(let DoKeyOb evaluating a keyob) with PTR 3F9FD instead of Key>StdKeyOb -
PTR 3F9FD checks for special conditions (ParOuterLoop running, USER enabled
etc.).
>However, if the menukey is for some built-in function, like PICT, the 48
>will hang on trying either of the above sequences. Things that make you
>go mmmmmmhhhh...
> [..]
>Any ideas for how to achieve a reliable key press emulation? Why are
>built-in objects causing trouble?
I didn't have any trouble when running the following program with menu 13.01
being active; pressing the [A] key returns PICT into the stack (I also
checked it with Key>StdKeyOb - same result):
%%HP: T(3);
"::
CK0NOLASTWD
BlankDA2
$ "Perform a keystroce\031"
DISPROW5
WaitForKey ( \-> #kc #pl )
PTR 3F9FD ( \-> keyOb )
DoKeyOb
;"
Hope that helps,
8-Detlef
--
+------------------------------------+--------------------------------------+
|`What a depressingly stupid machine'| Detlef Mueller |
| -- Marvin | det...@dmhh.hanse.de |
+------------------------------------+--------------------------------------+
f...@waikato.ac.nz
> In article <1992Nov16.0...@waikato.ac.nz> f...@waikato.ac.nz writes:
>
>>How do I emulate a key-press in sys_RPL?
>>
>>That is, if I have a keycode in level 2 and a key plane in level 1,
>
> As BINTs ?!
>
Yes as BINTs, as far as I know - I've checked these on the stack with the
TYPE command - both are type 20.
>
> I didn't have any trouble when running the following program with menu 13.01
> being active; pressing the [A] key returns PICT into the stack (I also
> checked it with Key>StdKeyOb - same result):
>
>
> %%HP: T(3);
> "::
> CK0NOLASTWD
> BlankDA2
> $ "Perform a keystroce\031"
> DISPROW5
> WaitForKey ( \-> #kc #pl )
> PTR 3F9FD ( \-> keyOb )
> DoKeyOb
> ;"
>
> Hope that helps,
> 8-Detlef
Mmmh. Nope. That doesn't work - if anything it's worse, as the 48 hangs
on the 3F9FD pointer, so I can't even get the key object on the stack.
This happens even if I put in the BINTs as commands ie: #1 #1 PTR 3F9FD
still hangs the machine.
I'm SURE I have two BINTs on the stack when I try to call the key object.
However, the problem may arise earlier. In fact prior to calling the
Key>StdKeyOb, I muck about with the current menu, using GetMenu% to get
the current menu number, then I change the number on the stack and use
InitMenu% followed by DispMenu to change to and display a new menu.
THEN I have the BINTs left on the stack and try to emulate the particular
keypress. Is it just that the current menu key objects aren't defined when
I try to call them? Remember, the routine (using Key>StdKeyOb rather than
your pointer) works for RAM menu objects but not for built-in menus.
I should also mention that if I stop the routine at the Key>StdKeyOb command
I am left with the secondary on the stack and when I press EVAL, the key
object is evaluated for both RAM and Built-in objects. If I get tricky and
put the sys_RPL routine in a programme with (user) EVAL called afterwards,
ie: << sysroutine EVAL >>
I am back to the start in that RAM objects work, while built-in objects hang.
Any further thoughts? I appreciate your help very much!
Ryan M. Grant
So who's gonna make up the first HP macro recorder?
Is it a useful thing?
- Ryan Grant
christopher williams
er, that would be the _second_ macro recorder. here's one that records
what you do to the stack:
%%HP:T(3);
@
@ MACRO - a keystroke recorder for the HP48.
@
@ Author: Mark Warburton
@ mwarburt(at)sirius.UVic.CA
@
@ Download this program to your HP48 and store it as MACRO.
@ The program must be named MACRO so that, when you've finished
@ recording your keystrokes and you hit MACRO, the command "MACRO"
@ is not recorded as well.
@
@ The program will kick the HP48 out of User mode when it finishes,
@ regardless of its previous status. If you use User mode, you can
@ just remove the -62 CF from the program.
@
@ Instructions: Hit MACRO to start recording. A "3" (sideways "M" which
@ stands for Macro) will appear in the status line to indicate
@ that recording is active. Hit MACRO again to stop
@ recording. The completed program will be returned to
@ the stack.
@
\<< IF -63 FC? THEN "\<<" 'MDAT' STO
\<< \-> s \<< IF s "MACRO" \=/ THEN 'MDAT' " " s + STO+ END \>> \>>
'\GbENTER' STO
\<< \-> s \<< 'MDAT' " " s + STO+ s OBJ\-> \>> \>> '\GaENTER' STO
-62 SF -63 SF 3 SF
ELSE -62 CF -63 CF 3 CF MDAT OBJ\-> { \GaENTER \GbENTER MDAT } PURGE END
\>>