Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!rnews!hpcvbbs!akcs.dnickel
From: akcs.dnickel@hpcvbbs.UUCP (Derek S. Nickel)
Newsgroups: comp.sys.handhelds
Subject: Re: Some HP-48 Internals Answers
Message-ID: <27d099e0:2282.1comp.sys.handhelds;1@hpcvbbs.UUCP>
Date: 3 Mar 91 06:40:04 GMT
References: <13605@life.ai.mit.edu>
Lines: 36

Jan Brittenson writes:

>posted it to the net). I hope I am correct - I'm sure I will quickly
>be corrected if I'm not!

You also made a comment anout "very weak ice"...

The value 028FC is a "prolog signature", not an address of some code.
Try unassembling (not unthreading) at, for example, 02911 and you will
see that the fist two instructions (D=D-1 and some HST stuff) are
"unusual", if fact the HST stuff is a NOP.  But those first five nibbles
are used by other parts of the OS to identify a prolog object.

Is this clear (I fear its not).  My point is that 028FC is not an address
but actual machine code.  (unassembling at address 028FC only leads to
madness - trust me - I tried it before I realized what was going on).

Another point:  these prolog addresses (like 02D9D) are just like
prefixed machine code, only the "prefix" is far removed from the routine
that it is prefixing, but the data is close at hand (data follows the
prolog prefix).

exam[;es

examples:

02D9D program prolog (machine code at 02D9D)
   program data
0312bB End Marker...

(ugh! this example is getting out of hand - maybe later)

My most recent "HP 48SX Internals" manual covers this stuff with an
example.

        Derek S. Nickel
,