Help Please: Program PC to Calc file transfer?
Dale
figure out a way to transfer a working program (constructed in
notepad) to my new hp49g+ via Conn4x. It seems that the only way
Conn4x sends data is via a string.
via XRECV:
On the hp49g+ the contents of my program variables become strings
with newline chars embedded. Using the header: HPHP49-C <or>
%%HP: T(3)A(D)F(.); just adds that header to the string.
Am I doing this incorrectly with the hp49xx series? Is there a flag
setting that I need to change? I have tried toggling flag 35 from
binary to ASCII, which produced the same string.
"Help" is missing from my version 2.1 build 1783 Conn4x. Your help is
appreciated, thanks!
-Dale-
Earl Cenac
I had the same problem till I did these and now I have no problem.
1 If you do not have it yet, download debug4x from www.hpcalc.org.
One of the things that comes with it is the emu49 emulator.
2 Download http://www.hpcalc.org/search.php?query=emu48+Ascii+to+Binary+Converter
from www.hpcalc.org.
Follow the simple instructions in the text file attached to load the
emu49asc.bin file into the emulator and save it as any variable you
want (In the emulator).
Now with your notepad file with the correct heading %%HP:
T(0)A(D)F(.); and program delimiters « » , load it into the emulator.
Then convert it by pressing the variable that you created in step 2
earlier.
Your program is now converted into a compiled form ready to transfer
into the calculator.
Using the emulator's "save object" menu command, save the file on your
pc. Save it with a calculator variable name (without any extension).
Finally, download your program into your calculator using your usb
connection and you have your calculator program ready to run.
Motz
somewhat less convoluted solution. One might think that given the
depth of knowledge and breadth of experience of hp (calcs) that there
would be a little more elegant (aka: simpler) process.
I thank you, and at least I'm off and running now.
I hope hp doesn't consider Conn4x to be the ultimate be-all / end-all
PC to hp49g+ program development solution and that perhaps they might
make another attempt to improve upon their effort in some fashion.
(:^0)|
There just might be a little wiggle room for some improvement if they
try!
James M. Prange
> With my hp48sx and HPComm this was no problem; but I cannot seem to
> figure out a way to transfer a working program (constructed in
> notepad) to my new hp49g+ via Conn4x. It seems that the only way
> Conn4x sends data is via a string.
Well, it seems that the only way Conn4x transfers files is via Xmodem,
which doesn't have an ASCII mode, and since it didn't have a valid
binary transfer header, it stored the entire transfer as a character
string.
> via XRECV:
>
> On the hp49g+ the contents of my program variables become strings
> with newline chars embedded. Using the header: HPHP49-C <or>
> %%HP: T(3)A(D)F(.); just adds that header to the string.
The HPHP4n-x (where "4n-x" is the ROM information) is a binary transfer
header. The compiled object, starting with the 5-nibble prolog, is
expected to immediately follow the header, and it's just a bit difficult
to work with. The binary transfer header tells the calculator that
everything following the header is a compiled object, and whether the
object is valid for the calculator that you're trying to transfer it to.
Note that files transferred in binary mode are not intended to be edited
outside of a calculator.
The "%%HP: T(3)A(D)F(.);" is an ASCII transfer header. ASCII transfers
use the command line editor's string form of the decompiled object and
optionally translates bare NewLines to CRLF pairs, backslashes to
doubled backslashes, and non-ASCII characters to translation codes. A
file transferred in this manner can be edited just like in the command
line editor; at worst you'll get a syntax error when you transfer it
back to the calculator and it tries to compile your source code.
When the calculator receives (using Kermit) a file with an ASCII
transfer header, the header tell the calculator to treat it as such. The
"T(3)" tells it to using Translation mode 3. The "A(D)" tells it to
treat Angular components of vectors and ordered pairs as Degrees. The
"F(.)" tells it that a "." is a Fraction mark and a "," is a separator.
These parameters are optional and can be in any order. For example,
"%%HP: A(D)F(.)T(3);" has the same effect as "%%HP: T(3)A(D)F(.);", and
"%%HP: ;" makes it an ASCII transfer using the calculator's current
modes.
If the binary transfer header isn't valid for the calculator, then the
transfer is stored as a string. Likewise, if no header is present, it's
also stored as a string. When using Xmodem, an ASCII transfer header is
meaningless to the calculator, so it just stores the transfer as a
string.
If you add either of these headers to a string and send it from the
calculator via Xmodem, then it will just prepend a binary transfer header
to the compiled string.
In the case of a compiled character string, it starts with a 5-nibble
prolog, followed by a 5-nibble count of the numbers of nibbles in the
object (not including the prolog). These are the 5 "garbage characters"
you find after the header when you look at a string transferred to your
PC via a binary transfer. Finally comes the characters in the string,
each 1 byte.
What you can do is, first, make sure that you're in STD number display
format so that all 12 digits of "reals" are included, and make sure that
the wordsize is 64 (do 64 STWS) so that all 64 bits of user "binary"
numbers are included. Now do \->STR; this decompiles the object to
string form. If you want newlines and all non-ASCII characters
translated, first make sure the translation mode in IOPAR is 3. Run 3
TRANSIO if you're not sure. Also keep track of the angular mode and
fraction mark.
Then run the following program, but be careful to copy the hex number
before SYSEVAL exactly, and use the BYTES command to verify the checksum
and size before running it.
%%HP: T(3)A(R)F(.);
@ Checksum: # 2AC1h
@ Size: 28.
@ For 49G and 49g+ only!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 2F34Fh SYSEVAL @ KVISLF for 49G and 49g+.
\>>
Now, use Xmodem (or the SD card) to transfer it to your computer. Note
that it will have the binary transfer header, string prolog and nibble
count.
If you change the file in any way at all, remove these first 13
characters while you're at it. Note that it would be very easy to get a
mismatch between the actual string length and the count field after the
prolog; I wouldn't care to experiment with how the calculator would deal
with something like that in an object.
When you transfer the edited file back to the calculator, it will be
stored as a string, because with the missing header, the calculator
won't know what else to do with it.
To change the translation codes back to characters, check that the
translation mode in IOPAR is correct, and then run the following
program, the precautions for SYSEVALs apply here too.
%%HP: T(3)A(R)F(.);
@ Checksum: # CED2h
@ Size: 30.5
@ For 49G and 49g+ only!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 2F34Dh SYSEVAL @ KINVIS for 49G and 49g+.
+ @ Append any partial code.
\>>
Finally, make sure that the angular mode and fraction mark is correct,
and then do STR\-> (or OBJ\->) to compile from the string form to an
object.
> Am I doing this incorrectly with the hp49xx series? Is there a flag
> setting that I need to change? I have tried toggling flag 35 from
> binary to ASCII, which produced the same string.
Sorry, ASCII mode is for the Kermit file transfer only. It amounts to
pre/post-processing for Kermit. It has never been implemented for
Xmodem, and Conn4x doesn't offer Kermit.
> "Help" is missing from my version 2.1 build 1783 Conn4x. Your help is
> appreciated, thanks!
Yes, apparently it's assumed that you already have Conn4x and the USB
driver installed when you do the updates. Re-install from the CD that
came with your calculator and the install the update.
--
Regards,
James
Motz
by Earl Cenac (ala EMU48 v1.33). It's a quick and dirty way to
accomplish the same thing. It just needs the emulator as an
intermediary.
I guess I don't quite understand why hp couldn't have adapted the
HPComm v 3.04 to include a USB driver option. I would think that
would have worked just fine; and not have had to play ASCII to Binary
conversion and vice versa. Perhaps there were copyright issues(?) or
something.
I did understand about the header symbolism as that was the case with
hp48sx also. I have made a bunch of proggys on the hp48sx with HPComm
and it was adequate for the purpose. Conn4x is just not ready for
prime time yet; and there is that outstanding issue of lack of rs-232
from the hp49g+ still left haunting.
James M. Prange
> I have been ping ponging back and forth using the technique described
> by Earl Cenac (ala EMU48 v1.33). It's a quick and dirty way to
> accomplish the same thing. It just needs the emulator as an
> intermediary.
>
> I guess I don't quite understand why hp couldn't have adapted the
> HPComm v 3.04 to include a USB driver option. I would think that
> would have worked just fine; and not have had to play ASCII to Binary
> conversion and vice versa. Perhaps there were copyright issues(?) or
> something.
Could be.
> I did understand about the header symbolism as that was the case with
> hp48sx also. I have made a bunch of proggys on the hp48sx with HPComm
> and it was adequate for the purpose. Conn4x is just not ready for
> prime time yet; and there is that outstanding issue of lack of rs-232
> from the hp49g+ still left haunting.
Agreed. I can't even use Conn4x with my computer except to update the
ROM. And there have been reports of other problem with it.
I wish that they'd add Kermit (with its ASCII transfer mode) to it.
Why not an ASCII transfer mode for Xmodem?
And for compatibility with the 48 series, when doing an ASCII transfer,
if the characters NUL, ", or \ are in the decompiled object, use the
counted string form before doing the translations.
And add an option to translate the control codes 0-9, 11-31, and 127
too.
And add an option to instead of replacing bare NewLines with CRLF pairs,
replace them with a user-defined line termination string, as is done
when printing by wire or Serial IR.
<snip>
--
Regards,
James
James M. Prange
<snip>
> What you can do is, first, make sure that you're in STD number display
> format so that all 12 digits of "reals" are included, and make sure that
> the wordsize is 64 (do 64 STWS) so that all 64 bits of user "binary"
> numbers are included. Now do \->STR; this decompiles the object to
> string form. If you want newlines and all non-ASCII characters
> translated, first make sure the translation mode in IOPAR is 3. Run 3
> TRANSIO if you're not sure. Also keep track of the angular mode and
> fraction mark.
>
> Then run the following program, but be careful to copy the hex number
> before SYSEVAL exactly, and use the BYTES command to verify the checksum
> and size before running it.
>
> %%HP: T(3)A(R)F(.);
> @ Checksum: # 2AC1h
> @ Size: 28.
> @ For 49G and 49g+ only!
> \<<
> \->STR @ Verify that an argument exists and
> @ force it to be a string.
> # 2F34Fh SYSEVAL @ KVISLF for 49G and 49g+.
> \>>
Come to think of it, you may as well just set the translation mode do
the following instead:
%%HP: T(3)A(R)F(.);
@ Checksum: # 34CAh
@ Size: 46.
@ For 49G and 49g+ only!
\<<
DUP DROP @ Verify that an argument exists.
# 25ECEh SYSEVAL @ EDITDECOMP$ for 49G and 49g+.
# 2F34Fh SYSEVAL @ KVISLF for 49G and 49g+.
\>>
Don't forget to keep track of the translation mode, angular mode if the
object has any ordered pairs or vectors with angular components, and of
course the fraction mark.
--
Regards,
James
PoppaCork
stuff?
I wanted to transfer my 49G programs from my PC to my new 49G+ but
encountered the strings issue.
Happily, using your code as listed below these problems are pretty
easily overcome.
> # 25ECEh SYSEVAL @ EDITDECOMP$ for 49G and 49g+.
> # 2F34Eh SYSEVAL @ KVIS for 49G and 49g+.
> # 2F34Fh SYSEVAL @ KVISLF for 49G and 49g+.
> # 2F34Dh SYSEVAL @ KINVIS for 49G and 49g+.
After transfer from PC to 49G+ I edit the string to remove the header
info and the repeated lines (that always appear at the end of the
string??) then return the string to the stack.
To speed things up I then run this conversion program, that uses your
code, but with no checks, though always ensuring the string in on
'level 1' of the stack
<<
# 25ECEh SYSEVAL
# 2F34Eh SYSEVAL
# 2F34Fh SYSEVAL
# 2F34Dh SYSEVAL
DROP STR-> STR->
>>
I then store the code as a program/variable. (The DROP gets rid of an
extra set of quotation marks that appear on the stack.)
As you can see I have no idea what I am doing!!!
Is this dodgey and am I using the SYSEVAL commands correctly?
Certainly they seem to do the trick.
Thanks again for the excellent advice.
Chris McCorkindale
Austrukinfalia... mate
ps apologies for repeating myself, I posted this under another similar
message regarding this topic