converting stored HP-48SX programs to run on HP-50g - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: converting stored HP-48SX programs to run on HP-50g (/thread-127962.html) |
converting stored HP-48SX programs to run on HP-50g - Grant Nixon - 11-04-2007 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 - James M. Prange (Michigan) - 11-06-2007 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 Quote: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
If the SYSEVAL command is used in a program, then you should check for a
Most 48 series UserRPL programs (recompiled from source code) will run just
If you have a 48 series available, then this could be as simple as downloading them
But if the files are large, then downloading and uploading again at 9600bps could
You could use Emu48, in which case
Or you can install Debug4x, which
Okay, assuming that you have a 48 series emulator working, import the
Don't forget to check for SYSEVAL sequences. You can edit the source code file Quote: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
Note that my ASCII on SD programs were written specifically for SD card 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, Edited: 6 Nov 2007, 5:25 a.m.
Re: converting stored HP-48SX programs to run on HP-50g - Grant Nixon - 11-07-2007 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: 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 - James M. Prange (Michigan) - 11-07-2007 Quote: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:I notice this statement in ASCIIBIN.TXT: Quote: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
By the way, for "importing" and "exporting" objects with Emu48, use the Edit
When you load ASCIIBIN.48 into Emu48, it will appear on the stack as something 1: External ExternalThat'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 Quote:Good; as long as you're certain, that saves you a bit of editing. Quote:Let us know how it works out. Quote: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: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 %%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
The value for F() can be either a period or a comma. This tells the calculator
When writing your own source code files on a PC, you can put the parameters in %%HP: A(D)F(.)T(3);works as well.
Also, parameters can be left out of the ASCII transfer header, in which case %%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
Unfortunately, the ASCII transfer header doesn't include any information as to Quote: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
Also, it seems to me that MS Windows sometimes tinkers with non-ASCII
Regards, Re: converting stored HP-48SX programs to run on HP-50g - Giancarlo (Italy) - 11-08-2007 Hi James. |