HP 48GX hpcalc.org Program Name

[MNH]

I'm looking for, but don't remember the name of, the program at hpcalc.org that lets you see what's going on under the hood of all of the HP 48GX User-RPL commands. Can someone help me out please? Currently, I'm interested in the →LIST command. It seems to be rather slow, and I'm only working with 4 strings. What if I'm working with 200 strings?

[Dave Britten]

I believe Nosy might be the program you're thinking of.

[MNH]

(05-02-2021 11:29 PM)Dave Britten Wrote:  I believe Nosy might be the program you're thinking of.

That's it! Thanks!

[Giuseppe Donnini]

You should be careful here! Nosy is for the HP 49G and will not work on the HP 48GX. If you want to unravel the ROM code of the latter machine, you have the following options:

If you prefer to work on the calculator itself, you can either use RPL48 by Raymond Del Tondo and Detlef Müller or Jazz by Mika Heiskanen.

If you prefer to work on a computer, you can try Voyager by Derek S. Nickel, which is DOS-based, or SAD by Jan Brittenson, which runs on Unix/Linux systems.

There are a few other decompilers/disassemblers out there, but these are the best.

That being said, I would begin by optimizing my own code rather than trying to modify the internals of the HP-48GX. The lack of speed you are experiencing is almost certainly unrelated to the implementation of the \->LIST command. It usually takes less than a second to build a list of 200 fairly long strings (500 characters each).

Furthermore, if you plan to modify time-critical ROM code, it is usually not sufficient to have a good working knowledge of System RPL, you have to be proficient in Saturn assembly as well. For instance, here is the decompiled \->LIST command:


HP-48GX[M]: rpl x>LIST

1C783          LABEL x>LIST (Also Resolution of ROMPTR 002 098)
1C783 D9D20    ::      ( ob1 ... obn %n --> { ob1 ... obn } )
1C788 43C81      CKN   ( *Check presence of %n arguments, convert %n to #n* )
1C78D 95450      {}N   ( *Create list composed of specified number of objects* )
1C792 B2130    ;


HP-48GX[M]: rpl {}N

05459          LABEL {}N
05459 D9D20    ::           ( ob1 ... obn #n --> { ob1 ... obn } )
0545E F9F30      TYPELIST   ( *Specify composite sub-type should be a list* )
05463 13350      COMPN      ( *Build composite object of specified sub-type from #n objects* )
05468 B2130    ;


And that is as far as you get with System RPL, because COMPN is implemented in machine code.

If you show us exactly what kind of problems you experience and how you tried to tackle them, we could perhaps help you more efficiently.

[MNH]

(05-03-2021 12:42 PM)Giuseppe Donnini Wrote:  If you show us exactly what kind of problems you experience and how you tried to tackle them, we could perhaps help you more efficiently.

Program: FIN, 240.5 bytes, # 6054h checksum, removes line feed characters from a CSV file.
FILE: list containing 1 integer (size of list) and 4 empty strings.
CSV: Comma-Spaced Values file with line feed characters.

\<< FILE 1 GET CSV
DUP SIZE 10 CHR 1 \->
numpoints csv size
char start
\<< MEM DROP 1
numpoints
START csv start
size SUB DUP char
POS DUP 0 >
\<< DUP 'start'
STO+ 2 - 1 SWAP SUB
\>> IFT
NEXT DROP
numpoints \->LIST
\>>
\>>

I think MEM is slowing down program execution. I was going to use more stack commands and less local variables, but I think I'm using a logical mix of both. I apologize for no indentation. No time to retype.

[rprosperi]

(05-04-2021 01:02 AM)MNH Wrote:  I think MEM is slowing down program execution. I was going to use more stack commands and less local variables, but I think I'm using a logical mix of both. I apologize for no indentation. No time to retype.

MEM does garbage collection so it is indeed very slow.

Why do you think you need this inside the loop in your program?

[MNH]

(05-04-2021 01:44 AM)rprosperi Wrote:  MEM does garbage collection so it is indeed very slow.

Why do you think you need this inside the loop in your program?

In case I have a large amount of strings to process. Clearing used pointers from memory will allow a program to run faster.

[rprosperi]

(05-05-2021 01:10 AM)MNH Wrote:  

(05-04-2021 01:44 AM)rprosperi Wrote:  MEM does garbage collection so it is indeed very slow.

Why do you think you need this inside the loop in your program?

In case I have a large amount of strings to process. Clearing used pointers from memory will allow a program to run faster.

It's a trade-off. Execution of MEM adds time, while the effect of running it may speed things up. Try it with and without MEM DROP included, it's easy to make this change.

[RMollov]

The strategy of keeping coordinates as strings is proven no good. Better one is keeping one list of strings (descriptions) and another with coordinates as 3D vectors or replace the latter with a matrix. (In case of points having identifiers as alphanumeric strings, add another list of them.) All lists (or rows if matrix) have the same length and index gives connection. (You'll be able to quickly search in list of strings, or just use matrix or list index for point number.) Such separation is easy done on a computer by text editor like Notepad++ for example.

How do you create the CSV file? Is it produced by a total station directly in the calculator or sent through COM port? What are you trying to acheive with that program?

Regards,

[MNH]

(05-05-2021 04:01 AM)RMollov Wrote:  Better one is keeping one list of strings (descriptions) and another with coordinates as 3D vectors or replace the latter with a matrix.

I agree, although I've never used matrices in any HP language.

Quote:How do you create the CSV file? Is it produced by a total station directly in the calculator or sent through COM port? What are you trying to acheive with that program?

The Topcon FC-5000 tablet computer (Windows 10) survey software (Topcon MAGNET Field) creates a CSV file of points in the form of "Point #, Northing, Easting, Elevation, Description."
I can load that file (object) into my Emu48 (Android). My program removes the line feed characters and stores the new strings into a list for use in a COGO program. I have not written a program to store/recall/edit/delete points. I have not written a COGO program either.