Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!sunic!tut!santra!kampi.hut.fi!jmunkki
From: jmunkki@kampi.hut.fi (Juri Munkki)
Newsgroups: comp.sys.handhelds
Subject: HP48SX Kermit Problems
Message-ID: <1990Mar21.003623.29652@santra.uucp>
Date: 21 Mar 90 00:36:23 GMT
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@kampi.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Lines: 55

I'm having problems with the HP48SX kermit. I just did a total reset without
first checking that my backups were ok. Now I discover that the backups are
received as strings and not backup objects as they should be.

I have implemented my own kermit, so I know some of the pitfalls. My own
kermit does not work with the HP. This might be my fault, since MacKermit,
VersaTerm Pro and MicroPhone all seem to work fine. I say they seem to
work, since I have now discovered some problems.

First, let me tell about the bugs that I found when I tried to make my
kermit implementation work with the HP in binary mode:

1) If the 6-bit checksum is used, the HP often calculates a checksum that
   is incorrect. This value is quite close to the correct value (the
   difference is two). This happens only in binary mode with 7-bit
   transmission and ctrl-character prefix.

2) If the other end specifies a packet length shorter than 80 characters,
   the HP just ignores this and sends 80-character packets. Fortunately
   most kermit implementations accept this. I just tried smaller packets
   to make debugging easier: it didn't work!

The first one is the reason why the HP kermit will not work with mine. If
I modify my program so that it accept the incorrect checksum, everything is
fine. I don't want to make that modification to my program. I verified the
checksums by hand. My calculations agree perfectly with my program.

The third problem came up when I used an 8-bit connection between
VersaTerm and the HP kermit. This time "Y" characters were lost. Now
this is something that is familiar to me, since I had this bug in my
kermit when it was still in it's alpha-testing. The problem is that it
is perfectly legal to tell the other end that the bit-8 prefix is "Y".
If both ends agree, no prefixing will be done for characters with bit 8
set. When the HP interprets a "Y" as a prefix, it looses the Y and the
next character. This problem affects binary and text transmission

I assume that something like this is also making my backups unusable.
For some reason, some short binary files transfer ok (like the inprt
program and the peek and poke programs that I uuencoded).

Now do I get new ROMs because of these problems? Probably not, but I
wish I would. I hope I'm wrong about these bugs and that the HP kermit
is ok after all. It just looks like I've found some nasty bugs.

I'm getting sick of kermit. They tell me that kermit should work
through anything, but all these new additions to kermit (like windowing
and crc checksums) allow bugs to creep in commercial distributions. As
you all know, kermit may not be sold for profit, so we have a lot of
unofficial kermit implementations. XMODEM works a lot better, although
it has its faults (like requiring a pure 8-bit connection).

   ___________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  /   HP S /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /   48 X /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~