fin@norge.unet.umn.edu (Craig A. Finseth) (03/22/90)
The HP-48SX must receive a binary file as the exact length intended. Extra nulls after the contents to fill out a 128 byte block, as are frequently inserted by XMODEM packages, will result in the incoming binary data stored as a string on the stack, not put into a data object as expected. Struggled with this one for a while and thought others might want to know. Thanks to Brian Walsh, Jake Schwartz, and Al Duba for their assistance in the investigations. Posted for: Peter Steinmetz <peter@neuro.med.umn.edu> Posted by: Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 626 1002 FAX 130 Lind Hall, 207 Church St SE, Minneapolis MN 55455-0134, U.S.A.
jmunkki@kampi.hut.fi (Juri Munkki) (03/22/90)
I have so far been unable to correctly download any of the PCLINK files that are archived at gmuvax2.gmu.edu. Only the APPT program, which by the way is ASCII, is accepted by my HP. I switched to using VersaTerm Pro, when I discovered that when I set both ends to use odd parity and binary kermit, I'm able to make and restore backups successfully. Being forced to use parity checking is probably related to the bit-8 prefix problem I discovered earlier. Has anyone else successfully downloaded the PCLINK programs? When I got them, the APDIR file was there, so someone must have found it after all. I did a lot of hacking trying to salvage my broken backups (ending up wasting three times more time than it would have taken to key in all the stuff). I almost got the backup working by stripping the HPHP48 stuff and then changing the object type with the hex debugger. Of course the restore process crashed and asked if I wanted to try to recover memory. Doing this found one directory that was previously lost. I haven't found any new bugs, but I wonder why the quick reference guide says that you have to OPENIO before using kermit. It looks like this kermit implementation hasn't been frozen long enough. HP should start giving ROM revision A owners 128KB RAM cards with preloaded fixes for all the bugs. This way when new bugs are found we could just use the file transfer utilities to distribute them from user to user and everyone would be happy. Creating a machine with 256KB ROM and trusting that it doesn't have serious bugs is crazy. Buying such a machine is stupid. I feel stupid right now after two days of fighting with the kermit. What kermit is HP going to distribute with the Macintosh Kit? I know that the latest version of MacKermit doesn't work. Do they have a version that works around all the problems in the calculator? (like KGETting 0-sized files and all the bugs I have described.) ___________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / HP S / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / 48 X / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
madler@tybalt.caltech.edu (Mark Adler) (03/22/90)
Oops. My fault---it seems I didn't achieve binary mode in the kermit transfer from my PC to my NeXT. I redid it all, re-ftp'ed it to gmuvax2.gmu.edu (in "new"), and then reversed the process all the way to my calculator to make sure it all worked. It does. Here is the list of files and their proper lengths, as they are on gmuvax2: -rw-r--r-- 1 ftp 13713 Mar 21 23:40 apdir -rw-r--r-- 1 ftp 124 Mar 21 23:40 appt -rw-r--r-- 1 ftp 4924 Mar 21 23:40 appt.txt -rw-r--r-- 1 ftp 6877 Mar 21 23:40 clk -rw-r--r-- 1 ftp 9402 Mar 21 23:40 clk.txt -rw-r--r-- 1 ftp 1229 Mar 21 23:40 epsprint.lib -rw-r--r-- 1 ftp 4770 Mar 21 23:41 epsprint.txt -rw-r--r-- 1 ftp 5472 Mar 21 23:41 grob2tif.exe -rw-r--r-- 1 ftp 1363 Mar 21 23:41 grob2tif.txt -rw-r--r-- 1 ftp 865 Mar 21 23:41 inprt -rw-r--r-- 1 ftp 2660 Mar 21 23:41 inprt.txt -rw-r--r-- 1 ftp 47117 Mar 21 23:42 pclink48.tar.Z -rw-r--r-- 1 ftp 1136 Mar 21 23:42 pclprint.lib -rw-r--r-- 1 ftp 4781 Mar 21 23:42 pclprint.txt -rw-r--r-- 1 ftp 2831 Mar 21 23:42 stpwatch.lib -rw-r--r-- 1 ftp 3936 Mar 21 23:42 stpwatch.txt -rw-r--r-- 1 ftp 1401 Mar 21 23:42 usag -rw-r--r-- 1 ftp 3822 Mar 21 23:42 usag.txt Just by the way, I have had no problems with the HP-48SX kermit, except for the Lost Memory problem (there are other situations besides bringing in a zero-length file that causes it). I always use three character "checksums" however. I've not tried the one or two character checksums. (For the edification of kermit users, the reason I blew the transfer the first time is that I didn't realize that the kermit being served is the one that controls the file type (text or binary), so setting binary before "serv" on the mainframe kermit had no effect.) Mark Adler madler@hamlet.caltech.edu
sterling@cbmvax.commodore.com (Rick Sterling) (03/22/90)
In article <1990Mar21.225133.2561@santra.uucp> jmunkki@kampi.hut.fi (Juri Munkki) writes: > [ text deleted] > Creating a machine with 256KB ROM and trusting that it doesn't have > serious bugs is crazy. Buying such a machine is stupid. I feel stupid > right now after two days of fighting with the kermit. > > What kermit is HP going to distribute with the Macintosh Kit? I know > that the latest version of MacKermit doesn't work. Do they have a > version that works around all the problems in the calculator? (like > KGETting 0-sized files and all the bugs I have described.) > For what it's worth ... I've been using VLT on my Amiga and have had flawless bi-directional transfers with Kermit at 9600 bps. The only problem to date was with the files that HP munged on their BBS by using Xmodem ( files padded to 128 modulus ) ... after sending a note to Meghas at HP the BBS files were fixed and they downloaded to my 48 just fine... all I need now is MORE MEMORY!!! sheesh. ;-) Rick Sterling Commodore Technology Group Test Engineering UUCP ...{uunet,allegra,rutgers}!cbmvax!sterling
alonzo@microsoft.UUCP (Alonzo GARIEPY) (03/24/90)
In article <1990Mar21.225133.2561@santra.uucp> jmunkki@kampi.hut.fi (Juri Munkki) writes: > Creating a machine with 256KB ROM and trusting that it doesn't have > serious bugs is crazy. Buying such a machine is stupid. I feel stupid > right now after two days of fighting with the kermit. If HP relied on trust for quality assurance, I doubt they would have the reputation for excellence they do. Your statement might be rephrased: it is impressive how few bugs remain in such a complex piece of software as the HP 48. I don't think you should feel bad for buying this machine. I have had no trouble with the kermit. Perhaps you should use slightly different parameters. Bill Wickes has already implied that HP will satisfy any customer who is having major problems, so do not despair. Alonzo
jmunkki@kampi.hut.fi (Juri Munkki) (03/24/90)
In <53747@microsoft.UUCP> alonzo@microsoft.UUCP (Alonzo GARIEPY) writes: >jmunkki@kampi.hut.fi (Juri Munkki) writes: >> Creating a machine with 256KB ROM and trusting that it doesn't have >> serious bugs is crazy. Buying such a machine is stupid. I feel stupid >> right now after two days of fighting with the kermit. > >If HP relied on trust for quality assurance, I doubt they would have the >reputation for excellence they do. Your statement might be rephrased: >it is impressive how few bugs remain in such a complex piece of software >as the HP 48. It is impressive. If it is possible to patch the existing ROM with RAM routines, I'll accept the current implementation as good. If the can't patch the bugs, they will have to replace quite a few calculators some day, when more bugs are found. It will take time to find the more subtle bugs. >I don't think you should feel bad for buying this machine. I have had >no trouble with the kermit. Perhaps you should use slightly different >parameters. Bill Wickes has already implied that HP will satisfy any >customer who is having major problems, so do not despair. I don't feel bad. After all, I'm "advertising" it in my signature file. This little computer has great potential once all the internals are known and third party developers will start producing machine coded application ROM cards. RPL is too slow for good interactive control of the display. The bit-8 prefixing bug turned out to be in VersaTerm Pro, which is quite surprising, since a lot of people use that program. It was the bug I described, it just wasn't the HP's fault. The problem is that when 8 bit communication is possible, a 'Y' is sent instead of the normal quote character. Every kermit implementation has to recognize this character as a sign that the quotes aren't used. What VersaTerm didn't do correctly was that it went on to handle the 'Y' characters in a special way: it used the special character (also used to make control characters) quote whenever a 'Y' was found. So instead of sending "Y", it sent "#Y", which is interpreted as ctrl-Y or ASCII code 25. My apologizies to anyone who wants them. This bug was just a theory anyway, since I couldn't get debugging information from VersaTerm. The packet size problem seems to be related to bad send-init handshaking on the part of the HP. We are still looking into this. As to the bad checksums: I'm still getting them and I don't have a clue. It might be that they are also related to this handshake problem. I'll post a more thorough description when more is known. I haven't taken a deeper look at the problems I'm having with MacKermit (which should at least be a good implementation of the protocol, since it comes from Columbia University). At least one problem was that unless I opened the file defaults dialog, MacKermit wouldn't notice that the settings file had binary transfer as the default. Even with this problem corrected, none of the PCLINK binaries are transmitted correctly. Fortunately VersaTerm works, if I use parity checking to get rid of the 'Y' problem. I still wonder what HP distributes with the Macintosh Interface Kit. It's also good to know that White Knight works. I wanted to try an old version of that program (Red Ryder), but since it wouldn't talk to the printer port, where I have the HP connected, I didn't try it after all. One more thing: Even with its bugs, I like the HP48SX very much. It also seems that I'm the only one who is seeing problems, but that might be just because there are so few serial cables out there yet. HP has done some thorough testing with PC kermit, so PC users probably won't see any of the problems that I have. That doesn't mean that PC users are allowed to send me obnoxious mail telling me to "buy a real computer". I'm not attacking HP, I'm just trying to solve some problems. ___________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / HP S / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / 48 X / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jmunkki@kampi.hut.fi (Juri Munkki) (03/25/90)
This is probably my last posting on this subject. My own kermit now talks with the HP and I know why VersaTerm didn't work in 8 bit mode. The bad checksums and packet length problem turned out to be handshaking problems. My configuration packet contained a null where there should have been a space. This was fine for the C kermit in the unix host, but the HP kermit was more picky. This caused the HP kermit to resend its send init packet to which my kermit just sent an acknowledgement packet, because it already saw a good init packet. The HP never received a complete receive init packet. In this case, there was nothing really wrong with the HP. The problem with VersaTerm also appears to have been an init handshake problem. When VersaTerm sends a Send-init, it specifies bit-8 quoting. Normally everyone else is then also forced to use some sort of quoting. HP kermit is funny in that it sends 'Y' anyway. It uses bit-8 quoting, since the other end requested it, but it doesn't give the correct prefix character. Since VersaTerm has already requested prefixing, the HP kermit shouldn't argue against that. This is a very subtle bug in the HP kermit and doesn't hurt anything, if your kermit understands what the 'Y' means. I gave up on MacKermit. I don't recommend it. If you use VersaTerm, use 7 bit transmission with some sort of parity. ___________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / HP S / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / 48 X / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~