akcs.jrchaffer@hpcvbbs.UUCP (J. Richard Chaffer) (05/15/91)
Joe - or anyone -- Documentation on Goodies 2 refers to a file called "XLB - nuts that should be XLIB.DOC.. yet that file isn't on the disk, or on Goodies 1 - or on ;here, that I can find. Anyone know s where I d can get/read that file ?? J.R. Chaffer - 206-773-5433 days, or 206-883-72 scrathc that should be 206-883-7115 evews...
akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn) (05/15/91)
J. Richard Chaffer asks where he can get the "XLIB.DOC" file that's mentioned on the EduCALC Goodies Disk #2. Since it doesn't exist, it is presently very difficult to obtain. The mention of it on the disk was an unfortunate mistake. The file that was GOING to be called XLIB.DOC (omitted from the disk) will be posted here tomorrow. -- Joseph K. Horn -- Peripheral Vision, Ltd. [Note well: It's ltd. VERY ltd...]
akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn) (05/16/91)
J. Richard Chaffer brought to my attention yesterday that the IO.DOC
file in the HORN2 directory on the EduCALC Goodies Disk #2 makes a
reference to the file "XLIB.DOC on this disk" whereas in fact there is
no such file on that disk.
The file XLIB.DOC is an edited version of an excellent article by Rick
Grevelle about XLIB numbers, and how to create, split, and recall the
programs they refer to. It was posted here several months ago. It
somehow got placed in the HORN3 directory. If you can't wait until you
get Disk #3, here it is again. Sorry for the confusion.
Joe Horn
--------------- Rick's article "XLIB.DOC" follows -------------------
From Hewlett Packard's Corvallis BBS
(Comp.sys.handhelds)
Item: 1874 by n233dk at tamuts.tamu.edu
Author: [Rick Grevelle]
Subj: ROM XLIB's (Hidden ROM)
Date: Fri Feb 01 1991 16:08
For those individuals who are currently interested in the 48's
internals, the following information should be somewhat helpful as far
as the use of XLIB's in system RPL is concerned. XLIB's are frequently
found within an RPL instruction stream. Unthreading STO reveals that a
system RPL call made to another RPL routine, which contains an XLIB
object in its instruction stream, can seemingly lead to a dead end.
This is, for the most part, due to the fact it has been impossible to
determine where the system RPL is that's executed when the XLIB is
evaulated.
Now it should be understood that it is ROM based XLIB's I'm referring
to in the above, but the following details can be applied to library
XLIB's as well. The whereabouts of the RPL routine, which is executed
when any of the libraries' XLIB's are evaluated, can be easily
determined simply by reading the link table within that library. Since
this has already been explained by several individuals, and is not
crucial to an understanding of the material about to be disclosed, a
rediscussion will be avoided.
As previously mentioned, the system RPL which constitutes the STO
command, and begins at #20CCDh, when unthreaded reveals several system
RPL routines which contain XLIB objects embedded in their instruction
streams. A good example of this can be found in the RPL routine
responsible for storing a backup or a library object in level two, to
the port specified by the real number in level one. Located at
#215BFh, this RPL routine utilizes what is in fact "XLIB 240 95", and
when evaluated, executes the system RPL which is responsible for the
actual storing of the stack arguments just described.
But where in ROM is the system RPL located that is executed when the
XLIB is evaluated? Well in my version E, it's at #7F7BDh, and is the
ROM that's normally covered by RAM. This is why some system RPL has to
utilize XLIB's to call other system RPL routines. RPL can't call any
of the entry points in the "hidden" ROM by simply placing the address
of the desired routine in the RPL instruction stream. Accessing entry
points in the hidden ROM requires bank switching, and it's XLIB's which
possess this ability. HP uses XLIB's in their system RPL to access the
various entry points in the hidden ROM.
The following programs utilize several prefixed machine routines which
will aid in the manipulation of these previously illusive ROM-based
XLIB's. Only one of the four routines included here do I consider to
be slightly kludged. And although short, all four provide powerful new
tools for manipulating all XLIB's. For the sake of time a SYSEVAL type
listing of the routines is used as explanation.
\->XLIB take two real numbers as arguments and returns the appropriate
XLIB.
Arguments Results
4: 4:
3: 3:
2: 240 2:
1: 95 1: XLIB 240 95
\->XLIB
02D9D begin RPL
18A8D need 2 arguments
18FB2 check arguments
04099 real, real <11h>
02D9D begin RPL
18CEA real\->system binary
03223 swap
18CEA real\->system binary
03223 swap
07E50 \->xlib
0312B end rpl
0312B end rpl
\->XLIB
%%HP: T(3)A(D)F(.);
"D9D20D8A812BF8199040D9D20AEC8132230AEC813223005E70B2130B213097F3"
XLIB\-> requires an XLIB argument, and is is the reversal of the above.
Arguments Results
4: 4:
3: 3:
2: 2: 240
1: XLIB 240 95 1: 95
XLIB\->
02D9D begin rpl
18AB2 need 1 argument
18FB2 check argument
04085 system binary <Fh>
02D9D begin rpl
08CCC xlib\->
18DBF system binary\->real
03223 swap
18DBF system binary\->real
03223 swap
0312B end rpl
0312B end rpl
XLIB\->
%%HP: T(1)A(D)F(.);
"D9D202BA812BF8158040D9D20CCC80FBD8132230FBD8132230B2130B21306983"
Although the previous two routines are quite useful, they are trivial
by comparison to the next. X\->R is an XLIB-to-RPL conversion scheme
where upon an XLIB argument is taken, and the RPL routine that would
normally be executed when the XLIB is evaluated is returned. So if it
were system RPL that resides in the hidden ROM, the level one result
would contain the unevaluated routine to which the XLIB calls. There
is no longer any need for guessing, simply use HEX\-> on the stack
object to examine it. Or use PRG\-> to unthread, and then HEX\-> to
acquire the individual addresses for the externals. The applications
here are quite obviously multiple.
Arguments Results
4: 1: External External
3: <2h> External
2: External External
1: External External
X\->R
02D9D begin rpl
18AB2 need 1 argument
18FB2 check argument
04085 system binary <Fh>
02D9D begin rpl
07E99 xlib\->rpl
61A3B return if true
05016 errn #004
0312B end rpl
0312B end rpl
X\->R
%%HP: T(1)A(D)F(.);
"D9D202BA812BF8158040D9D2099E70B3A1661050B2130B2130470B"
Lastly, is the above routine's reverse scheme, as this is exactly how
it functions. It takes the above result as an argument and returns as
its result the argument with which we started.
Arguments Results
1: External External 4:
<2h> External 3:
External External 2:
External External 1: XLIB 240 95
R\->X
02D9D begin rpl
18AB2 need 1 argument
18FB2 check argument
0403F system binary <8h>
02D9D begin rpl
07E76 rpl\->xlib
07E99 xlib\->rpl
0712A jump next call/object if true
11056 errn #12D
07E76 rpl\->xlib
0312B end rpl
0312B end rpl
R\->X
%%HP: T(1)A(D)F(.);
"D9D202BA812BF81F3040D9D2067E7099E70A21706501167E70B2130B2130D796"
Some final notes. The information which appears here in regards to the
four prefixed machine routines #07E50h, #08CCCh, #07E99h, and #07E76h,
is the result of my own experimentation, and in no way came from HP. I
would also recommend disassembling #07E99h for further study to those
interested in how the 48 accesses the hidden ROM. Good luck.
Rick Grevelle
[Note: If you have the HACKIT library in your HP 48, you do not need
the first three routines by Rick. Use the following instead:
Rick's -->HACKIT's
----------------
->XLIB->XLIB
XLIB->OUT->
X->RRCLIB
HACKIT's functions each have more functionality too. ->XLIB accepts
real or binary integer arguments. OUT-> not only pulls apart XLIBs
but also arrays of string (or of any other kind), lists, programs,
and algebraics. And RCLIB not only extracts single XLIB commands
from their libraries, but if given a real number or global name as
its argument, will recall the entire library as a directory.
-jkh-]akcs.jrchaffer@hpcvbbs.UUCP (J. Richard Chaffer) (05/17/91)
Joe _
I got it. Thanx a bunch. Will have to get Goodies III too!
- jrc