48 to 49 object conversion


I know that a diligent browse of hpcalc.org would likely yield fruit, but I am by nature lazy, and I do enjoy the social aspect of posing questions in this forum.

I am interested in finding something that converts UserRPL programs and other objects written on an HP48G to HP49G compatible format, and back if possible.

Is there such a beast? The syntax of program on each series of calcs is so similar there must be a way of forward and back porting progs without having to manually rekey them.




Is there such a beast?



The only thing that you need is the serial cable that came with your HP49G to connect both calcs. Set them for Kermit transfer with ASCII format and that should take care of your USER RPL programs. On the HP 49G side it need to be on Kermit - ASCII and the CAS in aproximate mode. Do note that some object or variable names used on the 48 could be new commands on the 49.


I actually have a 49G+. So should IR transfer work?



Actually, I just tried it and have answered my own question.

My HP48G and HP49G+ do not speak "infrared" to each other, alas.

I guess my next question is: should they?



Actually, I just tried it and have answered my own question.

My HP48G and HP49G+ do not speak "infrared" to each other, alas.

The 49g+ isn't designed to "speak" directly to the 48 series or
49G. It can communicate with another 49g+ or a 48gII via IrDA, but
not via wire. Using USB and Conn4x, it can communicate with a MS
Windows system, and there are USB communication packages for Macs
and Linux systems too.

At least with Win98SE, an IrDA device can be seen as a "virtual
COM port", and HyperTerminal can be used with it for communication
with a 49g+. I don't know whether this works with WinXP; maybe by
using an application called IrCOMM2k; available

Using an SD card or MMC, you can transfer objects between the 49g+
and a PC, but the 49g+ stores objects to the card as binary
transferred files, and binary transfers between the 48 and 49
series aren't allowed. For programs designed to store objects on
the card in a format compatible with Kermit ASCII transfers, see

I guess my next question is: should they?

Well, in my opinion, the 49g+ should've at least had
RS-232 compatible communication capability built-in, and maybe the
IR used on the 48 series, as well as USB and IrDA, but it doesn't.

The thing to do is transfer to the PC in "Kermit ASCII" or "Text"
format, and then transfer to the other calculator.

In general, source code for the 48 series will usually work on the
49 series. Possible pitfalls include global names on the 48 being
built-in command names or reserved variables on the 49. To avoid
having the 49 compile "real" numbers that happen to be integers as
"exact integers" (a different object type), have the 49 in
"approximate" mode while transferring to it.

The 49 series adds some new object types. Exact integers will be
compiled as real numbers, rounded to 12 significant digits if
needed, when compiled on the 48. Symbolic matrices can be compiled
on the 48 only if the elements are all real numbers or exact
integers, or all complex numbers, and they'll be compiled as real or
complex matrices. Other new object types won't compile on the 48

The following object types can be transferred only in binary mode:

16 Library
17 Backup Object
20 Internal Binary Integer
21 Extended Real Number
22 Extended Complex NumberLes
23 Linked Array
24 Character Object
25 Code Object
26 Library Data
27 Minifont
30 Font

If you want to transfer SysRPL or assembly objects between models,
first use the appropriate tools to decompile them to source code
form, make any changes needed for compatibility, and recompile
them for the other model.


Edited: 3 June 2006, 9:16 p.m.


This is the tentative solution I have come to to go from 48 to 49G+. I haven't had any call to got the other way yet.

Most of my program objects of interest are on my PDA in Power48. Saving an object from the stack to internal memory or SD card is in binary form, just as in Emu48.

This means I store the binary program object to the SD card. Plug the SD card to my PC. Upload the file from SD card to my real HP48G, then back to the SD card in ASCII format, using hp48 explorer which is Kermit driven.

