[comp.sys.handhelds] Display question

TNAN0@CCVAX.IASTATE.EDU (02/01/91)

I have a question that I put forward every once in awhile in hopes that
SOMEONE can answer it correctly...  Please listen carefully...

The HP-48sx display is memory mapped, but it is NOT fixed.  The various
parts of the display (stack area and menu label area) can be moved
independantly of each other (by poking around near address 100h - I
believe that it's 120h-124h actually for the upper portion of the screen
and 130h-134h for the lower).  Anyway, my question is:  Where does the
HP keep track of the current addresses associated with the position of the
screen (120h-124h and 130h-134h provide no useful information, they are
write-only).  The screen memory itself it laid out like two GROBs, so I
assume that there are two 'GROB pointers' somewhere in memory... Where are
these?  I assume that the author of Chip must know since this was what
caused him problems in the first version of Chip with screen offset.  Please
post this information if you feel that you know.

Hint:  The answer is NOT 70890, 709BC, or any other location that the
screen has been found at...  I am looking for the storage area that holds
the address of the screen...

Thanks...

---Xeno

bgribble@jarthur.Claremont.EDU (Bill Gribble) (02/02/91)

In article <C73C31B198BF60A165@ISUVAX.BITNET> TNAN0@CCVAX.IASTATE.EDU writes:

>The HP-48sx display is memory mapped, but it is NOT fixed.  The various
>parts of the display (stack area and menu label area) can be moved
>independantly of each other (by poking around near address 100h - I
>believe that it's 120h-124h actually for the upper portion of the screen
>and 130h-134h for the lower).  Anyway, my question is:  Where does the
>HP keep track of the current addresses associated with the position of the
>screen (120h-124h and 130h-134h provide no useful information, they are
>write-only).

From a list of useful RAM addresses: 

        loc_menugrob=#70551
        loc_stackgrob=#70556

  these locations contain pointers to the grobs you're talking about. So
  the code bit 

        move.p5  loc_stackgrob,a
        move.a   a,d0
        move.a   @d0,a
        swap.a   a,d0
        add.a    #a,d0
        add.a    #a,d0

  will leave d0 pointing to the start of stack grob data.

You can't change the pointers, but you can follow them and modify the existing
  grobs with impunity. (You're betatesting NRTS, aren't you?  Then you've
  seen this in action!)

>---Xeno

*****************************************************************************
**   Bill Gribble                     Harvey Mudd College, Claremont, CA   **
**   bgribble@jarthur.claremont.edu   Never heard of it?  You're stupid.   **
*****************************************************************************