48GX to 49G+ transfer

[Adem Ordna]

I've been racking my brain to find a way to get my equations from my 48Gx to my 49G+.
I finally found a way to transfer (in around about way) files via a 49G emulator.

If I set up the emulator to use com1 and hook my PC cable to the 48gX I can copy my files from the 48gx to the virtual 49G. Then if I hook my PC cable and the PC adapter (as a null modem cable) from com1 to Com2 I can use the conn4x transfer the files from virtual 49G to 49G+.

Here are my steps:
***ON PC***
1) Get the following files from HPCalc.org
Emu48
Colored 49G Emulator Faces
HP49 Emulator

2) Extract them all to the same directory (stir well)

3) Run EMU48.EXE and select one of the 49g scripts

4) Go to file | Settings and set Wire to COM1

5) Hook 48gX to PC attached to COM1

***ON 48GX***

6) Go into the transfer menu ( [RShift][I/O](select Transfer...) [OK]

7) Make sure the FMT: is ASC and select the files you want to transfer. Press [SEND]

***ON virtual 49G***

8) Go in to Files click [LShift] [FILES][OK][NXT][RECV] 48GX to 49G+ transfer

***Now your files should be on the V49G***

9) Unhook the 48GX plug in the PC adapter to the PC cable now you have a Null modem cable (This is Just like Monkey Island)

10) Hook the Null modem cable between COM1 and COM2

11) Hook up the 49G+ via the provided USB cable

***On the 49G+ and V49g***

12) Put both 49G+ and the V49G in to Xmodem server mode [RShift][RArrow]

***On the PC***

13) Open the COnn4x software for the 49G+ and set the "Connect using:" to HPx9G+ and connect

14) Open another instant of the COnn4x software for the 49G+ and set the "Connect using:" to COM2, the "Speed:" to 9600 and connect.

15) Drag files from the conn4x window for the V49G to the Conn4X window for the 49G+

***TA DA***

Parts used obtained from hp calc support:

PC to 49G cable F1897-66000,
Cable to 48 adapter F1633-66001,
Cable to PC adapter F1906-66000

Software used obtained from hpcalc.org:

Emu48, emu48-1.30.zip, http://www.hpcalc.org/details.php?id=3644

Colored 49G Emulator Faces, 49gcolor.zip, http://www.hpcalc.org/details.php?id=3206

HP49 Emulator, calc.exe, http://www.hpcalc.org/details.php?id=3207

[Adem Ordna]

If any one has a better option please post the directions.

Adem 0rnda

[James M. Prange (Michigan)]

I've got to admit that I didn't even try to follow all that. Conn4x doesn't work
with my PC, so I do my transfers via the SD card and a card reader. But files
put on the SD card by the 49g+ look just like a file transferred in binary mode
(even including a "binary transfer" header), so I expect that a similar method
would work with files transferred via Conn4x's Xmodem. Note that Conn4x doesn't
give us the option of Kermit file transfers or, for that matter, ASCII transfers
of any kind.

Note that the entry points on the 48 series and 49 series (including, I believe,
the 48gII as being in the 49 series) differ, so binary transfers between them
aren't possible. Well, with a little fooling around, they're possible, but
unless you're absolutely certain that the object code is the same on both
calculators, not a good idea. To transfer between the 48 and 49, you generally
want the decompiled form of the object.

Anyway, transfer from the 48 to the PC in Kermit ASCII mode (using something
other than Conn4x), preferably using translation mode 0 unless you intend to
edit the file on the PC, and then transfer that file from the PC to the 49.
Since the file doesn't have a valid binary transfer header, it will be stored as a
character string.

Recall the string to the stack and use the information in the ASCII transfer
header, similar to:

%%HP: T(0)A(R)F(.);

, to set the 49 modes. Use the
value from "T(0|1|2|3)" as a numeric argument for TRANSIO for the Translation
mode. The "A(D|R|G)" tells you how to treat objects with an Angular component;
execute DEG, RAD, or GRAD as needed depending on the letter. "F(.|,)" tells you
which of "." or "," is the Fraction mark; be sure that the calculator is set up
in accordance with this.

