FORSTHO@IITVAX.BITNET (12/31/90)
Can someone please help me? I am trying to doenload a program from Compuserve to my HP48SX. I used Compuserve-Quick-B protocol from Compuserve to my PC and Kermit from my PC to my calculator. The file is in binary form and when I transfer it to my calculator, it is stored as a string which looks like this: "HPHP48-B....." If I try to edit this I get the message 'Can't Edit Null Char.' I don't think the problem is from my PC to the calculator, I think it is either from Compuserve to my PC or even when the file was Uploaded to Compuserve. Can anyone verify this? Thanks for your help. Thomas L. Fors Illinois Institute of Technology MCL Inc. BITNET: FORSTHO@IITVAX.BITNET CompuServe: 76557,344
rrd@hpfcso.HP.COM (Ray Depew) (01/08/91)
Thomas L. Fors (FORSTHO@IITVAX.BITNET) asked: > Can someone please help me? I am trying to doenload a program from > Compuserve to my HP48SX. [stuff deleted] > Compuserve to my PC and Kermit from my PC to my calculator. The file is > in binary form and when I transfer it to my calculator, it is stored > as a string which looks like this: "HPHP48-B....." You forgot to set your calculator to "binary" mode. (Even if you think you did, you really didn't! :-) ) The clue is your statement that the program appears as a string beginning with "HPHP48-B.....". This is the header for binary HP-48 files stored outside the 48. ASCII files start with a header similar to "$$HP: T(3)A(R)F(.);" In the binary header, the "B" refers to the revision # of the calculator from which the program was uploaded (I think). HP tells us that my Rev.A machine and your Rev.D machine can swap binary files without getting bitten by bugs. So the revision number isn't that important (yet). In the ASCII header, "T(3)" refers to "translate code 3," "A(R)" means "angle mode is radians", and "F(.)" means that the decimal point is a dot rather than a comma. The 48 sets these variables on uploading a file, and reads them when downloading the file, temporarily changing its configuration as necessary to make sure that the data is downloaded accurately. You can also change the variables yourself, when editing the file offline. Sorry, I know that's more information than you asked for. > ... I don't think the problem > is from my PC to the calculator, I think it is either from Compuserve to > my PC or even when the file was Uploaded to Compuserve. Can anyone verify > this? Nope, it's at the last link in the chain: the calculator. According to the owner's manual, "A receiving HP 48 treats all files as ASCII unless they match the special encoding generated for HP 48 binary files. The calculator will automatically switch to binary receive mode for files with this encoding." I don't think that's true. I think you have to set binary manually -- at least that's what we've all been doing since Day One. For more information, read pages 629, 630 of the owner's manual. -- Regards Ray Depew HP ICBD -- IC's by Bill and Dave rrd@hpfitst1.hp.com Disclaimer: I don't make calculators, I just use them, same as you.
NELSON%VWSCYG@vmsd.oac.uci.edu (Matthew A. Nelson) (01/09/91)
> >> Can someone please help me? I am trying to doenload a program from >> Compuserve to my HP48SX. > >[stuff deleted] > >> Compuserve to my PC and Kermit from my PC to my calculator. The file is >> in binary form and when I transfer it to my calculator, it is stored >> as a string which looks like this: "HPHP48-B....." > >You forgot to set your calculator to "binary" mode. (Even if you think you >did, you really didn't! :-) ) The clue is your statement that the program >appears as a string beginning with "HPHP48-B.....". This is the header for >binary HP-48 files stored outside the 48. ASCII files start with a header >similar to "$$HP: T(3)A(R)F(.);" I get tired of seeing "you dont know what youre talking about; you have NOT set your calculator to binary mode, regardless of what you SAY you did" responses to these questions. Why? Well, I had the same problems. I FTP'd a binary file to my VAXstation in BINARY mode, then kermitted the file to my 48 in BINARY mode and still got the "HPHP48-x...." business. Please don't try to tell me that I didn't. The problem, for me, was that when using VAX/VMS, you have to use space parity (7-bit mode) since kermit-32 has a bug in it. When I moved over to a DECstation and c-kermit, the "HPHP48x..." stuff went away. You might be saying, "well, if you use 7-bit mode OF COURSE you will just get an ascii file, since you can't send full bytes" (or something). Well, how does one explain the fact that I was doing frequent archives/restores SUCCESFULLY using the VAX and 48 in space-parity mode? If I upload using space parity, I can download it, but if I try to download someone elses file (presumably done with 8-bit trasf. mode), I get trash. just my .02. -matt [stuff deleted] >Regards >Ray Depew >HP ICBD -- IC's by Bill and Dave >rrd@hpfitst1.hp.com >Disclaimer: I don't make calculators, I just use them, same as you.
jurjen@cwi.nl (Jurjen NE Bos) (01/09/91)
rrd@hpfcso.HP.COM (Ray Depew) writes: >Nope, it's at the last link in the chain: the calculator. According to the >owner's manual, "A receiving HP 48 treats all files as ASCII unless they match >the special encoding generated for HP 48 binary files. The calculator will >automatically switch to binary receive mode for files with this encoding." >I don't think that's true. I think you have to set binary manually -- at least >that's what we've all been doing since Day One. I doesn't matter what mode your HP48 is in. The manual is absolutely right. What is the case, is that the file has been sent in ASCII form at least once in the chain. This modifies the file a tiny bit, but so much that the HP48 recognized it has been modified. It will try to receive it as binary, but fail. The result is then put in a string. So remember: if you have a binary file, handle it in binary mode with EVERY program in the chain! You lose information that you can't get back! (And don't blame the calculator... it is just doing its work :-)
rrd@hpfcso.HP.COM (Ray Depew) (01/10/91)
In comp.sys.handhelds, jurjen@cwi.nl (Jurjen NE Bos) writes: > So remember: if you have a binary file, handle it in binary mode with EVERY > program in the chain! You lose information that you can't get back! > (And don't blame the calculator... it is just doing its work :-) I stand corrected -- and the manual stands vindicated. (Well, I was almost right...) Ray
madler@pooh.caltech.edu (Mark Adler) (01/10/91)
One possible reason to see "HPHP48-B ..." (or -A, -C, -D, -E) is that somewhere along the way garbage ended up on the end of the file. For example, Vaxes like to make files a multiple of 512 bytes. Even if the data is there, bit for bit, if the length is wrong, the HP won't recognize it as a special object, and will simply make it a string. Mark Adler madler@pooh.caltech.edu
NELSON%VWSCYG@vmsd.oac.uci.edu (Matthew A. Nelson) (01/10/91)
> >In a posting of [9 Jan 91 15:07:00 GMT] > NELSON%VWSCYG@vmsd.oac.uci.edu (Matthew A. Nelson) writes: > > > You might be saying, "well, if you use 7-bit mode OF COURSE you will > > just get an ascii file, since you can't send full bytes" (or > > something). Well, how does one explain the fact that I was doing > > frequent archives/restores SUCCESFULLY using the VAX and 48 in > space-parity mode? > > When you archive and restore, the HP-48 automatically enters binary >mode. Since in the kermit protocol, the transmitting end determines >what parameters are used (i.e. binary/crc/etc), this is sufficient - >the receiving end adapts to the HP-48. In the portion of my letter that you ommitted, I specifically asked that you please not tell me that I didn't set up for binary transfer. I know how to do this; back when I had my Amiga, I downloaded literally hundreds of floppies worth of binary material. -matt nelson (nelson@psroot.ps.uci.edu) > -- Jan Brittenson > bson@ai.mit.edu
bson@rice-chex.ai.mit.edu (Jan Brittenson) (01/11/91)
In a posting of [10 Jan 91 15:03:00 GMT] NELSON%VWSCYG@vmsd.oac.uci.edu (Matthew A. Nelson) writes: > In the portion of my letter that you ommitted, I specifically asked > that you please not tell me that I didn't set up for binary transfer. > I know how to do this; back when I had my Amiga, I downloaded > literally hundreds of floppies worth of binary material. Knowing how to "set up for binary transfer" is not the same as knowing how the kermit protocol works. There is enough leeway in the protocol that settings that work between two Amigas may not work between two Vaxen or between an HP-48 and an Amiga. Also, I wasn't responding to you specifically, but to your question canonically. If I wanted to respond to you personally, I would have sent you e-mail. This is a public forum, not an exchange of letters. -- Jan Brittenson bson@ai.mit.edu ;; The distinction between a hack and a hacker is that the hack works ;; for the money; the hacker works for the hack.
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (01/12/91)
Well, instead of arguing, I tried an experiment. I tried two archives, both
with the HP-48 set to space parity and VMS Kermit set to space parity, file-type
binary. I did one archive with the HP-48 set to ASCII and one with it set to
binary. I got two different files on the VMS system, with these different
record characteristics:
HP-48 in binary HP-48 in ASCII
format variable length, variable length,
maximum 510 bytes maximum 3786 bytes
attributes none carriage return carriage control
Furthermore, the file created by the ASCII transfer could not be successfully
transferred back to the HP-48, with either the original settings or with both
sides set to binary. (The transfer always yielded a string rather than a backup
object.) Therefore, it is important to set the file transfer mode on the HP-48
when doing an archive; the archive does not automatically override the setting
and force a binary transfer (at least not a proper binary transfer as VMS Kermit
requires it).
-- edp (Eric Postpischil)
"Always mount a scratch monkey."
edp@jareth.enet.dec.com