Prev: Hacked ROM emulator HP49G
Next: HP50g fast parser plotting and numerical integrasjon , request for betatesters
From: Gurveer on 16 Feb 2010 21:34
>> The HP49G/50G series internal library contains more functions,
>> and renumbered some of the original HP48G internal functions,
>> hence you may need a "library function browser" (easy to make)
>> to discover the correspondence
>> between the old function numbers and the new ones :)

As John said exactly one year ago, what is a library function browser?

Regards,

Gurveer
From: Andreas Möller on 17 Feb 2010 02:14
Hello,

> similar documentation about the ROMPTRs associated with the BRbrowse
BRbrowse is documented in "Programming in SYS-RPL" IIRC.

Regards,
Andreas
http://www.software49g.gmxhome.de
From: Gurveer on 17 Feb 2010 16:22
On Feb 17, 12:14 am, Andreas Möller <andreas_moellerNOS...(a)gmx.de>
wrote:
> Hello,
>
> > similar documentation about the ROMPTRs associated with the BRbrowse
>
> BRbrowse is documented in "Programming in SYS-RPL" IIRC.
>
> Regards,
> Andreashttp://www.software49g.gmxhome.de

Yeah, I looked into that manual. He describes the commands used but
not exactly which PTR corresponds to which ROMPTR of the library 224.
Anyways, I looked at your code and worked around the same way as John
said to find the corresponding ROM pointer and I think ultimately I
figured it out and this is what I believe it is:


::
CLCD10
UnLockAlpha
' ROMPTR E0 15 ROMPTR@ DROP FPTR 3 0
FPTR 3 A5
FPTR 3 A6
ClrDAsOK
' ::
' ROMPTR E0 12 ROMPTR@ DROP FPTR 3 0
;
' ::
' ROMPTR E0 26 ROMPTR@ DROP FPTR 3 0
;
TrueTrue
5ROLL
ONEFALSE'
LAM 'BR20
'ERRJMP
' POLSetUI FPTR 3 0
' POLKeyUI FPTR 3 0
ABND
ClrDAsOK
;
@


Looked into Nosy and found that it's using Flash Page 3 as ROMPTR2
~BRbrowse is essentially FPTR 3 4.

Anyways, thanks a lot guys. It really helped me solve a big problem(at
least big for me:-)

Regards,

Gurveer
From: Andreas Möller on 17 Feb 2010 16:49
Hello,

you might be able to speed up your program at the expense of your
program size by ripping the corresponding FLASHPTR/ROMPTR out of the
ROM instead of recalling it from the ROM everytime it is called/
executed.

For example:
' ::
' ROMPTR E0 12 ROMPTR@ DROP FPTR 3 0
;
This is really slow because a secondary is placed on the stack which
is used by the POL, now everytime the POL executes this the ROMPTR is
copied to TEMPOB and executed from there with the EVAL from Flash Bank
3.

Your code would run a lot faster if you would use something like this:
' ::
Code from ROMPTR E0 12
FPTR 3 0
;

However, it might be a little bit tricky to write the code that
creates the above program at runtime and the drawback is that your
program will most likely be bigger and will also need more RAM to run.

Also note that you can extract the code of a ROMPTR/FLASHPTR with NOSY
by pressing the [STO] button and also Keyman (from Wolfgang
Rautenberg) contains an option/code to extract a FLASHPTR. I use a
standalone code from Keyman in some of my programs to extract the
content of FLASHPTRs at runtime, modify them and then run my modified
program. The delay at start up is almost of no consequence compared to
the gain of speed at runtime of the POL.

Hope my explanations makes sense to you.

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




From: Gurveer on 17 Feb 2010 18:32
On Feb 17, 2:49 pm, Andreas Möller <andreas_moellerNOS...(a)gmx.de>
wrote:
> Hello,
>
> you might be able to speed up your program at the expense of your
> program size by ripping the corresponding FLASHPTR/ROMPTR out of the
> ROM instead of recalling it from the ROM everytime it is called/
> executed.
>
> For example:
>   ' ::
>     ' ROMPTR E0 12  ROMPTR@ DROP FPTR 3 0
>   ;
> This is really slow because a secondary is placed on the stack which
> is used by the POL, now everytime the POL executes this the ROMPTR is
> copied to TEMPOB and executed from there with the EVAL from Flash Bank
> 3.
>
> Your code would run a lot faster if you would use something like this:
> ' ::
>     Code from ROMPTR E0 12
>     FPTR 3 0
>   ;
>
> However, it might be a little bit tricky to write the code that
> creates the above program at runtime and the drawback is that your
> program will most likely be bigger and will also need more RAM to run.
>
> Also note that you can extract the code of a ROMPTR/FLASHPTR with NOSY
> by pressing the [STO] button and also Keyman (from Wolfgang
> Rautenberg) contains an option/code to extract a FLASHPTR. I use a
> standalone code from Keyman in some of my programs to extract the
> content of FLASHPTRs at runtime, modify them and then run my modified
> program. The delay at start up is almost of no consequence compared to
> the gain of speed at runtime of the POL.
>
> Hope my explanations makes sense to you.
>
> Regards,
> Andreashttp://www.software49g.gmxhome.de

I understand what you said but just a basic question which I kept
trying figuring out. When you say that FLASHPTR is recalled in the
runtime, isn't this what was happening before as ROMPTR@ was recalling
the ROMPTR? I'm kinda an amateur at this stuff and I try to get it.
So, what about that code, is this what you meant:

Instead of

' ::
' ROMPTR E0 12 ROMPTR@ DROP FPTR 3 0
;


Should I have

::
' ::
DA3OK?
?SKIP
::
DispMenu
SetDA3Valid
;
FPTR 3 0
;
;

for all those ROMPTRs which are evaluated at the Flash Page 3 in my
code?

Because what I understood from your code was that ROMPTR@ was
recalling the ROMPTR in the runtime.

Or is the speed has to do something with the FPTR?

Thanks for the Nosy trick BTW, I used the COPY shortcut earlier.

And yeah, I should better look at Keyman now, had heard about it but
never used it. Looks like a good tool to speed up programming...:-)

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