Edit out the ASCII transfer header. If you care to automate this,

\<< ";" POS 1. + OVER SIZE SUB \>>

should be good, and works even if the
source file was written on the PC and some of the optional parameters are left
out of the header.

As the file is from a 48, set the 49 to approximate mode so that real numbers
aren't compiled as exact integers. If the file were from a 49, you'd want to use
exact mode to avoid compiling exact integers as real numbers.

If you used translation mode 2 or 3, run the following program:

%%HP: T(3)A(R)F(.);

@ Argument: Level 1: A character string.

@ Returns: Level 1: A character string translated as in Kermit ASCII

@                   RECV transfers.

@ Notes: 1: Respects translation mode in IOPAR.

@        2: If IOPAR doesn't exist in the HOME directory, then creates

@           it with default values.

@        3: If IOPAR exists but is invalid, then errors out.

@ Checksum: # CED2h

@ Size: 30.5

@ For 49G and 49g+

@ NOT for 48S/SX/G/GX/G+!

\<<

  \->STR                            @ Verify that an argument exists and

                                    @ force it to be a string.

  # 2F34Dh SYSEVAL                  @ KINVIS for 49G and 49g+.

  +                                 @ Append any partial code.

\>>

Now compile to an object by executing either STR\-> or OBJ\->.

Finally, store the object.

It's been reported that if you have IrDA on the PC, you can treat the IrDA as a
"virtual COM port", and use Kermit with it. Certainly there are IrDA-RS232
adapters available that will allow you to use Kermit on the 49g+, assuming that
your PC has an RS-232 port. Come to think of it, I believe there are IrDA-USB
adapters too; whether they'd be treated as COM ports, I don't know.

For more on "Kermit ASCII" translations and decompiling objects, see:
http://groups.google.com/groups?threadm=boq59a%24nh2%241%40newsreader.mailgate.org

In general, search from:
http://groups.google.com/advanced_group_search?group=comp.sys.hp48 for
answers to many questions about the RPL calculators.

Regards,
James

Edited: 11 Dec 2003, 2:17 a.m.

[Victor Koechli]

Not all that easy or user friendly, I'd say. However, it's good to know that it can be done, so I can eventually go out and buy myself a 49G+.

Another good thing is that the tools needed for this procedure are also available on a Mac - if the USB connection to the 49G+ works, that is. Has anyone tried this?

Thanks, Victor

[James M. Prange (Michigan)]

Not at all "user-friendly". The user shouldn't have to use SysRPL or SYSEVAL commands simply to transfer files. I was amazed to find that the USB communications package for the 49g+ doesn't include Kermit. What were they thinking? Were they thinking?

As for tools to do this on a Mac, you really only need the computer as a place to upload the file to and store it so you can download it to the other calculator. If you prefer, you could edit out the header on the computer instead of on the calculator, but you can do it all (except the file transfers themselves) on the calculators.

There have been discussions on comp.sys.hp48 about connecting the 49g+ to the Mac, and to Linux boxes too, for that matter, but I haven't paid much attention to them. Search the Google archive of the newsgroup.

Regards,
James

[Victor Koechli]

Thanks, James, I'll check it out. Actually, I have Kermit and Xmodem tools on the Mac, and I can communicate with my 48 SXes and GXes without problems. The real question will be if the Mac can 'see' the 49G+ by itself, or if I need some piece of software (e.g. a driver) for this. Let's see what I can find out...

Thanks again very much, Victor

[James M. Prange (Michigan)]

Well, maybe via IrDA?

For the USB connection, there are drivers for MS Windows, but the HP website doesn't seem to have any drivers for non-Microsoft operating systems. Possibly there's a way to use an MS driver with your Mac?

Actually, the USB communications package doesn't even work with my MS Windows 98SE. Supposedly something to do with a particular chipset on the motherboard. It does work for the ROM upgrade, but not file transfers. But my USB doesn't seem to have a problem with anything else except my USB to RS-232 adapter with HP software for the 49G.

But except for the problem of not having a built-in UserRPL method of using decompiled and translated files with the SD card, I find transferring by using card reader attached to a USB port very convenient and fast.