The, I plug the SD card in the HP49G+, load the ASCII file on to the stack, hit up arrow then the EDIT soft key (since just hitting the down arrow doesn't reveal the quotes to be removed from the string object), edit out the quotes and the header information, enter the edited object on to the stack, then save to a variable.

Running the programs require the numeric and/or approximate CAS settings to be appropriately set, otherwise conditional tests go wrong or the output is confusing unevaluated gibberish. But it works, and my UserRPL progs from HP48G work well on the HP49G+.

This works, but it is cumbersome, and I can only do it on the one computer I have with a serial port. What I really want to do is take the binary files that I have stored to the SD card from Power48, convert them DIRECTLY to ASCII using a utility on the PC, save them back in SD format, then load and refine them on the HP49G+ for use as described above.

Maybe the HPBINASC.exe utility is what I need here?

I will try it out and let you know....



Nope, that doesn't work.

HPBINASC does a different kind of binary-ASCII conversion than what I am seeking. It basically takes all of the ASCII codes for things like the double angle brackets (\<<), forward arrows(\->), and Greek symbols, and converts them to HP48 symbols and back. Doesn't take a full blown binary file and turn it to a text one.

Is there utility that does the same conversion on the PC that Kermit and hp48 explorer do when transfering objects to and from the actual calc over a serial connection?

That, folks, is the question I still dangle before ye!




Well, my "ASCII on SD" programs, or something similar, might work within an emulator on the PC.




My ASCII on SD programs were intended specifically for the 49g+, so use commands and SYSEVAL addresses for the 49 series. If you try it on an emulator, make sure that it's emulating a 49 series; don't even try it on a 48 series.



Some suggestions:

First use \->STR to decompile the object to source code form
before transferring it out of the 48.

On the 49, you could use STR\-> to compile the object, but if
there's a syntax error, that won't give you any clue of where it

If you simply edit out the string delimiters, be sure that the
"fraction mark" is the same on both calculators, and if it has a
complex number or vector with an angle symbol in it, aso make sure
that the angular mode (DEG. RAD, or GRAD) is the same.

But if you use \->STR, it may be difficult to edit the source code
on the PC, unless the character sets match. With the Kermit
translation mode set to 3, you can use the SysRPL command KVISLF
or KVIS to do the Kermit ASCII translations, and KINVISLF to
"untranslate" it.



I actually have found a solution that works. I tried it once but left out a step.

On the hpcalc.org page where you list your utility there is also the ASCIIBIN utility, which happens to be for my purposes the same as the EMU48ASC utility that packs with Emu48.

In Power48, with HP48gx mode activated, I load my desired HP48G object on the stack, use the EMU48ASC utility to convert it to a text string right on the stack. Save that string as an object to the SD card. (I could just have well used Emu48 as the emulator, not Power48.)

Now the step I left out: I plug the SD card in my PC, open the saved object in Notepad, edit out all of that HPHP etc. header stuff at the beginning up until the the first << bracket where the code begins, save it.

Plug the SD card into the HP49G+, load the string object to the stack, up arrow EDIT, nip out the quotes, enter back to stack, save into a variable, voila....

The problem I had before was that the HPHP header stuff blocked editing--you get a "can't edit null char" error box, or something of that ilk when executing the up-arrow EDIT key sequence.

There still is a middle step here--editing out the header in a text editor--but it is a lot less cumbersome than transfering the file back and forth to the actual HP48G calculator to attain the proper ASCII format.

I know this routine will not carry thru certain changes in complex code, but for my simple little programs it seems to do the trick just fine.

Thanks for devoting a lot of thought tonight to my little dilemma. I am glad we came up with an answer. I think I have mentioned in the Forum that my newly acquired HP49G+ is actually growing on me (sacrilege to HP48GX purists, I know), so getting my programs off the emulator and onto it is a really neat thing to accomplish.



The "Can't Edit Null Char." error is a bit surprising. On a 49
series, attempting to use EDITB (invoked by CursorDown) on a
string containing a NUL does indeed result in that error, but EDIT
(invoked by LeftShift CursorDown or CursorUp EDIT) decompiles NUL
to \00, a literal double-quote (") embedded within a character
string to \", and \ to \\.

When compiling, \00 becomes NUL, \" becomes ", \\ becomes \, and
any \ not immediately followed by 00, ", or another \ is

But note that a 49G with a ROM revision earlier than 1.19-6
incorrectly compiles \00 to 00, instead of to NUL.

Now that I think of it, the way that the 49 series decompiles
these "special cases" can cause problems in transfers from a 49 to
48 too.

Note that on a 48 series, any string that contains a literal "
character is decompiled to a counted string form, which the 49
series compiles correctly, so transferring one from a 48 to a 49
isn't a problem.

Since a binary transfer from a 48 has the wrong header for a 49,
the calculator simply (and safely) stores the entire data stream
within a character string object. In the case of a character
string, the data stream would start with the binary transfer
header (8 bytes), a character string prologue (5 nibbles, or 2.5
bytes), a length field (5 nibbles, or 2.5 bytes), and finally the
characters of the string itself. So you end up with a string with
its first thirteen bytes being the binary transfer header plus
some "garbage".

A way to remove the binary transfer header, character string
prologue, and length field on the calculator itself is:

The above simply returns the string without the first thirteen



You are of course correct.

I was getting the NUL character error ONLY on attempting the down arrow action to open editing. Left shift down does exactly what you say it does.

This makes me happier--I can now get get header characters out right on the calculator. Don't have to edit the converted ASCII file in a text editor first....



Possibly Related Threads...
Thread Author Replies Views Last Post
  HP 35s polar/rectangular conversion CD Dodds 6 582 11-28-2013, 02:39 PM
Last Post: Dieter
  HP Prime... NOT meant to replace HP48,49,50 ? Chris Pem10 21 1,494 11-18-2013, 03:30 PM
Last Post: Chris Smith
  [WP 34s] Pressure Conversion Factors Timothy Roche 8 777 11-04-2013, 07:17 PM
Last Post: Dave Shaffer (Arizona)
  More programs for polar-rectangular conversion on HP Prime Michael de Estrada 4 513 11-04-2013, 12:43 AM
Last Post: Michael de Estrada
  ANN: A MacOSX Kermit program for HP48/49/50 calculators Paul Onions 2 384 09-08-2013, 04:55 AM
Last Post: Paul Onions
  HP Prime: Conversion factors Paul Townsend (UK) 19 1,167 08-27-2013, 09:19 AM
Last Post: Nigel J Dowrick
  Nibble reverse (HP-48,49,50g) Gerson W. Barbosa 44 2,855 07-28-2013, 10:10 PM
Last Post: Gerson W. Barbosa
  (OT) Pandigital expression (HP-48,49,50g) Gerson W. Barbosa 19 1,328 07-19-2013, 05:59 AM
Last Post: Gilles Carpentier
  downloading HO 229 v. 2,0 from HP 49/50 Astronomy Programs list Al 10 776 11-26-2012, 05:38 PM
Last Post: Al
  Best Keyboard of the HP 28/48/49/50 Series Eddie W. Shore 9 714 07-12-2012, 07:21 AM
Last Post: Dave Britten

Forum Jump: