Re: Transferring data from a HP50 to a PC [Long]
Message #2 Posted by James M. Prange (Michigan) on 25 Sept 2007, 10:46 a.m.,
in response to message #1 by Stuart Sprott
Quote:
When I had a working HP 48 I could transfer data from the HP to a
PC in ASCII format.It appears that you can do the same with the HP
50. The same commands are there but it seems like that only binary
transfer is acceptable.
I have now started using the SD cards for transfering. They seem
to be much more reliable. But again the same problem.
Is ther any way of transforming binary into ASCII ?
Yes.
The 48G and newer have both Kermit and Xmodem protocols available.
For whatever reasons, the Xmodem protocol is still binary-only,
although the SysRPL commands needed for "ASCII" transfers are
built-in and an ASCII transfer option could easily be added to
Xmodem transfers. After all, with the 49 series, they added the
Xmodem server capability, so why not also an Xmodem ASCII transfer
capability? For that matter, MMC/SD card transfers are also
binary-only even though an ASCII transfer option could easily be
added for them too.
If you transfer using IrDA, you can use the Kermit protocol and
choose "ASCII" mode.
The 50g has a "serial" (but not RS-232 compatible) port. You can
now buy a cable with a built-in level-shifter at a reasonable
price, from http://commerce.hpcalc.org/. Note that you'll
also need a female-to-female "null modem" to connect Eric's cable
to a PC's COM port. I've noticed that since Eric has made his
cable available, a different source (which, as far as I can tell,
typically charges the highest price that the market will bear) has
slashed its price for its cable, but it's still about double
Eric's price, and there have been reports of problems with that
other cable. Or of course you can build your own cable as a
do-it-yourself project. Anyway, using the serial port plus a
level-shifting cable, you can use the Kermit protocol.
Note that HyperTerminal PE can do either Kermit or Xmodem
transfers, and
HPComm (the
"Connectivity Kit" designed for the 49G) uses the Kermit protocol.
For either of these, you'll need a COM port. A USB/RS-232
converter should work. In the case of IrDA, with MS Windows 98SE,
a "virtual COM port" should be available when IrDA is installed on
the PC, but for XP (and, I suppose, Vista), you may well have to
install
IrCOMM2k or
something similar to get the virtual COM port.
But I expect that most users connect to their PCs using the
supplied USB cable, and as far as I know, the only MS Windows
compatible software for USB connections is Conn4x (the supplied
"Connectivity Kit" for the 49g+ and 50g). Conn4x does have a
"text" transfer mode. After connecting, in the "File" menu, choose
"Binary transfer mode, press for text mode". Or easier, there's a
button that by default is labelled "010101" (meaning binary mode);
click it to change it to "ABCD" (meaning text mode). Conn4x uses
the calculator to decompile objects, but does the character
translations itself (on the PC). Note that the translation mode in
IOPAR (set by TRANSIO) is ignored; to set the translation options,
use "Options..." in the Conn4x "View" menu. The Conn4x "text"
translations are almost the same as the Kermit "ASCII"
translations; see the help file for any differences. Also note
that variable names are, if needed, translated to MS
Windows-compatible file names; again, see the help file.
By the way, the version of Conn4x that came on the CD with the
calculator may well be buggy.
Version 2.2 Build
2353 works for me, but
Version
2.3 Build 2439 might be better; I rarely actually use
Conn4x.
Note that the 49 series decompiles a NUL (ASCII control code 0) to
\00, a literal " (double-quote character within a character
string) to \", and \ to \\. With a Kermit ASCII transfer using
translation mode 2 or 3, these are translated to \\00, \\", and
\\\\. Conn4x "simplifies" these three translations, but only when
they occur within a quote-delimited character string, and in rare
cases (as far as I know, some cases of a \ character outside of a
quote-delimited character string) this can cause a mistranslation.
It may be necessary to edit (in the PC file) \ to \092, but this
is needed only where the \ and the 2 or 3 characters immediately
following would make a valid translation sequence, and only
outside of a quote-delimited character string. Finding any other
mistranslations is an exercise for the student.
For that matter, Kermit ASCII translations can go wrong too, if
you happen to have a <CR><LF> (CarriageReturn-LineFeed) pair in a
character string using translation mode 1, 2, or 3. In this case,
in transfers from the calculator, the <CR><LF> pair is left as-is,
instead of being translated to <CR><CR><LF>. But on transfers back
to the calculator, the <CR><LF> pair is translated to just <LF>,
even if it was originally a <CR><LF> pair. Conn4x does avoid this
bug.
In the 48 series, a character string that contain a literal " is
always decompiled to the "counted string" form. I don't know of
any way to get a 49 series to decompile to a counted string form,
but it compiles them just fine.
I really prefer to use an MMC or SD card for transfers. I wrote a
pair of programs to convert between binary objects and characters
strings suitable for Kermit ASCII compatible transfers using a
card. These are UserRPL programs (well, they do use a couple of
SYSEVAL sequences), so they may take a few seconds to run. On the
other hand, commented source code files and a README.TXT file are
included, so they should be fairly easy for a user to customize;
for example, how to translate <LF> characters, and whether to
leave the original commented source code string on the stack when
converting to a binary object. As stored on the card, the first
line of the file will be an "HPHP49-X" binary transfer header,
followed by 5 bytes for the character string prologue address and
length; it's best to edit this line out with a text editor on the
PC. See http://www.hpcalc.org/search.php?query=ASCII+on+SD.
For that matter, it should be fairly easy to port my programs to
SysRPL in case anyone feels inclined to do so, and using some code
invoking the underlying ARM processor, it might be possible to
store a file on the card without the binary transfer header.
Regards,
James
|
Go back to the main exhibit hall