HP 48 Series -- interseries compatibility?

[johnb]

Hey, sorry for the long period between updates!

I had the anime convention, then on my return, I've ditched a former role at my employer and assumed two new roles otherwise, which have required a HUGE learning curve. That and some other real-world complications have kept me "more than busy."

#0 [preface, off-topic] - for those of you who are interested, my panel at Anime Weekend Atlanta was a HUGE success! I am totally astonished and truly blessed. WE FILLED THE 500 SEAT BALLROOM, and they *still* had to turn people away. Apparently, LOTS of anime fans like science. Among the 500, I had one chemist, one physicist, an epidemiologist, a biologist, one other scientist, and one fellow former-Navy submarine nuc propulsion operator! I had plenty of fun audience interaction. The HP-41CX scene again got guffaws and "oh WOW!" from some of the engineers, and me subsequently holding up my own 41 again got peals of laughter from pretty much everyone.

I guess the only thing we have to fear is, fear itself?


#1 [back on topic] - today I tried my proposed shortcut of completely clearing the memory of the 48s, then installing John Meyers' routines first (via cable) to get 48g list processing, then installing my own routines via IR. Bob Prosperi, you were correct, this didn't work. If I open any of my broken routines, I see the XLIB references.

#2 - My personal library has a LOT more functions that I remembered, so it behooves me to be a world-class developer by being lazy and larcenous-at-heart... I've recently backed up my 48g to my PC -- 3 different ways: full backup, binary copies of individual objects, and ASCII copies. I'm noting that the ASCII copies have the real function names where the XLIB references appear in my 48s. So my next attempt at "skirting the rules" will be to use the connectivity kit to try loading a few of those ASCII copies to the 48s and see where that gets me.

#3 - However, if I were a betting man, the safe money is that Bob is still right, I am still wrong, and I will have to manually edit every single darn one of those broken subroutines, LOL.

#4 - I just remembered, I never posted a photo of my acquisition. My phone's camera hasn't done it justice, it literally looks brand new...

   

[Werner]

You might want to give my GX library a try, that I wrote in another lifetime..
and, if you use SORT a lot, LSORT may come in handy, an almost 100% compatible SORT program, but way, way faster.

Cheers, Werner

[johnb]

(11-24-2023 06:20 AM)Werner Wrote:  You might want to give my GX library a try, that I wrote in another lifetime..
and, if you use SORT a lot, LSORT may come in handy, an almost 100% compatible SORT program, but way, way faster.

Cheers, Werner

Thanks, Werner!

What are some of the differences between you GX library and John Meyers' "LIST" routines? Are there things his has that yours does not, or is yours a proper superset? (I'm trying for completeness, hopefully to save myselfe some effort.)

Further News...

Buwahahaha! I have figured out the trick to getting RPL to recompile without my having to do fixups! For the benefit of others, the full procedure I followed is here below.

To copy programs from a G/GX to an S/SX:

