The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

converting stored HP-48SX programs to run on HP-50g
Message #1 Posted by Grant Nixon on 4 Nov 2007, 7:31 p.m.

Dear forum users:

I would like to convert my archived HP-48SX RPL files/diretories such that I can store them on the HP-50g. So, my problem is two-fold: (1) I must extract variables from the HP-48 binary format and (2), I must find a way to convert them such that I can download and run them on my new 50g.

While I am sure that this was posted at some previous time, I was unsuccessful in finding related posts and I would appreciate any help you may offer. Thank you.

Best regards,

Grant

      
Re: converting stored HP-48SX programs to run on HP-50g
Message #2 Posted by James M. Prange (Michigan) on 6 Nov 2007, 4:56 a.m.,
in response to message #1 by Grant Nixon

Are these UserRPL objects?

Do you have a 48 series (48SX, 48S, 48GX, 48G, or 48G+) available?

Which operating system are you running on your computer?

I haven't run through the following procedures step-by-step, but I believe that they'll work.

Quote:
I would like to convert my archived HP-48SX RPL files/diretories such that I can store them on the HP-50g. So, my problem is two-fold:

(1) I must extract variables from the HP-48 binary format and

You need source code, as you'd get from a Kermit "ASCII" transfer. If the files are from binary transfers or the ARCHIVE command, then you'll need to decompile them to source code.

UserRPL objects can be decompiled on the calculator itself (of the series that compiled them in the first place, that is). Libraries and anything that contains SysRPL or assembly language code are more complicated to decompile, particularly for the 48 series. For now, I'll assume that your files are UserRPL.

If the SYSEVAL command is used in a program, then you should check for a changed entry point. The cross-reference files are useful for this.

Most 48 series UserRPL programs (recompiled from source code) will run just fine in a 49 series, but it's possible that a few commands may run differently, particularly if the 49 series' more complicated CAS gets involved.

If you have a 48 series available, then this could be as simple as downloading them to the 48 series, uploading them again using Kermit ASCII or Conn4x's "text" mode, and checking for any SYSEVAL sequences.

But if the files are large, then downloading and uploading again at 9600bps could take a lot of time, and you might not even have a 48 series available. Assuming that you're running a fairly recent version of MS Windows, I suggest using an emulator.

You could use Emu48, in which case you'd need to convert a 48 series ROM image to a ROM file that Emu48 can use. Various publicly released ROM versions for the 48 series are available at http://www.hpcalc.org/hp48/pc/emulators/.

Or you can install Debug4x, which includes a version of Emu48 together with the required ROM files and .KML scripts. If I recall correctly, it doesn't include the files to emulate a 48S series, but a 48G series should work just fine for these purposes. I suppose that if you really wanted to emulate a 48S series, you could add a .KML file for it (several should be available at hpcalc.org) and a 48S ROM file (converted from a ROM image).

Okay, assuming that you have a 48 series emulator working, import the binary-transferred file to it. To convert it to a source code string, I suggest installing the ASCII to Binary Converter (it also does binary to ASCII conversions) on the emulator. Be sure to use the ASCIIBIN.48 (not ASCIIBIN.49) file with the 48 series emulator. I suggest using translation mode 3, that is, execute 3 TRANSIO before using the translator. This should give you a source code string on the stack, which you can export to a plain text file.

Don't forget to check for SYSEVAL sequences. You can edit the source code file with any text editor (even MS Notepad will work). A "word processor" should also work, as long as you're careful to save the file as plain text.

Quote:
(2), I must find a way to convert them such that I can download and run them on my new 50g.
The "conversion" would be merely compiling the source code on a 49 series. But when downloading to the 49 series, you'll probably want to have it in approximate mode, so that any integer-valued "real numbers" from the 48 series will be compiled as reals, instead of being compiled as zints (exact integers), a new object type available on the 49 series.

You could use Conn4x to download the source code files to the 50g.

