HP Forum Archive 16

[ Return to Index | Top of Index ]

48 to 49 object conversion Message #1 Posted by Les Wright on 3 June 2006, 11:39 a.m. 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. Les

Re: 48 to 49 object conversion Message #2 Posted by Virgilio Guillen on 3 June 2006, 12:54 p.m., in response to message #1 by Les Wright Quote: Is there such a beast? Les Hi, 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.

Re: 48 to 49 object conversion Message #3 Posted by Les Wright on 3 June 2006, 4:52 p.m., in response to message #2 by Virgilio Guillen I actually have a 49G+. So should IR transfer work? Les

Re: 48 to 49 object conversion Message #4 Posted by Les Wright on 3 June 2006, 5:32 p.m., in response to message #3 by Les Wright 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? Les

Re: 48 to 49 object conversion Message #5 Posted by James M. Prange (Michigan) on 3 June 2006, 9:09 p.m., in response to message #4 by Les Wright Quote: 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 here. 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 here. Quote: 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 series. 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. Regards, James Edited: 3 June 2006, 9:16 p.m.

Re: 48 to 49 object conversion Message #6 Posted by Les Wright on 3 June 2006, 9:14 p.m., in response to message #4 by Les Wright 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.... Les

Re: 48 to 49 object conversion Message #7 Posted by Les Wright on 3 June 2006, 9:34 p.m., in response to message #6 by Les Wright 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! thanks, Les

Re: 48 to 49 object conversion Message #8 Posted by James M. Prange (Michigan) on 3 June 2006, 9:41 p.m., in response to message #7 by Les Wright Well, my "ASCII on SD" programs, or something similar, might work within an emulator on the PC. Regards, James

Re: 48 to 49 object conversion Message #9 Posted by James M. Prange (Michigan) on 3 June 2006, 9:48 p.m., in response to message #8 by James M. Prange (Michigan) PS: 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. Regards, James

Re: 48 to 49 object conversion Message #10 Posted by James M. Prange (Michigan) on 3 June 2006, 9:39 p.m., in response to message #6 by Les Wright 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 is. 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. Regards, James

Re: 48 to 49 object conversion Message #11 Posted by Les Wright on 3 June 2006, 10:06 p.m., in response to message #10 by James M. Prange (Michigan) 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. Les

Re: 48 to 49 object conversion Message #12 Posted by James M. Prange (Michigan) on 3 June 2006, 11:27 p.m., in response to message #11 by Les Wright 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 discarded. 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: 14 OVER SIZE SUB The above simply returns the string without the first thirteen bytes. Regards, James

Re: 48 to 49 object conversion Message #13 Posted by Les Wright on 4 June 2006, 1:38 a.m., in response to message #12 by James M. Prange (Michigan) 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.... Thanks! Les

[ Return to Index | Top of Index ]

Go back to the main exhibit hall