Prev: Hacked ROM emulator HP49G
Next: HP50g fast parser plotting and numerical integrasjon , request for betatesters
From: Gurveer on 17 Feb 2010 19:10
Just noted a weird behavior which I didn't know about, but you guys
probably did, I believe, is that if you use the SPC (Space) key, it
would scroll only to the non-null string items which is exactly what I
wanted for the down arrow key action. Is there a way to assign a key
handler onto a different without creating the code by oneself or even
if I can get to know what are the default hardkey assignments?

Regards,

Gurveer
From: Andreas Möller on 17 Feb 2010 19:39
Hello,

please note that I am writing this from memory so it may not be a 100%
accurate all the time ;-)

There are some fundamentals missing on your side. Please search this
newsgroup for FLASHPTR and memory layout of the 49G.

A FLASHPTR is not a ROMPTR, these are different object types, details
about can be found in "Introduction to Saturn Assembly Language" which
is available at hpcalc.org.

The main difference is, that a ROMPTR is fetched from memory (if in
covered memory), than copied to TEMPOB and finally executed from
there. This is kind of slow.

A FLASHPTR reconfigures the memory layout, swapping in the appropriate
Flash Bank and then executes a PTR directly from this bank and
afterward restores the memory layout. This is faster than executing a
ROMPTR.

All the PTRs that have a name (like ?SKIP, DispMenu, etc. ) reside at
a memory address below 40000h and these addresses are always visible.
The upper memory (40001h - 80000h) is exchanged when a FLASHPTR is
called, that is the reason why a PTR from Flash Bank 6 (just an
example) is not working in the standard memory layout as in this case
the Flash Bank 2 is active.

So the trick is to have the content of the ROMPTR already in TEMPOB
avoiding the recurring copying of its content by the POL *but* the
ROMPTR may contain PTRs (unnamed addresses) of the Flash Bank the
ROMPTR resides in and that is the reason why you have to use FLASHPTR
x 0 to ensure that the correct bank for these PTRs is swapped in.

In the particular example of
> ' ::
> DA3OK?
> ?SKIP
> ::
> DispMenu
> SetDA3Valid
> ;
it should not matter as all this commands reside in Flash Bank 2.

Note however, that some constructs exists more than once, for example
:: and ; also reside in each Flash Bank (IIRC) as they are very small
PCOs (a low level object type) to avoid unnecessary swapping while the
particular bank is active.

The advantage of having the content of a FLASHPTR would be the saving
of the time needed to configure the Flash Banks, however the gain is
not as big as in the ROMPTR case.

The whole might be a little bit confusing at first, but this is due to
the limited memory the Saturn CPU can access (and therefore bank
switching is needed) and an advantage would be to know which built-in
functions reside in which Flash Banks. I know that this is documented
somewhere in this newsgroup as I have a copy of this post somewhere on
my hard disk, but I can not find it right at the moment.

> I'm kinda an amateur at this stuff and I try to get it.
I wouldn’t call myself a professional as I am still discovering new
tricks about accessing the ROM and it is quite astounding what you can
do with this machine ;-)

> So, what about that code, is this what you meant:
>Instead of
>
> ' ::
> ' ROMPTR E0 12 ROMPTR@ DROP FPTR 3 0
> ;
No, I meant something like this for the arguments that the POL takes
from the stack:
At runtime you built the needed argument at the very beginning, than
the POL will use your constructed secondary.

' ' ( put ' on the RPL-Data-Stack )
' ROMPTR E0 12 ROMPTR@ DROP
( fetch the ROMPTR and copy its content to TEMPOB, the object in
TEMPOB )
( is referenced and a PTR to this is on the RPL-Data-Stack )
( Note that the ROMPTR may contain calls to the same Flash Bank )
( or into another Flash Banks and that the ROMPTR may need a
specific )
( configuration of the Flash Banks )
' FLASHPTR 3 0 ( put EVAL for the Flash Bank on the RPL-Data-Stack )

( in this example now three objects are on the stack )
3: '
2: PTR_to_TEMPOB_which_is_the_content_of_ROMPTR_E0_12
1: FLASHPTR 3 0

Now construct you secondary at runtime.
BINT3 ::N ( built a secondary from it, this is the result: )
:: ' PTR_to_TEMPOB_which_is_the_content_of_ROMPTR_E0_12 FLASHPTR 3 0 ;

Now what happens when this secondary is called from the POL:
PTR_to_TEMPOB_which_is_the_content_of_ROMPTR_E0_12 is placed on the
stack and FLASHPTR 3 0 evaluates it in the correct Flash Banks, so
that each subroutine which might be called by
PTR_to_TEMPOB_which_is_the_content_of_ROMPTR_E0_12 is executed with
the correct memory configuration.

Note again, that there this is a little slow down at start of your
program and that a program like this requires more RAM. The benefit is
faster execution time so you have to judge by yourself where you want
speed against size ;-)

Hope this makes sense to you (as English is not my native language).

Regards,
Andreas
http://www.software49g.gmxhome.de

P.S. There are a lot of advanced techniques that can be used to speed
up programs, especially in avoiding continues usage of ROMPTRs, you
can reserve memory for them so that they reside in RAM during your
program and you can even use some reserved memory areas (the different
screens) for speeding up time critical routines, but this is currently
out of your knowledge.


From: Andreas Möller on 17 Feb 2010 19:44
Hello,

> Is there a way to assign a key
> handler onto a different without creating the code by oneself or even
> if I can get to know what are the default hardkey assignments?

IIRC no, you can not customize the keys of BRbrowse or Choose.
If you want customized keys here you have to provide a standard hard
key handler as demanded by a POL and replace the hard key handler of
BRbrowse or Choose with it.

HTH,
Andreas
http://www.software49g.gmxhome.de


From: Andreas Möller on 17 Feb 2010 19:46

> if I can get to know what are the default hardkey assignments?
They should be documented somewhere or else I have to dig them out ;-)

Regards,
Andreas
http://www.software49g.gmxhome.de
From: Gurveer on 18 Feb 2010 20:59
Wow, this is pretty cool explanation and I checked out that Saturn ASM
manual. It kinda describes in detail and I think I need more time to
work around this. Thanks a lot!

Sorry, just a little quick question about the BRbrowse:-)

I could fix those arrow key actions for the Choose engine because I
got to know that I had to control NULLLAMs 6 & 18 to change the
highlighted item but for BRbrowse, due to lack of documentation I was
unable to determine if there were any Nulllams being used. To move to
desired location, I would store LAM 'BR3 to the specified row
number(from ROMPTR E0 18) but the problem lies here, it would not
refresh the display. The highlighted row is still the same old one but
it executes the program based on newer selection, strange!

> They should be documented somewhere or else I have to dig them out ;-)

I tried looking for them but haven't found them yet, gotta dig
more...:-)

Thanks a lot anyways. You were of great help!

Whole-heartedly regards,

Gurveer
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Hacked ROM emulator HP49G
Next: HP50g fast parser plotting and numerical integrasjon , request for betatesters