SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (09/08/86)
Info-Kermit Digest Mon, 08 Sep 1986 Volume 5 : Number 6
Today's Topics:
New Kermit for HP-1000
New Release of Sperry-1100 Kermit
New Kermit for Use with Microsoft Windows
More Kermit Diskettes Available
MSBPCT.ASM
Amiga Kermit Initialization
Kermit Documentation in French
Review of MS Kermit 2.29 vs ProComm 2.3
Kermit on IBM MVS/XA?
Suggestions for Fortran Port
----------------------------------------------------------------------
Date: Wed 3 Sep 86 17:23:51-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: New Kermit for HP-1000
Keywords: HP-1000 Kermit
This is to announce a new Kermit program for the HP-1000 running either
RTE-6 or RTE-A, replacing both of the two earlier HP-1000 programs, as
discussed in Info-Kermit V4 #xxx and #yyy. This program was submitted by
Paul Schuman of E-Systems, Inc, Greenville, Texas, who has also contributed
it to the appropriate HP user groups. The files are in KER:HPM*.*.
Binaries (for RTE-A) are in KB:HPM*.*. The old versions have been moved to
KO:HP*.*.
------------------------------
Date: Wed 3 Sep 86 17:37:23-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: New Release of Sperry-1100 Kermit
Keywords: Sperry
This is to announce version 2.5 of Sperry 1100 Kermit from pAaul sTevens at
the University of Wisconsin. The changes include conditional assembly to
make it easier to port to "standard" Sperry systems, increased maximum
record size from 800 to 2000, and error corrections. The source file,
in Sperry assembler, is in KER:UNIVAC.ASM.
------------------------------
Date: Sun 10 Aug 86 10:21:58-EDT
From: Bill Hall <OC.AMS@CU20B.COLUMBIA.EDU>
Subject: New Kermit for Use with Microsoft Windows
Keywords: Microsoft Windows, MS-DOS Kermit
I have developed a simple version of Kermit to run under Microsoft Windows.
I will be sending you the files via the mails on a floppy disk for you to
try. It is strictly bare bones, but the multitasking aspect is really nice.
If you will put it on the system, I will maintain it and develop it further.
[Ed. - Thanks Bill! The diskette was received, and the files have been
placed in KER:WIN*.* on CU20B. Although this program is bare-bones (no
help, only dumb terminal emulation), it runs a lot faster under MS Windows
than regular Kermit does, and it has the advantage that it can be run in
several windows at once, for instance transferring two files simultaneously,
one on COM1 and the other on COM2, all in the background while doing other
work in the foreground. The program is written in Microsoft C v4.0 (Windows
aware), using the supplemental Windows libraries, the Microsoft Resource
Compiler, and LINK4 v5.02. It takes advantage of MS-Windows' built-in comm
and screen drivers, and is thus usable on any system that runs Windows. It
requires a lot of memory and only runs at speeds up to 2400 baud. It has
several typical Windows menus so a mouse is a near necessity. This Kermit
program should not be confused with the other "Windows Kermit" for the PC
(WKERMIT), which implements windows in the other sense of the word, namely
the sliding window transport-level protocol. The executable program is
KER:WINKRM.BOO, in Boo-file format, which can be translated to and .EXE
file using any of the KER:MSBPCT.* programs. The 8-bit binary .EXE file
is available in KB:WINKRM.EXE, for those sites that can transfer such files
directly from CU20B.]
------------------------------
Date: Sun, 17 Aug 86 17:06:41 pdt
From: Randy Spencer <spencer@usc-oberon>
Subject: More Kermit Diskettes Available
Keywords: Kermit Diskettes
This is a copy of the letter I sent out to net.micro.amiga. I am sending
it to you because I just noticed the file AADISK.HLP on CU20B and would
like to be included...
I am willing to send you a copy of Kermit for the IBM, C64, or the Amiga.
These are the most recent versions available from Columbia. Send me $6.00
and your mailing address to:
Randy Spencer {Keeper of the Kermits}, Box 4542, Berkeley CA 94704
^^^^^^^^^^^^^^^^^^^^^optional
I prefer checks, they make good receipts. I *will* include the sources for
Amiga Kermit on the disk I send. I will include the sources for the IBM
Kermit if requested (but it is so hard to keep up with the changes, and I
cannot be sure that it will compile as I have not got all the compilers for
the IBM (I am just using the transformer)). The sources for c64 Kermit will
not compile on the c64 (they were compiled on a mainframe) so there is
little use in downloading them. There are some other utilities on the disk
and the .boo file is included if you want to modem someone else a copy of
the file.
Randy Spencer
[Ed. - Thank you for offering to distribute Kermit on diskettes, Randy.
Your name and terms have been put in the file KER:AADISK.HLP. Are there
any other volunteers for micros we do not already have listed?]
------------------------------
Date: 27 Aug 86 14:14 EDT
From: junod@dtrc.ARPA (John Junod)
Subject: MSBPCT.ASM
Keywords: .EXE files
I have just completed a reconstruction of Kermit on a DEC Rainbow using the
MSVRB1.BOO file. The target machine had a Vanilla MS-DOS disk without BASIC
or a Terminal Emulator with file transfer. It did have MASM and LINK. I was
able to capture the BOO file by using "copy aux mskermit.boo" (and you could
capture the msbpct.asm file by using "copy aux msbpct.asm") and sending a
control-z at the end from another MS-DOS machine connected to the Rainbow's
communication port. Since I was unable to find an assembly version of MSBPCT
I wrote the following to reconstruct MSKERMIT.EXE. (Note: you must have the
source BOO file on the default drive as MSKERMIT.BOO and the output will
always be MSKERMIT.EXE on the default drive.
If necessary do a "copy" or "rename" of your capture file before running the
assembled MSBPCT.ASM)
Regards,
John Junod
Code 1821
David Taylor Naval Ship R and D Center (DTNSRDC)
Bethesda, Md 20084-5000
[Ed. - Thanks John! The file is in KER:MSBPCT.ASM.]
------------------------------
Date: Fri, 05 Sep 86 01:50 EDT
From: CCPHIL@TUCC
Subject: Amiga Kermit Initialization
Keywords: Amiga Kermit
Cross-Ref: Commodore Amiga (see also Amiga Kermit)
I have found the following kermit initialization file useful for the Amiga,
when you want to emulate a standard ANSI terminal (like a VT100). I have
used this with a PCI protocol converter and also a VAX VMS system. The PCI
works well, but the VAX has problems in EDT when lines need to be scrolled
up from the bottom of the screen.
Note that the Amiga Kermit will configure itself based on the settings in
the Preferances screen for the serial line. Insert the following lines into
a file s:.kermrc :
%
% Set up to 80 columns by 24 rows, position to (0,0), & clear screen
%
echo \\033[25t\\033[80u\\033[0x\\033[0y\\014
%
echo Kermit is initialized and 80x24 ANSI screen!
------------------------------
Date: Thu 4 Sep 86 16:12:48-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Kermit Documentation in French
Keywords: French Kermit Documentation
A translation into French of the first part of the Kermit User Guide appears
in CiSi telematique's "Bulletin Technique", numbers 86/05-06 and 86/07-08,
available (I'm not sure how) from CiSi telematique, 35 Boulevard Brune,
75680 Paris CEDEX 14, phone (1)45.45.80.00. Thanks to Gerard Gaye.
------------------------------
Date: 22 Aug 86 05:23:44 GMT
From: pete@octopus.UUCP (Pete Holzmann, Octopus Enterprises, Cupertino, CA)
Subject: Review of MS Kermit 2.29 vs ProComm 2.3
Keywords: MS-DOS Kermit, ProComm
THANK YOU to the many who responded to my recent request for info on
communications programs that properly handle flow control. This is a summary
of the responses and my subsequent experience:
The responses were almost unanimous in recommending either ProComm (2.3 is
the latest version) or MS-Kermit (2.29 is the latest). A kind soul sent me
MS-Kermit, and I picked up ProComm locally.
A review of the two:
Kermit: lots of options, but not really as flexible as the number of options
might lead one to believe. Comes with one terminal emulator (VT102) and only
one file transfer protocol (Kermit, no sliding windows). Can use 38.4
KBaud, a win. Drives my LCD display at about 6 Kbaud. User interface isn't
too bad once you know how to use it, but it is not at all intuitive (you
must 'Cancel Connection' to get to command mode, and that doesn't *really*
break the connection, fortunately!). No dialing directory or other
niceties, although you *can* push into DOS. File transfers are slooooowwww.
Running between two 8 MHz AT's at 38.4 KBaud, I could only push through
about 300 bytes a second!!! Rather poor. However, I didn't find any bugs.
It may not do a whole lot, but it works.
[Ed. - Actually, PC Kermit comes with 3 terminal emulators built in -- VT52,
H19, and VT102 -- plus the ability to run with external terminal device drivers
like ANSI.SYS or whatever. 2.29 is slightly slower than some previous
releases, but not THAT slow! See below...]
ProComm: Great user interface, lots of terminal emulations, lots of transfer
protocols, lots of niceities including dialing directory that can also link
to destination-specific command files (for auto-login, etc). Color,
windows, (even sound if you can stand it). Very fast file transfers (even
good in Kermit, with sliding windows, but slower than the other protocols).
It is a 'shareware' program (kermit is from a University, presumably more
altruistic). BUT A BIG BOO for all the bugs. ProComm has a strong tendency
to lock up. More so on AT's, but also on PC's. It can happen when you
aren't doing anything, it can happen during file transfer, it can happen due
to problems in terminal emulation, it can happen... you get the idea. I've
posted another article asking for help with these problems. I just can't
trust ProComm. Otherwise, it would be the greatest thing since sliced
bread.
[Ed. - Kermit has color too...]
Actually, there's two wish-list features I wish could be added to
ProComm or some other program:
1) Conditional branching and user-input in command files, similar to
some of the capabilities of CrossTalk.
2) Putting something like CWEEP into the comm program, so that one
could easily select the files to be block-transferred. It would make
unattended operation MUCH more useful! It would even be better if you
could grab filenames off the screen (so you could get a remote
directory, then just point at the files you want to download).
Again, thanks for the help! (My current status: using ProComm in general,
but using MS-Kermit when it is important that the job get done right without
system-reboot hassles).
[Ed. - The following comments about MS-DOS Kermit 2.29 performance on the
IBMs and clones come from Joe Doupnik, who put together version 2.29 and
is working on a new release, 2.29A]
At 38400 baud the effective speed ought to be well above 9600 baud (like
14-16Kb or so). That's for the new version (2.29a) whereas the release
version (2.29) is the normal slow poke (say 3000 but not quite 300 baud).
MSKermit 2.29 is slower than 2.28 (please speed up if possible). Well, the
test version of 2.29 on the previous disk is much faster than 2.28. As an
example, transferring a plain text file, mssscp.asm in fact, between two
regular IBM PC clones at 9600 baud this morning took:
132 seconds with MSK 2.28
67 seconds with MSK 2.29a/test same packet length as 2.28
That's a 2:1 speedup! Lower baud rates achieve less dramatic factors since
the transmission time is a greater proportion of the whole. 2.29a
at 38400 baud works, but the higher efficiency did not come cheaply.
Some additional comments since I have focused on that topic recently. The
measured overhead of new 2.29a to move a character from one ramdisk to
another is close to 350 microseconds per character plus the time sending the
data on the comms link. The per character time includes the major factor of
time doing (s-l-o-w) DOS file calls. I overlap as much packet construction
and decomposition as possible with i/o without going to extreme measures
(read that as expanded buffering + management code). Screen writes are time
consuming but are less so now. The release 2.29 (and earlier releases) had
high overhead associated with clock timing (for timeouts); this version does
not. Earlier versions had real trouble with the serial port at high speeds;
this version has code written for high speeds. A problem with all comms
programs is that items hanging on the clock tic block interrupts from the
serial port and cause data loss. Examples are print spoolers, keyboard
enhancers, screen savers, pop up helpers, and so forth; it is amazing how
much time they eat. With a scope attached to the comms line I observe a
series of 1000 byte packets to use 1.34 +/- seconds from ACK to ACK at 9600
baud; hence the timing figure above. This is on a regular 4.77 MHz PC and
translates into an efficiency of 75% on the comms line. In the test case of
transferring MSSSCP.ASM from hard disk to a ramdisk the new version gave a
throughput of about 507 bytes/sec (5000 baud, 33950 bytes div 67 seconds)
end to end (or about 7200+ on the comms line) including all overhead of
prefix encoding chars, screen updating, packet header bytes, etc. I think
the new Kermit will beat many or most X-modem implementations (certainly the
ones I have). So, Kermit's efficiency is up this time around, and it can
run at much higher speeds than before.
------------------------------
Date: Thu 4 Sep 86 10:04:46-EDT
From: Walter V Dixon Jr <EXT1.DIXON@CU20B.COLUMBIA.EDU>
Subject: Kermit on IBM MVS/XA
Keywords: MVS/TSO Kermit?
Another GE site is trying to use an MVS version of Kermit under XA. They
are getting an ijkmsg SYSDA not allowed. Is there anyone they can call to
get help solving this problem?
Thanks
Walt Dixon
------------------------------
Date: Mon, 18 Aug 1986 01:49 PDT
From: "Jeffrey Sicherman" <JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU>
Subject: Suggestions for Fortran Port
Keywords: Fortran Port
I would appreciate some advice from anybody who has done a kermit
port/implementation in FORTRAN or who is familiar with one or more of the
FORTRAN implementations.
The machine is a minicomputer and has an old FORTRAN compiler ... Fortran
IV (which corresponds to FORTRAN 66, I think) and I would like
recommendations on which of the existing versions would be easiest to
convert. I could edit some new IF constructs, etc., but I wouldn't like to
use one if it was rife with such constructs. Maximum facilities would be
nice, but right now ease of conversion is primary. Please reply to me if
possible:
JAJZ801@CALSTATE.BITNET
Thanks for any help.
------------------------------
End of Info-Kermit Digest
*************************
-------