red@hpfcso.FC.HP.COM (Floyd Moore) (04/11/91)
I know that this is probably a very simple question, but...
I am having troubles with transferring files to/from my 48SX to my
computer. The transfer SEEMS to work, but for example if I try to
transmit a backup copy of my 48SX memory across the link the header on
the library file receives it as:
HPHP48-Eb+ccHOMEDIR
where the small 'c' characters are some non-printable characters.
Now when I retrieve the file/library on the 48SX, I have the following
settings in IOPARM:
IR/wire: wire
ASCII/binary: binary
baud: 9600
parity: none 0
checksum type: 1
translate code: 0
The receipt seem to work just fine and a new variable is created with
the name that I sent first. I then follow the instructions in the
manual and execute the following:
Recall the data from the variable onto the stack 'name' RECALL
The display now shows: "HPHP48-..." same as above. not the "Backup
HOMEDIR" display.
I then try the RESTORE, and I get the following error:
RESTORE Error:
Bad Argument Type
Am I doing something wrong? According to my display I have a current
rev ROM (can't remember how to check the number, but I did once and I
had the latest revision). Are there some other settings I need?
Please could someone shed some light on this problem.
Note: Even though I work for HP, I don't know much about the 48SX. I am
just learning.
-----
Floyd Moore {ucbvax,hplabs}!hpfcla!red
Entry Systems Operation red%hpfcla@hplabs.HP.COM
Hewlett Packard Co. Fort Collins, Colorado darrylo@hpnmdla.hp.com (Darryl Okahata) (04/12/91)
In comp.sys.handhelds, red@hpfcso.FC.HP.COM (Floyd Moore) writes: > I know that this is probably a very simple question, but... > I am having troubles with transferring files to/from my 48SX to my > computer. The transfer SEEMS to work, but for example if I try to > transmit a backup copy of my 48SX memory across the link the header on > the library file receives it as: > HPHP48-Eb+ccHOMEDIR > where the small 'c' characters are some non-printable characters. You're using Unix, right? With Unix, the kermit at the *Unix end* must be set to binary transfer mode; the default mode is ASCII, and this mode corrupts HP-48SX binary transfers (the HP-48SX is sending binary, but the receiving end is treating it as ASCII). When receiving ASCII, Unix kermit must translate incoming CR/LF pairs to LF. This is not necessary with IBM PC clones, which is why you see this problem there. -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@relay.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.
red@hpfcso.FC.HP.COM (Floyd Moore) (04/12/91)
Thanks to those who have responded to me via email or here on notes.
The answer was that, as was properly identified by the responders, the
UNIX kermit was set in ascii mode via:
kermit -l /dev/tty09 -s <filename>
instead I should have used the binary mode;
kermit -l /dev/tty09 -i -s <filename>
This prevents the infamous CR/LF translations in UNIX.
I am now the happy owner of a transfer system for my 48SX and can
hopefully do some useful work with it.
Floyd Moore
The opinions expressed here are my own and do not necessarily express
the opinion of Hewlett Packard Company.
-----
Floyd Moore {ucbvax,hplabs}!hpfcla!red
Entry Systems Operation red%hpfcla@hplabs.HP.COM
Hewlett Packard Co. Fort Collins, Colorado sburke@jarthur.Claremont.EDU (Scott Burke) (04/13/91)
This is for those of you stuck on ASCII/BINARY troubles: The reason that the downloaded backup object appears as a string is that it was not correctly _uploaded_ to the PC/Mac. You MUST have your PC/Mac Kermit set for Binary receive (in the Mac version, you set Default File Type to Binary). If you don't do that, but instead receive the archive in ASCII, then it will be corrupt, no matter what you later do. The two problems posted to the net sound like this problem: the ARCHIVE was made to a PC/Mac waiting in ASCII mode. I am not thoroughly versed in the specific file format, or the differences between ASCII and BINARY transfers with Kermit--someone else on the net will be able to answer this question: Is it possible to tweak an ASCII-transmitted file to make it into a valid BINARY file, such as these previous posters need to do to make their archives valid? Scott. sburke@jarthur.claremont.edu