Or you could copy them to an MMC or SD card and transfer them from the card to the calculator. However, the calculator does only binary transfers with the card, so you'll get a source code string instead of a compiled object. I suggest using my ASCII on SD programs to convert between source code and compiled object, but ASCIIBIN.49 may work as well (or even better, for all that I know) for you.

Note that my ASCII on SD programs were written specifically for SD card transfers, and include SYSEVAL sequences that would very likely corrupt memory on a 48 series calculator or emulator. They should be used only on a 49 series calculator or emulator.

And of course, the final step would be trying out your programs on the 50g.

Post again if you have any questions or problems.

Regards,
James

Edited: 6 Nov 2007, 5:25 a.m.

      
Re: converting stored HP-48SX programs to run on HP-50g
Message #3 Posted by Grant Nixon on 7 Nov 2007, 11:50 a.m.,
in response to message #1 by Grant Nixon

Thank you very much for the very comprehensive response James. My HP-48SX bit the dust after a final/fatal fall and i was left with a host of backups of UserRPL programs (mostly backed-up as entire directories) made using binary transfer. Fortunately, there are no SYSEVAL sequences in my programs. I will try your method(s) tonight.

FYI and for my own curiosity's sake: I am running XP on my laptop but I have a DOS emulator (DOSBox) running on it that appears to work satisfactory. I had downloaded a DOS version of an ASCII to Binary converter for HP48 files and was able to convert the few stand-alone programs (that I had saved seperately from the directories) from binary programs to ASCII. These then appeared as "%%HP:T(1):="D9D...." type strings. I got stuck when trying to figure-out how to convert these into UserRPL source code strings. I had naively tried to use Conn4x to dump them onto my 50g - with the mere result that it looked exactly the same on the calculator (i.e. a mere string file that looked like "%%HP:T(1):="D9D...." ) on the calculator.

Was my biggest problem that the translate code was somehow set (by default?) to one (as per the setting during the original archiving process?) or was it that the binary to ASCII conversion needs to be performed on a HP48 emulator like emu48? Just curious.

Thanks again for the great support.

Grant

            
Re: converting stored HP-48SX programs to run on HP-50g
Message #4 Posted by James M. Prange (Michigan) on 7 Nov 2007, 7:43 p.m.,
in response to message #3 by Grant Nixon

Quote:
My HP-48SX bit the dust after a final/fatal fall
I'm sorry to read that. I hope that the 50g works out for you. You may want to look at the documentation for the 48G series for some changes that may not be well-documented for the 50g.
Quote:
and i was left with a host of backups of UserRPL programs (mostly backed-up as entire directories) made using binary transfer.
I notice this statement in ASCIIBIN.TXT:
Quote:
Unfortunately, this program sometimes fails on directories. I'm not entirely sure why it doesn't work (since it properly imports some directories) and don't have a solution at present. For these pesky directories, you'll still have to use ASCII Kermit to transfer the file with a cable.
That rather surprises me. I don't know why it should fail either, short of insufficient memory. Looking at their source code, they use the SysRPL command EDITDECOMP$ to decompile the object to a source code string, which, as far as I know, should decompile any pure UserRPL object, including any directory, and if a directory contained any non-UerRPL object, then a Kermit ASCII transfer should fail to properly decompile it as well.

Well, give it a try, and if you have any problem, then post again and we'll try to work around it.

By the way, for "importing" and "exporting" objects with Emu48, use the Edit menu's "Load Object..." and "Save Object...".

When you load ASCIIBIN.48 into Emu48, it will appear on the stack as something like: 

1: External  External
   External  <3d>
   External  <11d>
   External  <1d>
That's okay; it's just the calculator's way of displaying a SysRPL program that it doesn't "know" how to decompile properly. Just go ahead and STO it with the name of your choice.

Also note that Emu48's "Save Object..." saves the object as a binary-transferred file, so it has a 8-byte binary transfer header, "HPHP48-W", plus, in the case of a string, five more bytes for the prologue address and string length. My "ASCII on SD" program would ignore that, but for most transfer methods those first thirteen bytes may well need to be edited out with a text editor. I think it best to edit out everything before the "%%HP:"