1. Back up your S/SX. Several different ways, preferably.
2. Reset your S/SX to factory default. Not strictly necessary, but prevents the hassle of having to do a lot of renaming of objects and such. I like starting from a clean slate.
3. Using the connectivity kit, load the librar(y/ies) that you will be using to add any missing GX functions to your S/SX.
4. At this point, you either need to copy/move those routines from any subdirectories down to HOME so that every other routine can use those objects. Alternatively, you'll need to reorganize your directory structures so that your own directories are children of the parent directory containing the supplemental librar(y/ies).
5. Connect your cable to your G/GX. Set both calculator and connectivity kit / port to ASCII. Back up all the objects you want to transfer, each one to an individual file. The only shortcut I can offer is that you can back up an entire subdirectory tree, starting at the root, to a single file. (For example, if you have HOME/CS, HOME/CS/WK1, HOME/CS/WK2, and HOME/CS/WK2/OTHER, you can simply back up the entirety of CS from the root directory to a single "CS" file and you will get all of it.)
6. Ensure the integrity of your backup.
7. Swap the cable over to your S/SX. Set both calculator and connectivity kit / port to ASCII.
8. Using the connectivity kit, copy the ASCII files over to the S/SX. You can do this in a batch, as order of transmission seems to not matter.
9. Give the calculator a few moments to gather its wits while you gather yours.
10. Do some spot checks, but there should be no stray XLIB nnnn entries in any of your programs!
11. If there are other things you need from your earlier backup of your S/SX, restore them.
12. Enjoy! (If you haven't completely covered all the missing commands, you will still get errors but you are presumably now a lot closer than you were previously!)
    

[johnb]

(11-24-2023 06:20 AM)Werner Wrote:  You might want to give my GX library a try, that I wrote in another lifetime..

Werner:

It appears to me your library truly is a proper superset of John Meyers' set of LIST routines.

But I'm having trouble using it. The HP Connectivity Kit wants the calculator running in Server Mode, so the little loader program you specified won't work.

I've copied GX.lib into HOME and figured out how to load it to Port-0, but attaching it to HOME doesn't appear to be working for some reason. I can go to LIBRARY and then to GX and use the routines directly, but after I (attempt to?) attach it to HOME, and then load other routines that use these functions, the other routines seem to be tripping all over themselves... and they worked correctly with the Meyers functions. Is that because his routines are purely UserRPL and yours are SYSRPL and embedded in a library? (I would have thought the latter preferable to the former.)

Just wondering what I'm doing wrong.

[Werner]

(11-26-2023 11:44 PM)johnb Wrote:  I can go to LIBRARY and then to GX and use the routines directly

Yes, it's a library, so that is the way you use them. I'm not entirely sure what you mean by 'attaching to HOME'.

Cheers, Werner

[DavidM]

(11-26-2023 11:44 PM)johnb Wrote:  ...I can go to LIBRARY and then to GX and use the routines directly, but after I (attempt to?) attach it to HOME, and then load other routines that use these functions, the other routines seem to be tripping all over themselves... and they worked correctly with the Meyers functions.

Are the "other routines" you refer to being restored onto the calculator as binary objects? There could be a subtlety here that is creating this confusing scenario.

First, bear in mind that numbers, programs, lists, arrays, etc. are always stored as compiled objects on your calculator (unless you specifically enclose the commands in "..." quotes). The calculator goes out of its way to hide this fact from you. It allows you to edit a program containing the command DOSUBS as if it were simply a string of characters. But as soon as you are done editing, the calculator compiles that reference into one of four things: a local variable name, a global variable name, a built-in command, or a library reference. Which option it chooses depends on the context (is a local variable already defined with that name?), the model (what built-in commands are available?), and the configuration (is there an attached library with a command of that name?).

If the programs in question contain something like DOSUBS as a global variable reference, then they will need to be re-edited and saved after installing Werner's library in order to convert the reference to a library call instead.

This is, admittedly, a subtle and highly-specific issue that would only come up when attempting to move RPL programs from one platform to another when restoring from binary objects. But I believe that may be exactly what you are doing here.

[johnb]

(11-27-2023 11:17 AM)DavidM Wrote:  

(11-26-2023 11:44 PM)johnb Wrote:  ...I can go to LIBRARY and then to GX and use the routines directly, but after I (attempt to?) attach it to HOME, and then load other routines that use these functions, the other routines seem to be tripping all over themselves... and they worked correctly with the Meyers functions.

Are the "other routines" you refer to being restored onto the calculator as binary objects? There could be a subtlety here that is creating this confusing scenario.

First, bear in mind that numbers, programs, lists, arrays, etc. are always stored as compiled objects on your calculator (unless you specifically enclose the commands in "..." quotes). The calculator goes out of its way to hide this fact from you. [...more elided...]

This was EXACTLY the information I needed, thanks!

Actually, the "other routines" are my own routines, written in UserRPL on the 48g, saved as ASCII, then downloaded onto the 48s, also as ASCII. But the library is binary!

BTW, this is something I have trouble explaining to nontechnical people when troubleshooting minor technical issues: the more adequately accurate and detailed your mental model is of what is going on behind the scenes, the easier it is to have a go at it! Clearly, my mental model has some gaps and in some places is just plain wrong.

The surprising thing was learning when the calculator chooses to compile program objects and fix up references. Apparently, if the "bottommost" routines are loaded as ASCII objects (such as Meyers' UserRPL implementations of some of the GX-only LIST routines for the SX), when you load your own UserRPL objects (also as ASCII), it does a text-based lookup when it doesn't recognize a program name as a built-in. It does this on every run, so it's a little slower than it could be.

But, in this new case, the "bottommost" routines were loaded as binary objects in a library... then stored to Port-0 (the only port for me, this is a 48s, not an SX). Then, even though my own routines were loaded on top as ASCII objects just as before, the loading process did NOT cause a compilation of the code -- as I'd previously thought would happen.

I did a little reading in Wickes' book, and saw that for binary libraries, the compilation process replaces the name of the subroutine with a pointer to the library routines and/or built-in routines. This is why calls to binary libraries run faster: no lookups at runtime.

The simple fix-up for me was a bit tedious but quick enough. Just go through each of my directories off HOME (including it), and one-by-one, recall a program onto the stack, recall its name onto the stack, then STO. Voilá! Recompiled!