frechett@spot.Colorado.EDU (-=Runaway Daemon=-) (01/31/91)
We need Zmodem. I know this sounds crazy but so does most of the other things that have been done on the hp48sx. ;) After spending several hours with my hp48 plugged into the back of a Sun, logged into another computer and kermiting stuff all over hell, and back, I find that kermit sucks.. Gotta love the error checking but it sure makes it slow. I didn't time it but I just did an archive of my calculator (1220 kermit packets) and it was dreadfully slow. And that was at 9600 baud. I can't imaging how long it would take to do at 2400 baud over the modem at home. (No PC) I feel that a new transfer protocol would be nice. I am beta testing machine language programs and have already lost my memory once.. I am an impatient guy and kermit really bugs me. One thing that I wondered about is if anyone happens to know if changing the checksum type changes the speed of kermit. Anyone know? ian -- -=Runaway Daemon=-
zlraa@marlin.jcu.edu.au (Ross Alford) (01/31/91)
In article <1991Jan31.015953.18380@csn.org> frechett@spot.Colorado.EDU (-=Runaway Daemon=-) writes: > >We need Zmodem. I know this sounds crazy but so does most of the other >things that have been done on the hp48sx. ;) After spending several hours >with my hp48 plugged into the back of a Sun, logged into another computer and >kermiting stuff all over hell, and back, I find that kermit sucks.. >Gotta love the error checking but it sure makes it slow. I didn't time >it but I just did an archive of my calculator (1220 kermit packets) and >it was dreadfully slow. And that was at 9600 baud. I can't imaging how long >it would take to do at 2400 baud over the modem at home. (No PC) > Believe it or not, it wouldn't take much longer. The overhead in a Kermit transfer is apparently so high that baud rates above 2400 don't really seem to speed things up too much. The packets in standard Kermit are limited to a maximum of something like 92 bytes, and *lots* of handshaking is done for each packet. I do a lot of file transfers between my laptop and a Decstation, and have timed it at about 8-10 kbytes/minute at 9600 baud, which is astonishingly bad. At 2400 baud it runs much closer to the potential bit rate, but still only about 65% or so. I doubt that changing the packet-check type would make much difference. What would make a difference is incorporation of a Kermit protocol that allowed extended-length packets. The latest versions of C-Kermit and MS-Kermit both allow packets to be up to 1024 bytes long. Setting packet-length to a large size improves my laptop transfer rate to about 20k bytes/min at 9600 baud. Still only about 40% or so of what's possible, but a real improvement. I now use Ymodem for my laptop. Ymodem uses 1024 byte packets and obviously has a lower overhead/packet that Kermit, since it runs at about 50kbytes/minute over a 9600 baud serial line. It has the advantage over Zmodem that it is *much* easier to implement, ends up being much smaller, and is neraly as fast if bit errors are rare. I'd suggest it for a HP extension over Zmodem for those reasons. Ross Alford zlraa@marlin.jcu.edu.au
jpser@cup.portal.com (John Paul Serafin) (02/01/91)
HP-71's (sold to a few discerning individuals and companies during the early 1980's) exchange data over HPIL at over 6000 BYTES per SECOND. The CPU on the HP-71 is an ancestor of the HP 48 running at 600kHz. With HPIL there are no pinout problems, no handshaking options to fool with, no connector gender problems, no ASCII vs binary worries. By the way, HP 48 archives go much faster in binary mode. John Serafin | Operating a car is more like riding than driving, jpser@cup.portal.com | operating a bike is more like driving than riding.
EBERBERS%yubgef51@pucc.PRINCETON.EDU (____ Zarko Berberski ____) (02/01/91)
> After spending several hours > with my hp48 plugged into the back of a Sun, logged into another computer and > kermiting stuff all over hell, and back, I find that kermit sucks.. Actually the Kermit itself is OK its just that HP have limited packets to 94by. If HP-48 had relly complete Kermit you could use 8196by packets and no Zmodem would be able to beat it. Zarko Berberski EBERBERS@YUBGEF51.bitnet
akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (02/03/91)
John Serafin says
> HP 48 archives go much faster in binary mode.
Isn't archiving only possibly with binary mode? And, by the way,
everything is faster in binary mode.
---Falcobson@rice-chex.ai.mit.edu (Jan Brittenson) (02/03/91)
It appears to me that the HP-48 cannot sustain a feed of 9600 bps. Effectively, it seems to be capable of roughly 3600-4800 bps. Extending the packet size probably won't help much, since it will likely just increase the delay. Now some advantages of Kermit: it has been around for a long time, people know how it works, it doesn't rely on any patented compression algorithms, it can cope with systems that have different word sizes, bit orderings, character sets, and communication subsystems. Its strength is that the specification is not based on any specific machine or system, but rather that it's a general independent protocol. The C code is relatively easy to port. Kermit also exists on damned near every system I can care to name, including VM/CMS, Primos, even RSX-11M. It would be utterly cool if someone implemented Ymodem, or FTP, or whatever - I would be the first to love it! But I also hail HP for putting the Kermit protocol in ROM in the first place. -- Jan Brittenson bson@ai.mit.edu ;; "Make sure the brain is connected before the mouth is started."