Quote:
Fortunately, there are no SYSEVAL sequences in my programs.
Good; as long as you're certain, that saves you a bit of editing.
Quote:
I will try your method(s) tonight.
Let us know how it works out.
Quote:
FYI and for my own curiosity's sake: I am running XP on my laptop but I have a DOS emulator (DOSBox) running on it that appears to work satisfactory. I had downloaded a DOS version of an ASCII to Binary converter for HP48 files and was able to convert the few stand-alone programs (that I had saved seperately from the directories) from binary programs to ASCII.
That's interesting; I wasn't aware of any such ASCII to binary converter for DOS, although certainly it should be possible (although a lot of work) to develop one.
Quote:
"%%HP:T(1):="D9D...." type strings. I got stuck when trying to figure-out how to convert these into UserRPL source code strings. I had naively tried to use Conn4x to dump them onto my 50g - with the mere result that it looked exactly the same on the calculator (i.e. a mere string file that looked like "%%HP:T(1):="D9D...." ) on the calculator.
It appears that something went wrong with (at least) generating the ASCII transfer header. If the calculator receives data that doesn't contain a valid (for the model) binary or ASCII transfer header, then it safely stores the entire data stream as a character string, rather than attempting to compile it to an object or (much worse) store it as an object.

A Kermit ASCII or Conn4x "text" mode transferred file will have a transfer header similar to: 

%%HP: T(3)A(D)(F(.);
The value for T() can be 0, 1, 2, or 3. This tells the calculator which translation mode should be used when receiving the file.

The value for A() can be D, R, or G. This tells the calculator which angular units mode should be in effect when compiling the source code, for the sake of complex numbers and vectors with an angular component.

The value for F() can be either a period or a comma. This tells the calculator which "Fraction mark" mode should be in effect when compiling the source code.

When writing your own source code files on a PC, you can put the parameters in any order. For example, 

%%HP: A(D)F(.)T(3);
works as well.

Also, parameters can be left out of the ASCII transfer header, in which case the receiving calculator's current mode is used. A minimal ASCII transfer header would be: 

%%HP: ;
In this case, the header tells the calculator to to treat it as a source code file (attempt to compile it), use whichever translation mode is currently in IOPAR (or create a default IOPAR if it isn't found), and use whichever angular units and fraction mark modes are currently in effect.

The 49 series (49G, 49gII, 49g+, and 50g) use the same ASCII transfer header as the 48 series, although of course the binary transfer header differs.

Unfortunately, the ASCII transfer header doesn't include any information as to whether the 49 series should be in exact or approximate mode when compiling the source code. Some reasonable rules of thumb would be: If the file originated from (or was written for) a 48 series, then have the 49 series in approximate mode when downloading it (unless you want all reals without a fraction mark to be compiled as zints). For 49 series objects, have the 49 series in exact mode when uploading or downloading (unless you want all zints to be changed to reals).

Quote:
Was my biggest problem that the translate code was somehow set (by default?) to one (as per the setting during the original archiving process?) or was it that the binary to ASCII conversion needs to be performed on a HP48 emulator like emu48? Just curious.
Binary transferred files don't include (or have any use for) the translation mode; they're very simply an 8-character binary transfer header followed by the compiled object, possibly padded to a full byte at the end. So I surmise that the garbled ASCII transfer header with the T(1) is something done by your DOS-based binary to ASCII converter.

Actually, any translation mode should work okay. I suggested mode 3 because I generally find such files easiest to view and edit.

Also, it seems to me that MS Windows sometimes tinkers with non-ASCII characters? Maybe when using the Windows clipboard?

Regards,
James

                  
Re: converting stored HP-48SX programs to run on HP-50g
Message #5 Posted by Giancarlo (Italy) on 8 Nov 2007, 2:38 a.m.,
in response to message #4 by James M. Prange (Michigan)

Hi James.
Here goes another article of yours saved for my personal bookshelf as "Explanation of Headers.txt" ! :-)
Thanks for your insights.
Best regards.
Giancarlo

[ Return to Index | Top of Index ]

Go back to the main exhibit hall