n233dk@tamuts.tamu.edu (Rick Grevelle) (01/30/91)
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. An unthreaded command such as 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 to other system RPL routines; because RPL can't call to any of the entry points in "hidden" ROM by simply placing the address of the desired routine in the RPL instruction stream. Accessing entry points in "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 base 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 \->XL begin rpl 02D9D begin RPL 18A8D need 2 arguments 18FB2 check arguments 04099 system binary <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 aquire the individuals addresses for the externals. The applications here are quite obvioulsy mulitple. 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; all of this was entered rather hastyly by me, and by hand. While I did take the time to double check the \->ASC encoded strings, there still could be errors. In which case corrections will be made as quickly as possible. 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 covered ROM. Good luck. Rick Grevelle