Unfortunately, RS-232 type serial isn't available on the 49g+.

Regards,
James

[Jeff Lastofka]

I just bought a 49g+ and transferred my entire 49g to it by backing up the 49g using the new connectivity software and my old serial cable. Then I restored the same backup file to my new 49g+ using the USB cable. It seemed to work flawlessly. Files, directories, key assignments, flags, everything.

What I can't do is view or print the program files from the new connectivity software on my PC. I can do it with the files from the old connectivity kit, though....

Anyone got a way to easily print the files from the connectivity software?

[James M. Prange (Michigan)]

By "print the file", I'm guessing that you mean decompile it, possibly
apply the I/O translations, and transfer it to the PC. Basically what a
Kermit "ASCII" transfer does to it.

I understand that you can do Kermit transfers (binary or ASCII) with
IrDA, but as far as I know, the USB connectivity package doesn't give
you the option of ASCII transfers. But you can do the following. Observe
the usual precautions with the SYSEVAL sequences.

First, set up IOPAR to use the translation mode desired. I prefer mode
3; to set this, do 3 TRANSIO (or edit the last element in the IOPAR
list).

Recall the object to the stack.

Decompile it with the following program:

%%HP: T(3)A(R)F(.);

@ Argument: Level 1: Any object.

@ Returns: Level 1: Object decompiled to command line editor character

@                   string form.

@ Notes: 1: For a character string argument, the result is the string

@           embedded within another string.

@        2: "Real" numbers are as in STD display format.

@        3: "Binary" integers use wordsize 64.

@ Checksum: # 7771h

@ Size: 30.5

@ For 49G and 49g+

@ NOT for 48S/SX/G/GX/G+!

\<<

  DUP DROP                          @ Verify that an argument exists.

  # 25ECEh SYSEVAL                  @ EDITDECOMP$ for 49G and 49g+.

\>>

Translate it (if using a translation mode other than 0) with the
following program:

%%HP: T(3)A(R)F(.);

@ Argument: Level 1: A character string.

@ Returns:  Level 1: A character string translated as in Kermit ASCII

@                    SEND transfers.

@ Notes: 1: Respects translation mode in IOPAR.

@        2: If IOPAR doesn't exist in the HOME directory, then creates

@           it with default values.

@        3: If IOPAR exists but is invalid, then errors out.

@        4: For translation modes other than 0, translates a "bare"

@           NewLine (LineFeed or LF) to a CarriageReturn LineFeed pair,

@           but a CRLF pair is left as is.

@ Checksum: # 2AC1h

@ Size: 28.

@ For 49G and 49g+

@ NOT for 48S/SX/G/GX/G+!

\<<

  \->STR                            @ Verify that an argument exists and

                                    @ force it to be a string.

  # 2F34Fh SYSEVAL                  @ KVISLF for 49G and 49g+.

\>>

Or combine the above programs into:

%%HP: T(3)A(R)F(.);

@ Checksum: # 34ACh

@ Size: 46.

\<<

  DUP DROP                          @ Verify that an argument exists.

  # 25ECEh SYSEVAL                  @ EDITDECOMP$ for 49G and 49g+.

  # 2F34Fh SYSEVAL                  @ KVISLF for 49G and 49g+.

\>>

You should now have a character string that looks much as the file would
on the PC, except that it doesn't have a transfer header. Store the
string into a variable, and transfer it using the USB connectivity
application (or an SD card and a card reader).

On the PC, the file will have a binary transfer header (HPHP49-X),
followed by five characters which are five nibbles for the character
string prologue and five nibbles for its length field. You can safely
ignore or edit out these first thirteen characters.

Regards,
James

[James M. Prange (Michigan)]

PS:

I said that you can safely ignore the first 13 characters of the string transferred to the PC in binary mode. But if you're planning to send the file back to a calculator, that's only true if you don't modify the file. Even viewing the file with a text editor and saving it without making any explicit changes may well modify it, so it may well be that the length field would be incorrect. In such a case, always edit out those first 13 characters so that the calculator will store it as a string instead of attempting to store it as an already compiled object.

Regards,
James