|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - download
Length: 180096 (0x2bf80)
Types: TextFile
Names: »KERMIT.DOC«
└─⟦82b4db2a8⟧ Bits:30007604 Kermit-80 - V3.22
└─ ⟦this⟧ »KERMIT.DOC«
KERMIT USERS GUIDE
Fourth Edition
Frank da Cruz, Daphne Tzoar, Bill Catchings
Columbia University Center for Computing Activities
New York, New York 10027
12 July 1983
Copyright (C) 1981,1982,1983
Trustees of Columbia University in the City of New York
Permission is granted to any individual or institution to copy or
use this document and the programs described in it, except for
explicitly commercial purposes.
Present address: Lehman Bros, Kuhn & Loeb, NYC
- 1 -
Preface to the 4th Edition
The Kermits are coming home to roost. Recipients of earlier Kermit distribu-
tions have sent back their own contributions. The 4th edition includes these,
plus additional work done at Columbia (where no attribution is made below, the
work was done at Columbia):
- KERMIT-32 was written for the VAX-11 running VMS by Bob McQueen at
Stevens Institute of Technology. KERMIT-32 can act as a server.
- KERMIT-65 was written for the Apple II 6502-based DOS system by An-
tonino Mione at Stevens Institute of Technology.
- KERMIT-10 now has CONNECT command, added by Vanya Cooper at Pima Com-
munity College in Tucson, Arizona.
- KERMIT-20 has various new SET options, load-dependent timeouts, im-
proved support for local operation (comforting messages on the screen
to show the file and packet traffic), expanded help and information
facilities, and the ability to issue commands to a Kermit Server
(KERMIT-20 could already act as a Kermit Server itself), expanded
debugging options, etc.
- Kermit-86 can now issue commands to a server, and can do wildcard
sends. Z100 support was added to Kermit-86 at Stevens Institute of
Technology.
- An adaptation of Kermit-80 was done by DEC for the Rainbow-100. This
is not the "real" Rainbow Kermit, but a stopgap. It will only work
at speeds up to 1200 baud. A similar adaptation was done for the
DECmate-II with CP/M.
- A "generic" version of Kermit-80 has been done, which should work on
any CP/M-80 system that implements the CP/M IOBYTE.
- An implementation of Kermit-80 was done for the TRS-80 II under CP/M
by Bruce Tanner at Cerritos College in Norwalk, California. Another
for the Osborne 1 by Charles Bacon at the National Institutes of
Health. And another for the Telcon Zorba by Nick Bush at Stevens.
- The SYMBOL cross assembler was "reTOPS10ized" at several sites, but
it has been dropped from the KERMIT distribution altogether in favor
of MAC80, an 8080-specific cross assembler that assembles KERMIT-80
much faster than SYMBOL could do, and produces a smaller hex file in
the bargain. SYMBOL was written in SAIL, which is never quite the
same on any two TOPS-10 or TOPS-20 systems; MAC80 is written in
MACRO-10, and doesn't require any special runtime support, and runs
with no problems under either TOPS-10 or TOPS-20. MAC80 was con-
tributed by Bruce Tanner.
- The RT-11 OMSI Pascal implementation contributed earlier by Philip
Murton of the University of Toronto was fixed up by Michael Weisberg
of Mt. Sinai Hospital in NYC to be self contained and complete, and
actually brought up on real RT-11 systems (the previously distributed
version was incomplete).
- 2 -
- The Columbia CS Department UNIX Kermit was updated to distinguish be-
tween "image mode" file transfers (e.g. UNIX-to-UNIX), and ordinary
transfers (in which newlines are mapped to CRLFs).
- 3 -
Preface to the 3rd Edition
For the 3rd edition, the Kermit manual has been reorganized to improve clarity
and to prune away a lot of redundant material. The wording and examples have
become less oriented to Columbia, and less towards programmers. Much new
material has been added as a result of new implementations of Kermit done at
Columbia and elsewhere, notably for TOPS-10, UNIX, and the IBM PC. Other ad-
ditions describe techniques for bootstrapping Kermit onto new systems, com-
plications arising from system bytesize mismatches, and a new simplified way of
running Kermit. The section describing the Kermit protocol has been moved to a
new document, the Kermit Protocol Manual.
Some material has been removed that described how to use certain systems. Due
to the proliferation of systems supporting KERMIT, it is no longer practical to
describe how to use each system. It is now assumed that the reader knows how
to log in and run programs on the systems involved, how to start a micro, in-
sert a floppy disk, and so forth.
- 4 -
Ordering Information
The KERMIT software is free and available to all. Columbia University,
however, is not set up to distribute free software on the scale required for
KERMIT. Therefore, to defray our costs for media, printing, postage, labor,
and computing resources, we must request a moderate donation from sites that
request KERMIT directly from Columbia. The schedule is as follows:
Complete KERMIT Distribution Å100.00
(Tape, Users Guide, and Protocol Manual)
Printed Documents Å5.00 each
(Users Guide, Protocol Manual, or Any Source Listing)
Other sites are free to redistribute KERMIT on their own terms, and are en-
couraged to do so, with the following stipulations: KERMIT should not be sold
for profit; credit should be given where it is due; and new material should be
sent back to Columbia University at the address below so that we can maintain a
definitive and comprehensive set of KERMIT implementations for further dis-
tribution.
To order KERMIT from Columbia University, send a letter requesting either:
(a) The manuals or source listings you desire (specify each one), or
(b) A 9-track magnetic tape in one of the following formats:
System Tape Format Densities
TOPS-10 BACKUP/Interchange, Unlabeled 800, 1600
TOPS-20 DUMPER, Unlabeled 800, 1600
IBM VM/CMS EBCDIC, CMS Format 1600, 6250
or EBCDIC, OS Standard Label 1600, 6250
Other ASCII, ANSI Label, Format ``D'' 800, 1600
(Specify system, format, and density.) One copy of each manual will be
included with the tape. We will supply the tape, packaging, and postage.
We can only make tapes in the formats listed above. We cannot produce floppy
disks; bootstrapping procedures are provided to allow the microcomputer ver-
sions to be downloaded from the mainframe for which the tape is produced. The
tape includes all source programs, documentation, and, when practical, binaries
or hex.
Send your letter to:
KERMIT Distribution
Columbia University Center for Computing Activities
7th Floor, Watson Laboratory
612 West 115th Street
New York, N.Y. 10025
Please list the machines and operating systems you expect to run KERMIT on,
specify the tape format or the listings desired, and mention whether there are
additional systems for which you require KERMIT or if you might be interested
in attempting your own implementation. Make checks payable to Columbia Univer-
sity Center for Computing Activities.
- 5 -
KERMIT is also available to users of the BITNET network via a server at host
CUVMA. BITNET users may type ``SMSG RSCS MSG CUVMA KERMSRV HELP'' for further
information. Additional network and user group distribution methods are under
consideration. Suggestions would be welcome.
No warranty of the software nor of the accuracy of the documentation surround-
ing it is expressed or implied, and neither the authors nor Columbia University
acknowledge any liability resulting from program or documentation errors.
- 6 -
1. Introduction
Everyone wants to get computers talking to one another. There are many ways to
do this, and most of them are very expensive. But there is one way that is
cheap and relatively easy: connect the two computers through their terminal
(TTY) ports, tricking one computer (or both) into believing that the other is a
terminal. This can be expected to work because the standard for connecting
computers to terminals is almost universally followed, in both hardware (plug
and signal: EIA RS-232) and software (character code: ASCII). Once two com-
puters (hosts) are connected in this way, cooperating programs can be run on
each host to achieve the desired communication by means of a communication
protocol.
Why is a protocol necessary at all? Two major problems occur when you try to
connect two computers via TTY line:
1. Noise. Data can become garbled in transmission because of electri-
cal interference, cosmic rays, or rodents chewing on the wires. The
longer a wire, the more noise you can expect. The noise corrupts
the data, sometimes in subtle ways which you may not notice until
it's too late.
2. Synchronization. One computer may be faster, or have larger buf-
fers, than the other. If one computer can send data faster than the
other can take it in, then some kind of flow control mechanism, ei-
ther in the data stream (XON/XOFF) or in parallel to the data (modem
control signals), can be employed to prevent data overruns, but no
two computers can be assumed to honor the same conventions for flow
control, or indeed to do it at all. Even when flow control is being
done, those signals are themselves are subject to noise corruption.
To prevent corruption of data and to synchronize communication, cooperating
computers can send control information to one another at the same time that
they are transferring data. This intermingling of control information with
data, and the resulting actions, constitute a "protocol".
KERMIT is a simple example of such a protocol. It is specifically designed for
transfer of files over ordinary serial communication lines. KERMIT is not
necessarily better than many other terminal-oriented file transfer protocols
but it is free, it is well documented, and it has been implemented compatibly
on a variety of microcomputers and mainframes.
KERMIT transfers data by encapsulating it in "packets" of control information.
This information includes a synchronization marker, a packet number to allow
detection of lost packets, a length indicator, and a "checksum" to allow
verification of the data. Lost or corrupt packets are detected, and
retransmission is requested. In addition, various special control packets al-
low cooperating KERMITs to connect and disconnect from each other and to ex-
change various kinds of information. Very few assumptions are made about the
capabilities of either computer, so the KERMIT protocol can work between many
different kinds of systems.
It should be noted that the checksum technique used by Kermit is not foolproof.
There are conditions under which bad data can still generate a valid checksum.
In practice, however, the protocol is quite reliable.
- 7 -
Acknowledgements to the Stanford DIALNET project (John McCarthy and Mark
Crispin), Peter Hurley of DEC (the "Hurley Protocol" described in the only
known issue of the DECsystem-10 Journal of Applications and Research), the
Stanford University Medical Center MAINSAIL project (TTYFTP), the University of
Utah CS Department SMALL-FTP developers, and to the authors of the File Trans-
fer Protocol section of the ARPANET Protocols Handbook.
The original design was done by Bill Catchings, Frank da Cruz, and Vace Kun-
dakci of the Columbia University Computer Center, in consultation with some
potential users, notably Peter Brooks. Bill wrote the initial implementations:
one for TOPS-20 and one for a Z80 CP/M system, which has subsequently been
adapted for a number of other CP/M systems. Bill also wrote the C kernel,
which has been used as the basis of other implementations, particularly the
UNIX implementation of Bob Cattani and Chris Maio of our CS Department. Daphne
Tzoar of Columbia wrote and documented the IBM VM/CMS and the IBM PC implemen-
tations. Other contributors are noted appropriately throughout this manual.
- 8 -
2. How to Use KERMIT
KERMIT is a protocol for reliable file transfer between computers over the or-
dinary serial telecommunication lines that are used to connect terminals to
computers. The mechanics of using KERMIT to get a file transferred can be con-
fusing until you get the hang of it. A little background material might make
the process a bit easier to understand.
KERMIT is probably the cheapest way to put two computers into communication.
The required hardware is usually already available, the software is free, and
all components run as ordinary user programs, with no system modifications.
This is in sharp contrast to a communication network, where there are dedicated
high-speed communications channels and drivers, expensive software, and so
forth. The network provides more services than KERMIT, usually at higher
speed, and with greater convenience, because the network is usually part of the
system. When a network is not available, KERMIT can fill in. But since KERMIT
is not integrated with any particular system, but rather grafted on top of many
different systems, it requires some extra work from those who use it.
2.1. The KERMIT Program
KERMIT embodies a set of rules for transferring files reliably between com-
puters. In general, one computer is a large system (a host, for instance a
timesharing system with many terminals), and the other is a personal computer
(PC)
the KERMIT protocol to occur, a KERMIT program must be running on each end of
the communication line -- one on the host, one on the PC.
The two Kermit programs exchange messages in a special language all their own,
the Kermit protocol. The dialog runs something like, "Hi! I'm going to be
sending files to you. When you send messages to me, please don't make them
more than 80 characters long, and if you don't hear anything from me for 15
seconds, wake me up, OK?" "OK." "Now, here comes a file called FOO.TXT, OK?"
"OK." "Here's the first piece..." "Got it." "Good! Here's the second
piece..." "Oops, sorry, the second piece was inconsistent." "Well, then here
it is again..." Et cetera. You don't see any of this. It's all packed into a
very concise code which the two Kermits can understand; they do all the wor-
rying about transmission, error checking, character set translation, and so
forth. Each message is called a packet, and each packet is in a special format
that all Kermits can understand.
Host-to-host and PC-to-PC connections are also possible.
- 9 -
2.2. Talking to Two Computers at Once
Your task is just to get the two Kermits started. The confusion arises because
you have to use a single keyboard and screen to talk to two different com-
puters, two different programs. Let's talk about a common case: you are sit-
ting at a personal computer (PC ), which has a serial communication port. The
serial port is connected to a host computer using, say, a dialup modem .
Normally, when you use your PC, you are "talking" directly to it; your commands
are interpreted directly by the PC's operating system (CP/M, MS-DOS, UNIX,
whatever), or by some program that runs on the PC (an editor, a text formatter,
space invaders...). The version of Kermit on your PC is a program like any
other, but it has a special ability to either interpret your commands directly,
like other programs, or to pass everything you type through to the host. When
you tell Kermit to CONNECT, it sends every character you type out the serial
port, and it will put every character that comes in the serial port onto the
screen. This is called virtual terminal service -- one computer acts
"virtually" as though it were a terminal on another. You are now "talking" to
the host, and the PC is ignoring you.
Kermit, like most programs, has a prompt. The prompt is a symbol it types on
the left margin to indicate that it is ready for you to type a command.
Kermit's prompt is normally "Kermit-xx>". The xx identifies the implementation
of Kermit; the Kermit that runs on the DEC-20 is called "Kermit-20" and its
prompt is "Kermit-20>"; the Kermit that runs on Z80 and 8080-based microcom-
puters is called "Kermit-80" and its prompt is "Kermit-80>"; the Kermit on the
IBM PC is "Kermit-86" , and so forth. If you become confused about who you are
talking to, the prompt should provide a clue. In addition, most Kermits print
an informative message like
#Connecting to remote host, type CTRL-$C to return$
when you CONNECT, and type another message like
#Connection closed, back at PC$
when you return.
The terms PC, micro, microcomputer, and workstation will all be used loosely
in this document to denote a single-user system.
The actual means of connection isn't important in this case -- it also could
be a direct line to the host, some kind of switched line, etc.
Although the processor in the IBM PC is an 8088, it is programmed as though
it were an 8086.
- 10 -
Having "connected" to the host, there must be a way for you to get back to the
PC. This is accomplished by an escape sequence. As Kermit passes your charac-
ters through to the host, it checks each one to see if it's a special
predefined escape character. When the PC sees this character, it stops ignor-
ing you -- you are once again "talking" to the PC, not the host. The escape
character is normally chosen to be one that you will not need to type while
talking to the host, and one that is hard to type by accident -- it's usually a
control character, such as Control-$, which is accomplished by holding down the
key marked CTRL or CONTROL and typing the indicated character (in this case, a
right bracket "$"). The CTRL key works just like a SHIFT key. Control charac-
ters are written either as CTRL-A or ^A, where A is the character to be typed
while holding down CTRL.
2.3. Transferring a File
To transfer a file, you must first get the attention of the PC's operating sys-
tem. This is normally done by starting the PC, possibly inserting your system
floppy disk first. Once you're at command level on your PC, you run Kermit.
Then you tell Kermit to CONNECT you to the host. Now you're talking to the
host -- at this point you must log in, and then run Kermit on the host.
Now you have a Kermit on each end of the wire. The next step is to tell each
Kermit what to do. Suppose you want to transfer a file from the host to the
PC; you would first tell the host Kermit to SEND the file, then "escape" back
to the PC Kermit and tell it to receive the file. The transfer begins -- all
you have to do now is sit back and watch. The PC Kermit will continuously show
packet and retry counts on your screen, and will notify you when the transfer
is complete.
The desired file is now on your PC's disk. The Kermit protocol has ensured
that the file arrived correctly and completely. Now you must clean up after
yourself: CONNECT back to the host, exit from Kermit on the host, log out from
the host, "escape" back to PC Kermit and exit from it. Now you can do whatever
you had planned for your file -- edit it, print it on your PC printer, etc.
The KERMIT protocol, and most Kermit programs, allow you to send a file reli-
ably from the host to the PC, from the PC to the host, from host to host, or PC
to PC, usually without any special regard for the nature of the particular
machines involved. Most implementations also allow files to be sent in groups,
with a single command, such as "Send all my Fortran files!" The scenario for
each of these is always the same as above -- only the details of how to estab-
lish the actual connection differ.
KERMIT works best with "printable" files -- files composed only of letters,
digits, punctuation marks, carriage returns, tabs, and so forth -- since these
can be represented on almost any kind of computer. KERMIT is also able to
transfer "binary" files -- files such as executable programs -- composed of ar-
bitrary bit patterns, but binary files normally are meaningful only to the kind
of computer on which they are generated. Nevertheless, KERMIT can usually move
such files from system A to system B (where they are not much use) and back to
system A in their original condition, although in some cases some special care
must be taken to accomplish this.
Now that we have a basic understanding of what KERMIT does and how it works,
let's look at some more concrete examples. First you need to know what the
basic Kermit commands are.
- 11 -
2.4. Basic KERMIT Commands
These are generic descriptions of the most basic Kermit commands. Detailed
descriptions for specific implementations of Kermit will come later. An under-
scored command is standard and should be found (in some form) in any implemen-
tation of Kermit.
In these descriptions, local refers to the system that you are directly con-
nected to, remote refers to the system to which you are CONNECTed via Kermit.
Commands may take one or more operands on the same line, and are terminated by
a carriage return.
SEND filespec Send the file or file group specified by filespec from this
Kermit to the other. The name of each file is passed to the
other Kermit in a special control packet, so it can be stored
there with the same name. A file group is usually specified by
including "wildcard" characters like "*" in the file specifica-
tion. Examples:
send foo.txt
send *.for
Some implementations of Kermit do not support transfer of file
groups; these versions would require a separate SEND command
for each file to be transferred.
RECEIVE Receive a file or file group from the other Kermit. If an in-
coming file name is not legal, then attempt to transform it to
a similar legal name, e.g. by deleting illegal or excessive
characters. The name thus formed cannot be guaranteed to be
unique, in which case previously existing files could be over-
written. Some versions of Kermit attempt to prevent this by
warning you of filename collisions and taking, or allowing for,
evasive action.
CONNECT Make a "virtual terminal" connection to the remote system. On
a PC or micro, this usually means to send all keyboard input
out the serial port, and display all input from the serial port
on the screen. Mainframe KERMITs that have this command behave
similarly; they send the characters typed at the terminal to a
specified TTY line and pass all input from that TTY line to the
terminal. KERMIT connections are most commonly initiated from
the the small computer. To "escape" from a virtual terminal
connection, type Kermit's escape character (e.g. CTRL-$,
control-rightbracket), followed by the letter "C" for "Close
Connection".
SET Establish various parameters, such as communication line num-
ber, CONNECT escape character, etc. See the description of the
appropriate version of KERMIT in Chapter 3.
SHOW Display the values of SET options.
HELP Type a summary of KERMIT commands and what they do.
EXIT Exit from KERMIT back to the host operating system.
- 12 -
? Typed anywhere within a KERMIT command: List the commands, op-
tions, or operands that are possible at this point. This com-
mand may or may not require a carriage return, depending on the
host operating system.
2.5. Real Examples
Kermit is used most commonly in several ways: a user sitting at a PC (personal
computer, microcomputer, workstation) which is connected to a larger host com-
puter; a user logged in to a host computer which is connected to another host;
two users, each sitting at a PC.
2.5.1. PC to Host
In this example, the user is sitting at an IBM Personal Computer (PC), which is
connected through its serial port to a DECSYSTEM-20 host computer. The IBM PC
is local, the DEC-20 is remote. This example will also apply almost literally
to any other microcomputer implementation of Kermit.
You have started up your PC and have the Kermit program on your disk. Begin by
running Kermit on the PC. Use Kermit's CONNECT command to connect to the
DEC-20. The PC will now behave as a terminal to the DEC-20. In fact, the PC
emulates the popular DEC VT52 terminal, so it is desirable to tell the DEC-20
that your terminal is a VT52. Login on the DEC-20 and run Kermit there. Here
is an example of this procedure with commands you type underlined:
A>kermit ! Run Kermit on the PC.
Kermit V1.2
Kermit-86> ! This is the Kermit prompt for the PC.
Kermit-86>connect ! Connect to the DEC-20.
#Connecting to host. Type CTRL-$C to return to PC.$
! You are now connected to the DEC-20.
CU20B ! The system prints its herald.
Øterminal vt52 ! Set your terminal type (optional).
Ølogin my-id password ! Login using normal login method.
(At this point, the DEC-20 prints various messages.)
Økermit ! Run Kermit on the DEC-20.
Kermit-20> ! This is Kermit-20's prompt.
You are now ready to transfer files between the two machines.
- 13 -
2.5.1.1. Receiving from the Host
The following example illustrates how to send files from the DEC-20 to the PC.
Note the use of the "*" wildcard character to denote a file group.
Everthing from a "!" mark to the end of line is a comment, not system
typeout or part of a command.
Kermit-20>send *.for ! Send all FORTRAN files.
^$c ! Now return back to the PC by
! typing the escape sequence, in this case
! ^$C (Control-$ followed by "C")
#Back at PC.$
Kermit-86>receive ! Tell the PC files are coming.
If you take more than about 5 seconds to get back to Kermit-86 and issue the
RECEIVE command, the first packets from Kermit-20 may arrive prematurely and
appear as garbage on your screen, but no harm will be done because the packet
will be retransmitted by the DEC-20 until the PC acknowledges it.
Once the connection is established, the PC will show you what is happening
-- it first clears the screen and waits for incoming packets; as packets ar-
rive, the current file name and packet number will be continuously displayed on
the screen. When the PC's "Kermit-86>" prompt returns to your screen, the
transfer is done.
When the transfer is complete, you must CONNECT back to the DEC-20 host, EXIT
from Kermit there, logout from the DEC-20, and return to the PC as you did
previously.
Kermit-86>connect ! Get back to the DEC-20.
#Connecting to host. Type CTRL-$C to return to PC.$
Kermit-20> ! Here we are.
Kermit-20>exit ! Get out of Kermit-20.
Ølogout ! Logout from the DEC-20.
Logged out Job 55, User MY-ID, Account MY-ACCOUNT, TTY 146,
at 24-Jan-83 15:18:56, Used 0:00:17 in 0:21:55
^$c ! Now "escape" back to the PC,
#Back at PC.$
Kermit-86>exit ! and exit from the PC's Kermit.
The files you transferred should now be on your PC disk.
2.5.1.2. Sending to the Host
To send files from the PC to the DEC-20, follow a similar procedure. First
follow the instructions in the previous section to log in to the DEC-20 through
the PC. Then in response to the host Kermit's "Kermit-20>" prompt you type
RECEIVE rather than SEND. Now escape back to the PC and use the SEND command
to send the local PC files to DEC-20 host. The PC will show you the progress
of the transmission on its screen.
When the "Kermit-86>" prompt indicates that the transmission is complete you
should follow the procedure shown above to logout from the DEC-20 host, except
that you may first wish to confirm that the files have been stored correctly in
your directory on the DEC-20.
- 14 -
2.5.2. Host to Host
This section describes use of Kermit between two hosts. A "host" is considered
to be a large or multi-user system, whose distinguishing characteristic is that
it has multiple terminals. Use of Kermit for host-to-host file transfers dif-
fers from the PC-to-host case in that the line your terminal is connected to is
not the same as the line over which the data is being transferred, and that
some special commands may have to be issued to allow one Kermit to conform to
unusual requirements of the other host.
In this example, you are already logged in to a DEC-20, and you use an
autodialer to connect to an IBM 370-style system running VM/CMS through DEC-20
TTY port 12. The autodialer, in this example, is invoked from program called
DIAL (idealized here, for simplification), to which you merely supply the phone
number.
Ødial 765-4321/baud:300
765-4321, baud 300
#confirm$
Dialing your number, please hold...
Your party waiting is on TTY12:
Ø
Other methods exist for connecting two hosts with a serial line. Dedicated
hookups can be made simply by running an EIA cable between TTY ports on the two7
systems.
manual dialup connection is also possible, but tricky. If you have a microcom-
puter that supports KERMIT, you may find it easier to first transfer from host
A to the micro, then from the micro to host B.
The following procedure would be the same in any case, once a connection is
made. Note that Kermit-20 accomplishes remote terminal connection by running a
program called TTLINK in an inferior fork.
Ø
Økermit ! Run Kermit on the DEC-20.
Kermit-20>set ibm-flag ! Turn on special handshaking, parity, local ech
Kermit-20>set line (to tty) 12 ! Indicate the line we'll use.
Kermit-20>connect ! And connect to it.
#TTLINK: Connecting to remote host over TTY12:, type <CTRL-Y>C to return.
Such a connection, by the way, requires the receive and transmit leads be
swapped in one of the RS-232 connectors; this is called a "null modem" cable.
Here's one way: log in on port x on your system, and assign another port, y,
to which you have physical access. Unplug the terminal from port y, and con-
nect the terminal to a dialup modem. Dial up the remote computer and log in on
it. Now, using a null modem cable, connect the modem directly to port y. Go
back to your terminal on port x, run Kermit from it, and CONNECT to port y.
- 15 -
VM/370 ONLINE ! The IBM system prints its herald.
.login myuserid XXXXXX ! Login to the IBM system.
LOGON AT 20:49:21 EST THURSDAY 01/20/83
CUVMB SP/CMS PUT 8210 01/19/83
.
.kermit
KERMIT-CMS>.send profile exec ! Send a file.
^Yc ! TTLINK's escape sequence typed here.
#TTLINK: Connection Closed. Back at DEC-20.$
Kermit-20>receive ! Tell Kermit-20 to RECEIVE.
The transfer takes place now; Kermit-20 will print the names of incoming files,
followed by dots or percents to indicate the packet traffic (a dot for every 5
packets successfully transferred, a percent for every timeout or
retransmission). It is complete when when you see "#OK$" and the Kermit-20
prompt next appears. At that point we connect back to the remote IBM system,
exit from the remote Kermit and log out.
.
PROFILE.EXEC.1 ..%%.#OK$
Kermit-20>connect ! Get back to IBM and clean up.
#TTLINK: Connecting to remote host over TTY12:, type <CTRL-Y>C to return.
KERMIT-CMS>.
KERMIT-CMS>.exit
R;
.
SP/CMS
.logout
CONNECT= 00:03:01 VIRTCPU= 000:00.12 TOTCPU= 000:00.60
LOGOFF AT 20:52:24 EST THURSDAY 01/20/83
^Yc ! Type Kermit-20's escape sequence
#TTLINK: Connection Closed. Back at DEC-20.$
Kermit-20>exit ! All done with Kermit.
That's the whole procedure. The file is in your DEC-20 directory, completely
readable, as PROFILE.EXEC -- note that KERMIT-CMS translated from the IBM
EBCDIC character encoding into standard ASCII, and converted the space between
the file name and file type to a dot.
To send a file from the local host to the remote host, we would merely have
reversed the SEND and RECEIVE commands in the example above.
- 16 -
2.5.3. Micro to Micro
Kermit also works between personal computers (microcomputers, workstations).
The difference here is that commands are typed on two keyboards, rather than a
single one. This is because a personal computer normally only accepts commands
from its own keyboard. If one PC Kermit CONNECTs to another, there will nor-
mally be no program on the other side to listen.
Making the physical connection between two micros is tricky. If the two units
are in close proximity , you can connect their serial ports with a null
modem cable. However, different micros have different requirements -- some may
want a male connector on their serial port, others a female; many require that
certain of the RS-232 signals be held high or low by wiring certain of the pins
in the connector together . In any case, you must also make sure the port
speeds are the same at both ends.
Connections at longer distances can be made via dialup, providing the required
modems are available (one side needs autoanswer capability), or using any kind
of dedicated or switched circuit that may be available -- PBX, port contention
unit, anything you can plug an EIA connector into.
In this example, a DEC VT180 "Robin" CP/M microcomputer is connected to an In-
tertec "SuperBrain" CP/M micro, using a female-to-male null modem cable. Es-
tablishing the physical connection is the hard part. The connection can be
tested by running Kermit and issuing the CONNECT command on both ends: typein
from each micro should appear on the screen of the other.
Suppose you want to send a file FOO.HEX from the Robin to the SuperBrain.
Proceed as follows:
1. Run Kermit on the SuperBrain, and give the RECEIVE command:
A>kermit
CUCCA SuperBrain Kermit-80 - V3.2
Kermit-80>receive
2. Run Kermit on the Robin, and give the SEND command for FOO.HEX.
A>kermit
CUCCA/DEC VT18X Kermit-80 - V3.2
Kermit-80>send foo.hex
Why would you want to run Kermit between two PCs that are next to each
other? One good reason is that if they are different models, their floppy
disks are probably incompatible.
For instance, some micros want DTR (Data Terminal Ready, pin 20) to be held
high, and this might be accomplished by connecting it to CTS (Clear To Send,
pin 5). See EIA Standard RS-232-C, and the appropriate manuals for your micro.
- 17 -
3. Watch the packets fly. When you get a Kermit-80> prompt, the trans-
fer is done, and you can EXIT from both Kermits.
The key point is to start the receiving end first -- most microcomputer Kermits
do not include a timeout facility, and if the receiver is not ready to receive
when the sender first sends, there will be a protocol deadlock.
2.6. Another Way -- The KERMIT Server
So far, we have been describing Version 1 of the KERMIT protocol. This edition
of the KERMIT manual now presents Version 2, which includes the concept of a
Kermit server. A KERMIT server is a Kermit program that does not interact
directly with the user, but only with another Kermit. You do not type commands
to a Kermit server, you merely start it at one end of the connection, and then
type all further commands at the other end.
Not all implementations of Kermit can be servers, and not all know how to talk
to servers -- yet. The server is run on the remote computer, which would nor-
mally be a large host, such as the DEC-20. You must still connect to the
DEC-20 to log in and start the server, but you no longer have to tell one side
to SEND and the other to RECEIVE, nor must you connect back to the remote side
to clean up when you're done. Using the server, you can do as many send and
receive operations as you like without ever having to connect back to the
remote host.
A Kermit server is just a Kermit program running in a special mode. It acts
exactly like ordinary Kermit does after you give it a RECEIVE command -- it
waits for a message from the other Kermit, but in this case the message is a
command telling whether to send or to receive, and if to send, which file(s) to
send. After escaping back to the local system, you can give as many SEND and
RECEIVE commands as you like, and when you're finished transferring files, you
can give the BYE command, which sends a message to the remote Kermit server to
log itself out. You don't have to connect back to the remote host and clean
up. However, if you want to connect back to the host, you can use the
FINISH command instead of BYE, to shut down the Kermit server on the remote
host without logging it off, allowing you to CONNECT back to your job there.
Here's an example of the use of a Kermit server. The user is sitting at a CP/M
microcomputer and a DEC-20 is the remote host.
A>kermit ! Run Kermit on the micro.
Kermit V3.2
Kermit-80> ! This is the micro Kermit's prompt.
Kermit-80>connect ! Connect to the DEC-20.
#Connecting to remote host. Type CTRL-$C to return to micro.$
CU20E ! The DEC-20 prints its herald.
Øterminal vt52 ! Set your terminal type (optional).
Ølogin my-id password ! Log in normally.
(The DEC-20 prints various login messages here.)
- 18 -
Økermit ! Run Kermit-20 normally
Kermit-20>server ! Tell it to be a server.
#Kermit Server running on DEC-20 host. Please type your escape sequence
return to your local machine. Shut down the server by typing the Kermit
command on your local machine.$
^$c ! Now escape back to the micro.
#Connection closed, back at micro.$
Kermit-80>receive *.pas ! Get all my DEC-20 Pascal programs.
Kermit-80>send foo.* ! Send all the "foo" files from my micro.
Kermit-80>exit ! Exit from Kermit back to CP/M.
A>
(Here you can do some work on the micro, edit files, whatever you like.)
A>kermit ! Run Kermit-80 some more.
Kermit-80>send file.pas ! Send another file.
Kermit-80>bye ! That's all. Shut down the Kermit server.
A> ! Back at CP/M automatically.
This is much simpler. Note that once you've cranked up the Kermit Server on
the remote end, you can run Kermit as often as you like on the micro without
having to go back and forth any more; just make sure to shut the server down
when you're done.
Here are the commands available for talking to servers. The underlined ones
are standard.
SEND filespec Sends a file or file group from the local host to the remote
host in the normal way.
RECEIVE filespec
Ask the remote host to send a file or file group. Example:
receive *.c
This command is exactly equivalent to typing "send *.c" at the
remote host followed by "receive" on the local host. Note that
the local Kermit does not attempt parse the filespec. If the
server cannot parse it, or cannot access the specified file(s),
it will send back an appropriate error message.
BYE Shut down the remote server and exit from Kermit. This will
cause the job at the remote end to log itself out. You need
not connect back and clean up unless you get an error message
in response to this command (for instance, if your logged-out
disk quota is exceeded on the remote host).
LOGOUT Shut down the server but don't exit from Kermit.
FINISH Shut down the server without having it log itself out, and
don't exit from Kermit. A subsequent CONNECT command will put
you back at your job on the remote host, at system command
level.
- 19 -
If you want to run the server with non-default options selected (like IBM-FLAG,
FILE-BYTE-SIZE, etc), then you can issue the appropriate SET options before
giving the SERVER command.
2.7. When Things Go Wrong
There are various ways in which Kermit can become stuck, but since many hosts
are capable of generating timeout interrupts when some process doesn't complete
quickly enough, they can usually resend or "NAK" (negatively acknowledge) lost
packets. Nevertheless, if a transfer seems to be stuck, you can type RETURN on
the keyboard of most micros to wake up Kermit and have it retransmit the last
packet.
An interesting exception is the IBM host (VM/CMS) Kermit -- it cannot time out
its "virtual console" (i.e. the user's terminal), so when using Kermit from a
micro to an IBM host, occasional manual wakeups may be necessary.
Here are a few symptoms and what to do about them.
2.7.1. The Transfer is Stuck
The following sections discuss various reasons why a transfer in progress could
become stuck. Before examining these, first make sure that you really have a
Kermit on the other end of the line, and you have issued the appropriate com-
mand: SEND, RECEIVE, or SERVER. If the remote side is not a server, remember
that you must connect back between each transfer and issue a new SEND or
RECEIVE command.
2.7.2. The Micro is Hung
The micro itself sometimes becomes hung for reasons beyond Kermit's control,
such as power fluctuations. If the micro's screen has not been updated for a
long time, then the micro may be hung. Try these steps (in the following
order):
- Check the connection. Make sure no connectors have wiggled loose
from their sockets. If you're using a modem, make sure you still
have a carrier signal. Reestablish your connection if you have to.
- Press RETURN to wake the micro up. This should clear up any protocol
deadlock.
- If the problem was not a deadlock, restart the micro and then restart
Kermit, CONNECT back to the host, get back to your job or login
again, and restart the transfer. You may have to stop and restart
Kermit on the remote host.
- 20 -
2.7.3. The Remote Host Crashed
If your local system is working but the transfer is hung, maybe the remote host
crashed. "Escape" back to local Kermit command level and issue the CONNECT
command so that you can see what happened. If the remote system has crashed
then you will have to wait for it to come back, and restart whatever file that
was being transfered at the time.
2.7.4. The Disk is Full
If your floppy disk or directory fills up, the Kermit on the machine where this
occurs will inform you and then terminate the transfer. You can continue the
transfer by repeating the whole procedure either with a fresh floppy or after
cleaning up your directory. If you were sending a file group from the DEC-20
you can continue the sequence where it left off by using the SEND command and
including the name of the file that failed in the "(INITIAL)" field, for ex-
ample
Kermit-20>send *.for (initial) foo.for
See the Kermit-20 command summary for further information about the initial
filespec.
2.7.5. Host Errors
Various error conditions can occur on the remote host that could effect file
transmission. Whenever any such error occurs, the remote Kermit normally at-
tempts to send an informative error message to the local one, and then breaks
transmission, putting you back at Kermit command level on the local system.
2.7.6. File is Garbage
There are certain conditions under which Kermit can believe it transferred a
file correctly when in fact, it did not. One way this can happen is if errors
occured during transmission that did not effect the byte count or checksum.
For instance, if in a single packet one character bit n was received as a zero
when it should have been a one, and in another character, bit n became a one
when it should have been a zero, then the checksum would be the same as if no
error had occured. The only remedies here are to edit the file after it is
sent to fix the bad characters, or send the file again.
A more likely cause of garbage files has to do with the tricky business of the
bytes. Most computers store files as sequences of 8-bit bytes, but there are
some exceptions, like the DEC-10 and DEC-20, which store files in various ways
-- text (printable) files as 7-bit bytes, binary files in 36-bit words. To
complicate matters further, different systems handle telecommunication dif-
ferently: most systems transmit ASCII (a 7-bit code) in 8-bit bytes, but some
allow the application (user program) to use the 8th bit for data -- thus allow-
ing the transmission of binary files in 8-bit bytes -- while others insist upon
- 21 -
using the 8th bit as a parity check . These complications only come into play
when attempting to transfer binary files; when transferring ordinary text
files, there's never a problem about byte sizes. The following descriptions of
the particular Kermit implementations tell what mechanisms are available for
dealing with bytes size problems.
The parity bit is set to one or zero based upon whether sum of the other 7
bits is odd or even. Parity can be EVEN, ODD, MARK (always one), SPACE (always
zero), or NONE (don't alter the 8th bit).
- 22 -
3. KERMIT Implementations
Kermit has been written for a wide variety of systems, both mainframes and
microcomputers. Kermit is not written in a portable language; rather, each im-
plemenation is written in the language best suited for the particular machine.
The specification, given in the Kermit Protocol Manual, is quite general and
allows implementation on almost any machine.
Here's a brief table summarizing the known Kermits, listing some of the fea-
tures in which they might differ: the host processor, implementation language,
and so forth. Notation for Service and Capabilities is explained below.
Operating Source
Machine System Language Done By Service Capabilities
DECSYSTEM-20 TOPS-20 MACRO-20 Columbia R L U S T F I W D E
DECsystem-10 TOPS-10 MACRO-10 Stevens R L T F D E
IBM 370 series VM/CMS 370 ASM Columbia R F W E
(various) UNIX C Columbia R L T W D
VAX-11 VMS Bliss-32 Stevens R S T F W D E
PDP-11 RT-11 OMSI Pascal Toronto/CU R L W D E
8086/8088 implementations:
IBM PC, XT PC DOS 8086 ASM Columbia L U F I W D E
Heath/Zenith 100 ZDOS 8086 ASM CU/Stevens L U F I W D E
8080/8085/Z80 implementations:
DEC VT180 Robin CP/M 8080 ASM CU/DEC L U F I W E
DEC Rainbow 100 CP/M-86/80 8080 ASM CU/DEC L U F I W E
DEC DECmate II CP/M 8080 ASM CU/DEC L U F I W E
Heath/Zenith 89 CP/M 8080 ASM CU/DEC L U F I W E
Heath/Zenith 100 CP/M-85 8080 ASM CU/Stevens L U F I W E
Apple II/Z80 CP/M 8080 ASM CU/DEC L U F I W E
TRS-80 II CP/M 8080 ASM CU/Cerritos L U F I W E
Osborne 1 CP/M 8080 ASM CU/NIH L U F I W E
Superbrain CP/M 8080 ASM Columbia L U F I W E
Vector Graphics CP/M 8080 ASM Columbia L U F I W E
Telcon Zorba CP/M 8080 ASM CU/Stevens L U F I W E
Ohio Scientific CP/M 8080 ASM Columbia L U F I W E
"Generic" CP/M 8080 ASM CU/DEC L U F I W E
6502 implementations:
Apple II Apple DOS CROSS Stevens L F E
(CU means Columbia University; CU/DEC implementations are modifications to the
basic CU 8080 implementations done by DEC personnel mostly on their own time;
Stevens is the Stevens Institute of Technology in Hoboken NJ.)
Under "Service", R means it can act as a Remote Kermit (the object of a
connection), L means it can act as a Local Kermit (initiate a connection to a
Remote Kermit via a CONNECT command); U means it can can be the User of a
remote Kermit server; S means it can act as a Server.
Under "Capabilities", "T" means it can time out, "F" means it can take some
- 23 -
kind of evasive action to avoid Filename conflicts, "I" means it can communi-
cate with an IBM mainframe (which requires special half duplex line handshak-
ing, local echoing, and parity control), "W" means it can do "wildcard" sends,
"D" means it has a Debug mode that can display the packet traffic on the
screen, and "E" means it can exchange Error messages with another Kermit.
3.1. Command Interface
Most implementations (the UNIX version is the major exception) attempt to im-
itate the command parsing style of the DEC-20, which is roughly as follows: In
response to the "Kermit-xx>" prompt you may type a keyword, such as SEND,
RECEIVE, or EXIT, possibly followed by additional keywords or operands, each of
which is called a field. You can abbreviate keywords to any length that makes
them distinguishable from any other keyword valid for that field. You can ter-
minate a field with ESC and receive a special short prompt, called a guide
word, in parentheses, telling you what the next field should be. You can type
a question mark at any time to get information about what's expected or valid
at that point. The ESC and "?" features work best on full duplex systems (all
but the IBM mainframe, so far), where the program can "wake up" immediately and
perform the required function. On half duplex or record-oriented systems, the
ESC feature is not available, and the "?" requires a carriage return to follow.
In this example, the user types "set" and then a question mark to find out what
the SET options are. The user then continues the command at the point where
the question mark was typed, adding a "d" and another question mark to see what
set options start with "d". The user then adds a "u" to select "duplex" (the
only SET option that starts with "du") followed by an ESC (shown here by a dol-
lar sign) to complete the current field and issue the guide word "(to)" for the
next one, then another question mark to see what the possibilities are, and so
forth. The command is finally terminated by a carriage return. Before car-
riage return is typed, however, the command can be edited using RUBOUT or other
command editing keys. Finally, the same command is entered again with a min-
imum of keystrokes, with each field abbreviated to its shortest unique length.
In the example, the parts the user types are underlined; all the rest is system
typeout:
Kermit-20>set ? one of the following:
debugging delay duplex escape
file-byte-size IBM-flag line parity
receive send
Kermit-20>set d? one of the following:
debugging delay duplex
Kermit-20>set duÅplex (to) ? one of the following:
full half
Kermit-20>set duplex (to) hÅalf
Kermit-20>set du h
This style is fully realized in TOPS-10, TOPS-20, CP/M, Apple DOS, and PC/MS
DOS implementations of Kermit, partially realized in the IBM VM/CMS and VAX/VMS
versions, and not used at all in the UNIX and RT versions.
- 24 -
3.2. Notation
In the command descriptions, the following notation is used:
<anything> A parameter - the symbol in angle brackets is replaced by an ar-
gument of the appropriate type (number, filename, etc).
#anything$ An optional field. If omitted, it defaults to an appropriate
value.
<o> An octal number, i.e. a number in base 8 containing digits in the
range 0-7.
<d> A decimal, base-10, number.
<f> A floating point number, decimal notation, e.g. 9.75
<c> A single printable character.
Commands are shown in upper case, but can be entered in any combination of up-
per and lower case. In order to keep the size of this chapter managable, some-
times only the differences from the command summary given in Chapter 2.4 are
noted. Also some infrequently used commands are omitted; consult the help
files on each version for a complete list of commands.
3.3. TOPS-20 KERMIT
Kermit is written for the DEC-20 in assembly language using the MACRO as-
sembler. It takes advantage of DEC-20 command parser, software interrupt sys-
tem, etc. In general, as much intelligence as possible was put into Kermit-20
to allow smooth communication with even the most minimal Kermit implemen-
tations.
DEC-20 file specifications are of the form
DEVICE:<DIRECTORY>NAME.TYPE.GEN;ATTRIBUTES
where the DIRECTORY, NAME, and TYPE may each be up to 39 characters in length,
GEN is a generation (version number), and various attributes are possible
(protection code, account, temporary, etc). Generation and attributes are nor-
mally omitted. Device and directory, when omitted, default to the user's own
disk and directory. Thus NAME.TYPE is normally sufficient to specify a file,
and only this information is provided by Kermit for outgoing files.
The DEC-20 has an unusual word size -- 36 bits -- and differs from most other
systems by storing text in 7-bit, rather than 8-bit, bytes. The word size is
not a multiple of the normal byte size. In fact, the DEC-20 has several ways
of storing files, which Kermit-20 must allow for:
1. Normal text files (such as program source) are stored as strings of
7-bit bytes, 5 per 36-bit word; the remaining bit (bit 35) of each
word is 0.
2. Files produced by text editors like EDIT, SOS, or Otto may have
"line sequence numbers". Such files are distinguished from ordinary
- 25 -
text files by having each line start on a word boundary. The first
word in a line is the character representation of the 5-character
line number, with bit 35 set to 1. The first character in the
second word is a tab. The final word in a line is padded with nulls
if necessary. There are also special page marks.
3. Sequential binary files consist of 36-bit words in which all bits
are used. Common examples are .EXE (executable) and .REL
(relocatable) files.
4. Eight bit files are strings of 8-bit bytes, four per 36-bit word
(left justified in 32 bits). This type of file is used most often
to store executable files from other machines such as .COM files for
CP/M micros. You must use the SET FILE-BYTE-SIZE EIGHT-BIT (or
AUTO) command to send these files, and EIGHT-BIT (only, not AUTO) to
receive them.
5. Other DEC-20 file organizations can not be fully supported by
Kermit-20. These include directory files, files with holes (missing
pages), ISAM files, and RMS files. These files require external in-
formation (kept in the DEC-20's file descriptor block and/or index
table) in order to be reconstructed; when sending files, Kermit
transmits only the file name and the contents of the file. External
control information is beyond the scope of the KERMIT protocol. Al-
though Kermit-20 might be able to send these files, it cannot com-
pletely reconstruct them upon receipt.
See the discussion of SET FILE-BYTE-SIZE, below, for further information.
Kermit-20 can be run in two modes, remote and local. When remote, all file
transfer is done over the job's controlling terminal line; what TOPS-20 thinks
is your terminal is really another computer running its own copy of Kermit.
When local, file transfer is done over an external, assigned TTY line, which is
connected in some way (e.g. dialout mechanism) to another computer, again run-
ning its own copy of Kermit. A local Kermit is in control of the screen, a
remote Kermit has no direct access to it. A local Kermit is one that has
issued the SET LINE n command, described below. Some commands make sense only
for remote (or local) Kermits, others can be used with either.
Kermit-20 will accept a single command on the Exec command line, or you can run
it interactively. Here are the Kermit-20 commands; special remote or local
commands are appropriately marked:
BYE LOCAL -- Shut down and log out a remote Kermit server, close any local
log files, and exit from the local KERMIT. This command has no effect
without a prior SET LINE n command. If the remote Kermit is not a
server (but is in receive mode), you'll get a message back like
"Illegal packet type".
CONNECT #<line>$
LOCAL -- Act as a terminal to the system connected to the other end of
the line specified, or if no line was specified, to the one given in
the most recent SET LINE command. Use full duplex echoing, no parity,
and CTRL-Y as the escape character by default, or else whatever was
specified by appropriate SET commands. Kermit accomplishes the connec-
tion by running the TTLINK program in a lower fork. If a line is
- 26 -
specified, it becomes the default for file transfer and subsequent CON-
NECTs. The escape character accepts single character arguments, as
follows:
C Close the Connection.
S Show Status of Connection.
P Push to a new Exec.
? Type a brief help message listing these options.
^Y (or whatever the escape character is) -- Send the escape charac-
ter itself to the remote host.
TTLINK has additional options which you can select if you run it
directly, including the ability to establish a log file to record your
remote session, which can provide "unguarded" (no error checking or
correction) capturing of files from remote systems that don't have KER-
MIT. CAUTION -- The DEC-20 is intrinsically incapable of taking in
large amounts of data on a serial port; if either the baud rate or the
system load average is high, incoming characters can be lost during
CONNECT.
EXIT Exit from KERMIT-20, closing any open debugging log files. The program
may be CONTINUEd. You may also stop KERMIT-20 in the midst of a trans-
fer or during server operation by typing several CTRL-C's; the program
traps them and puts your terminal back to normal before halting
(continuation puts the program back at "Kermit-20>" command level).
FINISH LOCAL -- Shut down a remote Kermit server without logging it out, so
that you can still CONNECT to the remote job, and close any open debug-
ging log file. Leaves you at local "Kermit-20>" prompt level. Has no
effect without a prior SET LINE n command. If the remote Kermit is not
a server (but is in receive mode), you'll get a message back like
"Illegal packet type".
GET <filespec>
LOCAL -- Ask a remote Kermit server to send the specified files. The
filespec is any string that can be a legal file specification for the
remote system; it is not parsed or validated locally. As files arrive,
their names will be displayed on your screen, along with "." and "%"
characters to indicate the packet traffic. If the remote KERMIT is not
capable of server functions, then you will probably get an error mes-
sage back from it like "Illegal packet type". In this case, you must
connect to the other Kermit, give a SEND command, escape back, and give
a RECEIVE command. (Note that most other Kermits use the RECEIVE com-
mand for this; Kermit-20 already had a RECEIVE <filespec> command that
was used differently; see below.)
HELP #<topic>$
Give help. There's a general help text, plus separate help texts for
each KERMIT-20 command. HELP alone will provide a summary of KERMIT-20
commands, HELP ? will list the individual topics on which further help
is available.
PROMPT Issue a prompt, and go into interactive command mode. This is useful
only on the Exec command line, when running a version of Kermit-20
whose default mode of operation is as a server; this causes the program
to start up with the "Kermit-20>" prompt, allowing you to issue inter-
- 27 -
active commands.
QUIT A synonym for EXIT.
RECEIVE #<filespec>$
Receive a file or group of files from other Kermit. If a filespec is
given, the first file received will be stored on the DEC-20 under that
name; otherwise, the name is taken from the incoming file header
packet. Even if the name provided by the other host is not a legal
TOPS-20 file name, KERMIT-20 will store it under that name, in which
case you can refer to it later by quoting the illegal characters
(spaces, lower case letters, control characters, etc) with ^V, or by
clever use of filename completion. If a file with the same name al-
ready exists, KERMIT-20 just creates a new generation.
If running as a local Kermit, the names of the incoming files will be
displayed on your screen, along with "." and "%" characters to indicate
the packet traffic. If running as a remote Kermit, you should escape
back to your local Kermit and give the SEND command. This command can-
not be used to request files from a remote Kermit server; for that use
the GET command.
SEND <filespec1> #(INITIAL) <filespec2>$
Send file(s) specified by <filespec1> to the other Kermit. If
<filespec1> contains wildcard characters ("*" or "%"), all matching
files will be sent in alphabetical order by name, and <filespec2> may
be specified as the initial file in the group to send (this allows an
interrupted wildcard transfer to be resumed where it left off). This
command may be used to send files to any Kermit, server or not.
If running as a local Kermit, the name of each file will be displayed
on your screen as the transfer begins, a "." will be printed for every
5 data packets sucessfully sent, and a "%" for every retransmission or
timeout that occurs. If you see many "%" characters, you are probably
suffering from a noisy connection.
If running as a remote Kermit, you should escape back to your local
Kermit and give the RECEIVE command. If you don't do this fast enough,
several "send-init" packets may arrive prematurely; don't worry,
KERMIT-20 will keep sending them until it gets a response.
SERVER REMOTE -- Act as a Kermit Server with default options, or with whatever
options have been established by previous SET commands. Note that all
options (such as FILE-BYTE-SIZE, see below) remain as long as the serv-
er is running -- there is no way to change them without shutting down
the server and restarting with new options. The server may be shut
down from the local Kermit using BYE or FINISH commands, or by connect-
ing back to the DEC-20 and typing several CTRL-C's. A BYE command logs
out the server's job from the DEC-20; a FINISH command halts the server
without logging its job out.
SET <parameter> <value>
Set the specified parameter to the specified value. Possible settings:
ABORTED-FILE <disposition>
Normally, when a file transfer cannot be completed (for in-
- 28 -
stance, because the communication path suddenly breaks or be-
comes too noisy), the side receiving the file normally "aborts"
the operation -- that is, everything received so far is dis-
carded. This command allows the user of Kermit-20 to specify
the disposition of partially received files upon abnormal ter-
mination of a file transfer:
DISCARD Remove all traces of the partially received file from
the DEC-20 disk. This is the normal mode of operation,
and need not be specified except to cancel an earlier
SET ABORTED-FILE KEEP.
KEEP Keep the file on disk, containing all the data that was
transferred successfully up until the error occurred.
This option may be useful when transferring very long
files, when it is possible to have the sending system
start again at the place it was interrupted, e.g. by
breaking the end of the file off with a text editor.
DEBUGGING <mode>
When KERMIT is not transferring files successfully, it may be
useful to inspect the messages that are sent between the two
Kermits, or the internal state transitions. Several options
are available.
STATES Shows the packet number and type or internal state, for
each packet. The packet types and states are:
S Send Initiate
R Receive Initiate
F File Header
D Data
Z End of File
B Break Transmission
C Transfer Complete
E Error
A "Abort" Transmission
T Timeout
PACKETS Display the actual incoming and outgoing packets. For
a description of the packet format, see the Kermit
Protocol Manual.
LOG-FILE <filespec> #(BYTESIZE) <d>$
Debugging display can be done to the screen if
Kermit-20 is running in local mode. If remote,
however, the display must not be sent to the screen, or
else it would interfere with the packets. This option
allows the display to be logged to a file. If a SET
DEBUG command has not previously been issued, this com-
mand will also force DEBUGGING mode to STATES. SET
DEBUGGING OFF will close the log file, as will the
EXIT, BYE, and FINISH commands. Optionally, the
bytesize for the log file may be specified as 7 or 8
-- 7 is the default; 8 is useful when debugging binary
file transfers. An 8-bit log file is not readable by
- 29 -
ordinary TYPE, PRINT, or EDIT commands, however; you
must use a DEC-20 utility like FILDDT to examine it
-- use ESC ESC 8o to display 8-bit characters in octal
(to see the parity bits), or ESC ESC 8t to display
8-bit characters in ASCII.
OFF No debugging information will be displayed. If debug-
ging was previously in effect, debugging is turned off
and any debugging log file is closed.
Debugging is OFF by default. The default <mode> for the SET
DEBUG command, however, is STATES.
DELAY <d>
REMOTE -- Specify the delay, in seconds, before sending the
first send-init packet. This gives you time to "escape" back
to your local Kermit and issue a RECEIVE command. Normal delay
is 5 seconds.
DUPLEX FULL (or HALF)
LOCAL -- Specify echoing during CONNECT to a remote host: FULL
means the remote host echoes, HALF means the local KERMIT will
do the echoing. FULL by default. HALF generally required with
IBM hosts.
ESCAPE <o>
LOCAL -- Specify the control character you must type back to
the local KERMIT when CONNECTed to a remote system. 31
(CTRL-Y) by default. The number is the octal value of the AS-
CII control character, 1 (CTRL-A) to 37 (CTRL-Underscore).
FILE-BYTE-SIZE
Arguments are EIGHT-BIT, SEVEN-BIT, or AUTO. Establishes the
DEC-20 byte size for incoming or outgoing files. You can tell
the bytesize of a DEC-20 file by doing a VDIR of that file,
e.g.
Øvdir foo
PS:<MY-ID>
FOO.COM.1;P770000 1 492(8) 27-Jan-83
MAC.1;P770000 1 152(7) 27-Jan-83
.REL.1;P770000 1 39(36) 27-Jan-83
.EXE.1;P770000 2 1024(36) 27-Jan-83
Total of 5 pages in 4 files
The bytesize is shown in parentheses, and the number directly
preceding the parens shows how many bytes of that size are in
the file. The number preceding that shows how many 512-word
pages are in the file (a page is the smallest unit of disk
storage on the DEC-20).
EIGHT-BIT Always do 8-bit i/o to the DEC-20 file. Incoming
files will be stored in your DEC-20 directory with a
bytesize of 8, and outgoing files will be sent in
- 30 -
8-bit mode: four 8-bit bytes from each 36 bit word,
with the trailing four bits ignored. You should use
this for binary files that originate on a non-DEC-10
or -20 remote host (for example, CP/M .COM files), or
8-bit files that are built on the DEC-20 (or -10)
using cross compilers or loaders for downloading to
8-bit-byte systems.
SEVEN-BIT When sending, each 36-bit word from the DEC-20 file
is divided up into five 7-bit bytes, starting from
the "left" (bit 0). Transmission is done in 8-bit
bytes; the first four bytes have the 8th bit
(otherwise used for parity) set to 0. The fifth byte
has bit 8 set to the value of bit 35 of the DEC-20's
word. This allows file types 1, 2, and 3 above to be
sent to a foreign host and reconstructed correctly
upon receipt. Naturally, binary files will have lit-
tle meaning on the foreign host. When receiving,
Kermit reads bytes from the communication line 5 at a
time, ignoring the 8th bit on the first 4, and set-
ting bit 35 of the current word on disk from the 8th
bit of the 5th byte. 7-bit is the default mode for
receiving.
AUTO When sending, take note of the bytesize with which
the file is stored in the DEC-20 directory. If the
byte size is 8, then use 8-bit i/o. If it is any-
thing else, use 7-bit i/o as described above. This
lets mixed groups of files be sent correctly,
provided they are stored correctly on the DEC-20.
When receiving, AUTO mode is the same as SEVEN-BIT
mode; the DEC-20 has no way of knowing whether an in-
coming file is binary or not, nor how it should be
stored. If you are sending binary files to the
DEC-20 from a micro, you have to tell the DEC-20 to
store them with 8-bit bytesize; if you don't, they
cannot be correctly restored to the micro. AUTO is
the default mode.
IBM-FLAG ON (or OFF)
LOCAL -- Allow the transfer of files to and from an IBM host.
This causes the DEC-20 to wait for the IBM turnaround character
(normally XOFF, CTRL-Q) before sending any characters out on
the line, to send the required parity, and to strip away parity
on incoming characters. When CONNECTing to the IBM host, local
(half duplex) echoing will be done.
LINE #<o>$
LOCAL -- Use the specified TTY line for subsequent CONNECT or
file transfer, rather than the controlling terminal. Only use-
ful if you can assign another TTY line on the DEC-20, and if
that line is connected (directly, via an autodialer, or some
other way) to a TTY port on another computer. Use whatever
parity, duplex, and escape character were specified in the most
recent SET commands, NONE, HALF, and CTRL-Y by default, respec-
tively. Note that you don't have to change your own terminal
- 31 -
speed to match the other line's. SET LINE n puts Kermit-20 in
"local" mode. To get back to (the default) "remote" mode,
simply type SET LINE.
PARITY <parity>
Allows you to adjust the parity on characters sent by KERMIT-20
to another system's requirements. The possibilities are NONE,
EVEN, ODD, SPACE, or MARK. If NONE, then the 8th bit can be
used for data when sending and receiving binary files. If
other than NONE, the 8th bit on outgoing characters will be set
to achieve the desired parity, and the 8th bit on incoming
characters will be discarded. Normally NONE. Should only be
set to one of the others if the remote host won't work without
parity. The specified parity is used for both terminal connec-
tion and file transfer. (Note, during terminal connection
-- not file transfer -- the DEC-20 normally sends EVEN parity,
but ignores parity on incoming characters.)
RETRY <parameter> <d>
Set the maximum number of times Kermit-20 will retry an opera-
tion before giving up and terminating the transfer. Parameters
are INITIAL-CONNECTION and PACKETS. The normal values are 16
and 5, respectively, but can be set higher when the connection
is noisy or other problems prevent a transfer from completing
successfully.
RECEIVE <parameter> <value>
These commands allow you to specify to the other Kermit what
the packets it sends should look like, or to inform this Kermit
what to expect.
END-OF-LINE <o>
The character the other Kermit should terminate its
packets with, CR (ASCII 15) by default. KERMIT-20 does
not require any special "line terminator" after a
packet.
PACKET-LENGTH <d>
The longest packet the other Kermit may send. Legal
values are 10 to 94; default is 80.
PADDING <o>, PADCHAR <o>
Inter-packet padding. The DEC-20 does not need any
padding.
PAUSE <f>
When receiving a file, pause the specified number of
seconds (which may have a fractional part, e.g. 0.75)
between receipt of a packet and sending the ACK or NAK.
This can be useful if a continuous stream of incoming
packets seems to be causing trouble for the DEC-20's
communications front end. Default is no pause.
QUOTE <o>
The character the other Kermit should use for quoting
control characters, normally ASCII 43 ("Æ"). There
- 32 -
should be no reason to change this. Permissible values
are 41 ("!") to 176 (""), i.e. the ASCII characters in
the printable range.
START-OF-PACKET <o>
The character the other Kermit will be using to start
its packets. Normally ASCII 1 (SOH, CTRL-A). If the
other Kermit is incapable of transmitting an ASCII 1,
you may use this command to tell Kermit-20 what control
character to expect. Permissible values are 1 (CTRL-A)
to 37 (CTRL-Underscore).
TIMEOUT <d>
The minimum number of seconds after which the remote
Kermit should time out when waiting for a packet. You
may adjust this as necessary to accomodate various line
speeds, or to compensate for slow systems. Legal
values range from 1 to 94 seconds.
SEND <parameter> <value>
These commands allow you to specify how outgoing packets should
look, in case the other Kermit has nonstandard requirements.
END-OF-LINE <o>
The octal value of the ASCII character to be used as a
line terminator for outgoing packets, if one is re-
quired by the other system. Carriage return (15) by
default. Some systems may prefer LF (linefeed, ASCII
12) or some other control character.
PACKET-LENGTH <d>
Maximum packet length to send, decimal number, between
10 and 94, 80 by default.
PADDING <o>, PADCHAR <o>
How much padding to send before a packet, if the other
side needs padding, and what character to use for pad-
ding. Defaults are no padding, and NUL (ASCII 0) for
the padding character. No cases are presently known
where this is necessary.
PAUSE <f>
When sending a file, pause the specified number of
seconds before sending each packet. This can be useful
if the system receiving the file is having trouble
keeping up. Default is no pause.
QUOTE <o>
The printable character to use for quoting of control
characters. 43 ("Æ") by default. There should be no
reason to change this.
START-OF-PACKET number
The control character that marks the beginning of an
outgoing packet. Normally SOH (Control-A, ASCII 1).
Change this only if the other Kermit can't input a
- 33 -
Control-A. The two Kermits must agree about the
start-of-packet character.
TIMEOUT <d>
The minimum number seconds to wait for a packet before
trying again. If receiving a file, this means sending
a NAK for the expected packet. If sending a file, this
means resending the same packet in hopes of getting the
expected ACK. The number specified will be adjusted on
a per-packet basis by Kermit-20 to compensate for the
system load, up to the maximum value of 94 seconds.
SHOW #parameter$
Show the settings of parameters that can be affected by the SET com-
mand, plus the version number of KERMIT-20 and some other information.
Various parameters may be specified; type SHOW ? to see them. The
default is ALL.
STATISTICS
Display statistics about the most recent transmission, including the
effective baud rate (actual user data bits per nominal line speed).
Work on Kermit-20 continues at Columbia. Planned future enhancements include:
- Addition of new server functions: directory, type, delete, etc, plus
user commands to invoke them.
- Host commands -- pass a command string to the TOPS-20 EXEC for execu-
tion.
- Terminal interrupts to stop or report status of a transfer in
progress.
- Error correction technique options beyond current single-character
checksum: 2-character checksum, 16-bit CRC, etc.
- 8th-bit quoting, to allow transfer of binary files with systems that
can't use the parity bit for data.
- PUSH command for local operation.
- TAKE command.
- Initialization files.
3.4. TOPS-10 KERMIT
The DECsystem-10 version of Kermit was adapted by Nick Bush, Bob McQueen, and
Antonino Mione at the Stevens Institute of Technology in Hoboken NJ from an
earlier DECSYSTEM-20 version. Local-mode operation (CONNECT) was added by
Vanya Cooper, Pima Community College, Tucson, AZ.
In general, the commands and other system dependencies for Kermit-10 are the
same as Kermit-20. In particular, the TOPS-10 Galaxy facility (ORNMAC) for
simulation of the TOPS-20-style command parser (COMND) was used to preserve the
- 34 -
same style command interface. Major differences between the versions are that
Kermit-10 does not allow wildcarding of the file specification in the SEND com-
mand, and there is not yet a TOPS-10 Kermit server, nor can KERMIT-10 issue the
special server commands (BYE, FINISH, GET).
TOPS-10 file specifications are of the form
DEV:NAME.TYP#P,PN$
where NAME is at most 6 characters long, TYP at most 3, and #P,PN$ is a
"project,programmer" number identifying the directory. DEV and PPN can be
omitted when the file is in the user's own directory, and only NAME.TYP is sent
in the file header by KERMIT-10.
KERMIT-10 commands are listed here. See the TOPS-20 section, above, for
detailed descriptions:
CONNECT ( to line ) <o>
EXIT (to the monitor)
HELP (with subject) <Topic for which help is wanted>
QUIT (to the monitor)
RECEIVE (file spec) #<filespec>$
SEND (file spec) <filespec>
SET <one of the following>
DEBUGGING ON (or OFF)
DELAY <d>
ESCAPE-CHARACTER <o>
FILE-BYTE-SIZE EIGHT-BIT (or SEVEN-BIT)
FILE-WARNING ON (or OFF)
LINE <o>
RECEIVE <One of the following>
END-OF-LINE <o>
PACKET-LENGTH <d>
PAD-LENGTH <d>
PADDING-CHARACTER <o>
TIME-OUT <d>
SEND (same options as RECEIVE)
SHOW (same options as SET, plus SHOW ALL)
STATUS
KERMIT-10 has self-contained code for the CONNECT command; there is no separate
TTLINK program.
- 35 -
3.5. VAX/VMS KERMIT
KERMIT-32 for DEC VAX-11 VMS systems was written in Bliss-32 at Stevens In-
stitute of Technology by Bob McQueen. KERMIT-32 can be run from SYSÅSYSTEM:.
It will prompt for input from SYSÅCOMMAND:. The commands and capabilities are
approximately equivalent those of KERMIT-10. KERMIT-32 can operate as a remote
server.
Here is a summary:
CONNECT #dev:$
Initiate an outgoing connection over another terminal device, which may
be connected to another computer via a dedicated line or an autodialer.
Note, IBM mode (half duplex, line turnaround handshake) has not been
implemented.
HELP keyword #keyword...$
EXIT, QUIT
RECEIVE #file-specification$
SET parameter value
DEBUGGING ON or OFF
Display packet traffic and other debugging information at the
console terminal.
DELAY seconds
ESCAPE character
For CONNECT.
FILE_TYPE type
ASCII For text files
BINARY For non-text files. Note that RMS-32 files are not
transferred correctly because the attributes are lost.
LINE device-specification
The default terminal line for CONNECT and file transfer, e.g.
TTA0:.
RECEIVE parameter value
PACKETLENGTH value
Maximum length for incoming packets, 10-96.
PADDING value
Number of padding characters (normally not needed).
PADCHAR value
Character to use for padding if PADDING nonzero, an oc-
tal number 0 to 37 or 177.
TIMEOUT value
How many seconds to wait for an incoming message before
trying again.
ENDOFLINE value
The character required to terminate incoming messages.
Normally no need to change this.
QUOTE Printable character to be used in incoming messages to
quote control characters.
- 36 -
SEND paramater value
The parameters and values are the same as for SET RECEIVE.
SEND file-specification
Send the file or file group specified. The file specification may con-
tain VMS wildcards.
SERVER Act as a Kermit Server. Accept all further commands only from the
other Kermit. These commands may be RECEIVE, SEND, FINISH, and BYE.
Note that although KERMIT-32 can act as a server, it cannot yet act as
a user of a server when in local (CONNECT) mode -- KERMIT-32 can SEND
files to a server, but cannot request the server to send files, and
cannot issue BYE and FINISH commands to a server.
SHOW parameter
Show the value of a parameter that can be set by the SET command.
Also, SHOW ALL to show all of them.
3.6. IBM VM/CMS KERMIT
Written in IBM 370 assembly language to run under VM/CMS on IBM 370-series
mainframes (System/370, 303x, 43xx, 308x, ...). These are half duplex systems;
the communication line must "turn around" before any data can be sent to it.
The fact that a packet has been received from the IBM system is no guarantee
that it is ready for a reply. Thus any Kermit talking to this system must wait
for the line turnaround character (XON) before transmitting the next character.
IBM systems talk to their terminals through a communications front end (IBM
3705, 3725, COMTEN 3670, etc). These front ends generally insist on using the
8th bit of each character for parity. This means that binary files (files con-
taining other than ordinary letters, digits, punctuation, carriage returns,
tabs, and so forth) can not be correctly sent or received by these systems with
Kermit (protocol version 1).
The IBM system under VM/CMS is unable to interrupt a read on its "console".
This means that the IBM version of Kermit cannot timeout. The only way to
"timeout" CMS Kermit is from the other side -- typing a carriage return to the
micro's Kermit causing it to retransmit its last packet, or an automatic
timeout as provided by Kermit-20. For this reason, CMS Kermit waits thirty
seconds before sending its first packet when sending files from VM/CMS. This
gives the user sufficient time to return to the local Kermit and issue the
Receive command. Otherwise, a protocol deadlock would arise requiring manual
intervention by the user.
Also, VM/CMS stores files as records rather byte streams. VM/CMS Kermit has to
worry about assembling incoming data packets into records and stripping CRLFs
from incoming lines, and also appending CRLFs to -- and stripping trailing
blanks from -- outgoing records.
The VM/CMS file specification is in the form
FILENAME FILETYPE FILEMODE
(abbreviated FN FT FM). FM is equivalent to a device specification on DEC or
microcomputer systems (FN FT FM would translate to FM:FN.FT). FILENAME and
- 37 -
FILEMODE are at most 8 characters in length, each, and FILEMODE at most 2.
When FILEMODE is omitted from a filespec, the user's own disk is assumed.
Kermit-CMS sends only FILEMODE and FILETYPE, and converts the intervening blank
to a period for compatibility with most other operating systems. Kermit-CMS
Commands:
SEND FN FT #FM$
Send the specified file(s), using * or % as the wildcard characters (*
will match any number of characters while % matches only one).
Kermit-CMS assumes the file is located on the A disk, and sets the
filemode to A1. If, however, the file is located on a different disk,
the filemode must be cited. Also, note that if you use * for the
filemode, Kermit-CMS will send only the first file that matches. Ex-
amples:
The command SEND CEN SPSS will send CEN SPSS A1. To send the
same file located on your B disk, you must specify: SEND CEN
SPSS B. SEND * FORTRAN will send all fortran files on your A
disk. SEND ABC% EXEC will send all exec files with a four let-
ter filename beginning with ABC. If you have the file PLOT SAS
on your A disk and your B disk, SEND PLOT SAS * will send PLOT
SAS A1.
RECEIVE #FN FT #FM$$
Receive the file(s) sent from the other Kermit. If a file specifica-
tion is not included, Kermit-CMS will use the name(s) provided by the
other Kermit. Use the file specification to indicate a different
filename or a disk other than the A disk (in this case, the file name
and type must also be supplied or = = FM can be used.) Examples:
To receive files using the filename(s) sent by the micro, use:
RECEIVE. To save a file under a different name, specify:
RECEIVE ABC FORTRAN. To save the file under the same name but
on the B disk, specify: RECEIVE ABC FORTRAN B, or RECEIVE
= = B.
SET <parameter> <value>
Set the parameter to the specified value. Legal Set commands are:
RECFM <c>
Denotes the record format to be used when creating the file.
Only fixed and variable length records are allowed, where vari-
able is the default. Indicate the desired record format by ei-
ther an F or a V.
LRECL <d>
Indicates the logical record length. The default is set to 80,
and the maximum allowed is 256.
QUOTE <c>
The quote character you wish to use in place of the default
(Æ). It must be a single, printable character from among the
following: 33-62, 96, or 123-126 (decimal).
END <d> Indicates the end-of-line character you choose to send. The
default is CR (ASCII 13 decimal), but can be set to any two
- 38 -
digit number between 00 and 31 (decimal).
PAC <d> Allows the user to specify the packet size the micro should use
when sending to Kermit-CMS. The range is 26-94 (decimal),
where 94 is the default.
SHOW <parameter>
Displays the current value of any variable that can be changed via the
SET command.
STATUS Returns the status of the previous execution of Kermit-CMS. Therefore,
STATUS will either display the message "Kermit completed successfully",
or the last error encountered prior to aborting.
CMS Issues a CMS command from within Kermit-CMS.
CP Issues a CP command from within Kermit-CMS.
? Lists all legal Kermit-CMS commands.
This is a list of other salient facts about Kermit-CMS:
1. The commands are supplied with a help option, so a question mark can
be typed to get the appropriate format or a list of options. The
question mark, however, must be followed by a carriage return;
Kermit-CMS will respond and display the prompt again. For instance,
SET ? will list all valid options for the SET command.
2. When receiving files, if the record format is fixed, any record
longer than the logical record length will be truncated. If the
record format is variable, the record length can be as high as 256.
For sending files, the maximum record length is 256.
3. Before connecting to the IBM mainframe from other systems (like the
various microcomputer and PC Kermits, DEC-20 Kermit, etc), you
should set the IBM flag ON so that echoing, parity, and handshaking
can be done the way the IBM system likes.
4. Note that "(" and ")" act as word separators on the input line.
Therefore, if you try to set the quote character to "(*" or "*(",
for example, only the first character will be used.
5. Since some Kermits do not send an error packet when they "abort",
Kermit-CMS does not always know the micro has stopped sending it in-
formation. Therefore, when you connect back to the IBM, Kermit-CMS
may still be sending packets (they will appear on the screen). The
user must hit a carriage return until Kermit-CMS has sent the max-
imum number of packets allowed and aborts. The error message,
however, will not indicate that communication stopped because the
micro aborted, but rather that no start of header character was
found.
6. The minimum send packet size Kermit-CMS will allow is 26. This is
necessary to avoid an error while sending the filename or an error
packet. If the micro tries to set the value to be less than 26,
Kermit-CMS will immediately abort with an error of "Bad send-packet
- 39 -
size."
7. While the IBM's communication front end processor translates all in-
coming characters from ASCII terminals to EBCDIC, Kermit-CMS trans-
lates the data it reads back to ASCII (characters not representable
in ASCII are replaced by a null). Not only is it easier to work
with ASCII characters, but it makes things more consistent throu-
ghout the many versions of Kermit. When the packets are sent to the
micro, Kermit-CMS converts all data back to EBCDIC. The ASCII to
EBCDIC translation table can be found in the Appendix.
8. If a transfer becomes stuck, you can CONNECT back to the CMS system
and type a lot of carriage returns -- each one will cause KERMIT-CMS
to retransmit the current packet, until the retransmission limit is
reached, and you will be back at "KERMIT-CMS>" command level.
9. Kermit-CMS supplies the micro and the user with numerous error mes-
sages. If the execution must be abnormally terminated, an error
packet is sent to the micro before Kermit-CMS stops. The same mes-
sage can be retrieved via the STATUS command when Kermit-CMS returns
and displays the prompt. If Kermit-CMS aborted because the maximum
amount of retries was exceeded (20 on initialization packets and 5
on others), the error message will display the most recent error
(i.e. the last NAK Kermit-CMS encountered). If execution stops be-
cause the micro gave up, the error message will convey that to the
user, but it is the micro's responsibility to pinpoint the error.
The messages Kermit-CMS gives are as follows:
"Bad send-packet size"
Sent when the micro attempts to set its receive buffer size to a
value that is less than 26 (the minimum that Kermit-CMS will
accept) or larger than 94, the maximum. It will also occur if
Kermit-CMS tries to send a packet that is larger than the max-
imum specified.
"Bad message number"
This and the following messages flag inconsistencies in a Kermit
packet.
"Illegal packet type" -- This can be caused by sending server com-
mands.
"Unrecognized State"
"No SOH encountered"
"Bad Checksum"
"Bad character count"
"Micro sent a NAK"
"Lost a packet"
"Micro aborted"
The micro abnormally terminated the transfer.
"Illegal file name"
When receiving the name of the file from the micro, Kermit-CMS
expects it to be in the format 'filename.filetype'. If the
filename, filetype, or dot is missing, Kermit-CMS will reject
(NAK) the packet. Also, if either the filename or filetype ex-
ceeds eight characters, it will be truncated.
"Invalid lrecl"
Kermit-CMS will abort on any file-system error it encounters
when reading from the file it is to send. It can only send
- 40 -
files with variable or fixed length record formats, therefore,
Wylbur Edit or Packed format files will cause an error.
"Permanent I/O error"
This signifies a permanent I/O error that occured when reading
from an existing file. Execution is aborted immediately.
"Disk is read-only"
Attempt to write on a read-only disk.
"Recfm conflict"
If a filename conflict arises, Kermit-CMS will append the
received file to the existing one, provided the record formats
of the two are the same. Otherwise, this error will cause a
halt of the execution.
"Disk is full"
Refers to any error regarding limitations on a user's storage
space. Most likely, it signifies that the receiving disk is
full, but the error can also mean that the maximum number of
files allowed has been reached, or virtual storage capacity has
been exceeded, and so on.
"Err allocating space"
Kermit-CMS keeps a table of all files it has sent to the micro,
allocating extra space if more than ten files are sent at one
time. If there is an error obtaining more space, Kermit-CMS
will abort with this error.
Work on VM/CMS Kermit continues. Planned future enhancements include:
1. 8-bit quoting, to allow binary files to pass through communication
front ends that insist on using the 8th bit for parity.
2. Ability to act as a Kermit Server.
3. Ability to SET LINE, so that Kermit-CMS can be used as a local Ker-
mit, connecting to a remote host over another communication port.
3.7. UNIX KERMIT
A sample, working implementation of the Kermit "kernel" was written in the C
language, and widely distributed in the Kermit Protocol Manual. This kernel
was intended merely to illustrate the protocol, and did not include a "user
interface", nor some of the fancy features like server support, 8-bit quoting,
file warning, timeouts, etc. Several sites have added the necessary trappings
to make this a production version of Kermit, usually under the UNIX operating
system.
The COMND style of user/program interaction favored by Kermit (program types
prompt, user types command followed by operands, program types another prompt,
etc) is contrary to the UNIX style, so UNIX implementations have a style more
familiar to UNIX users. C versions of Kermit are running successfully on VAX
and PDP-11 UNIX systems, and the SUN Microsystems MC68000-based workstation.
UNIX filespecs are of the form
dir1/dir2/dir3/ ... /filename
where the tokens delimited by slashes form a path name, and by convention are
- 41 -
each limited to 14 characters in length. The final token in a path is the ac-
tual file name. By convention, it is of the form name.type, but there is noth-
ing special about the dot separating name and type; to UNIX it's just another
character, and there may be many dots in a filename.
3.7.1. Cornell UNIX Kermit
A version was done at Cornell by Dean Jagels and Alison Brown. It is the most
ambitious Kermit implementation for UNIX. Several modifications were made to
the protocol; in particular, the Cornell version allows for either a
2-character CRC or the single character checksum used by standard Kermit (the
selection is made during the negotiation at initial connection). The programs
were rewritten from the ground up, with various sections picked apart to form
layers corresponding to the ISO network reference model, a "write-thru" state
was added incorporating the CONNECT command into the protocol itself, and ter-
minal interrupts were also added. Wildcard sends are expanded in the UNIX
shell, which feeds the resulting filespecs one at a time to Kermit.
3.7.2. Columbia UNIX Kermit
The version in use at Columbia was adapted from the Kermit kernel by Chris Maio
and Bob Cattani of the Columbia University Computer Science Department for the
SUN and VAX under UNIX, and is described below by Chris Maio. It is a version
1 Kermit (no server functions).
This version more or less conforms to the Unix command parsing conventions, and
has the ability to time out.
The new command syntax isn't as user friendly as the that of the other im-
plementations, but it is closer to what most Unix users will expect. Roughly,
this is how it works: You can only do one thing with any one invocation of Ker-
mit; either connect, send, or receive. The format is basically like that of
the "dump" or "tar" tape utilities, in that the first command line argument is
a word made up of letters which specify the desired function and options. This
"word" is then followed by the arguments for the options, in the order in which
the options appear in the command "word," and then a list of files to be sent,
if the send command is being invoked. The commands are:
c connect
s send
r receive
and the options are:
d debug mode (no argument)
i image (8-bit) mode; no mapping from LF to CRLF, and all eight bits of
each byte are sent or received. if this option is not specified, LF is
mapped to CRLF, and only 7 bit bytes are sent or received.
l line (the next arg is a tty name, e.g. /dev/tty01)
- 42 -
b baud rate (the next arg is a decimal number, e.g. 1800)
e escape char (next arg is a decimal number, interpreted as the ascii
code for the desired escape character)
The defaults are no debug mode, no external tty line (i.e. "host" mode
-- remote -- operation), the system default baud rate, and ^D as the escape
character. For example, assume that a user on a micro running Unix wants to
transfer files between her machine and a DEC-20 over a hardwire line, say,
/dev/tty13, at 4800 baud, using ^B (ASCII code 2) as her escape character.
Note that the order in which arguments are given must match the order in which
corresponding letters appear in the first "word":
% kermit clbe /dev/tty13 4800 2
Kermit: connected
Ø
Ø; now we're on the -20
Økermit
Kermit-20>send *.c
(user types ^B to get back to Unix)
Kermit: disconnected
%
% kermit rlb /dev/tty13 4800 (no escape character needed here)
Receiving CONNECT.C
Receiving MAIN.C
Receiving RECEIVE.C
Receiving SEND.C
Receiving UTILS.C
OK
% (now, let's send to the DEC-20)
% kermit clbe /dev/tty13 4800 2
Kermit: connected.
(now we're on the -20)
Kermit-20>receive
^B (user types ^B again to get back)
Kermit: disconnected.
%
% kermit slb /dev/tty13 4800 *.pl
Sending learn.pl
Sending parse.pl
OK
%
While the format shown above might seem verbose, it's easy to set up shell
scripts or command macros so that, for a given tty line, all one need type is
"connect", "send file1 file2 ..." or "receive."
"Host" (remote) mode operation is much simpler. When running Kermit in host
mode, nothing about the tty line need be specified, so the format reduces to
% kermit r
to receive files sent by the "remote" Kermit, and
- 43 -
% kermit s file1 file2 file3 ...
to send files back to your local system. Unfortunately, this command syntax
doesn't allow you to own the tty line from the local machine to the "host" con-
tinuously, but this shouldn't be a problem for most users.
The current version has been used to transfer files between VAXes running
Berkeley 4.1bsd Unix, a Sun workstation running Unisoft Unix (basically Unix
Version 7 with Berkeley extensions), and a DEC-20, over dialups at 1200 baud,
the PACX at 4800 baud, and hardwire lines at 9600 baud, all with no noticable
problems. None of the special features of Berkeley Unix are used, so only min-
imal, straightforward changes should be necessary to get Kermit up and running
on other flavors of Unix.
Unix Kermit presently does not send or process error-message packets.
3.8. RT-11 KERMIT in Pascal
An implementation of Kermit was written in OMSI Pascal by Philip Murton at the
University of Toronto for the RT-11 operating system, using the Software Tools
techniques (Kernighan & Plauger, Addison-Wesley 1981), with UNIX-style com-
mands. The version received at Columbia was incomplete and would not run.
Michael Weisberg of the Columbia CS Department modified the Toronto version to
run on his RT-11 system at Mt. Sinai Hospital. Here are his comments:
This is NOT a portable version due to the limited I/O facilities of Pascal no
such animal is currently possible. This version should work on all reasonably
configured RT11 sytems and has been tested on several different processors.
This version is largely based on the work of Philip Murton, University of
Toronto Computing Services, Communications and Field Service. The main
modifications are that the command structure have been modified to conform more
closely to the Kermit standard although not exactly (they are documented by the
HELP command) and the system has been made runnable as is under RT11 at the
price of adding noportable I/O routines.
Finally there is still alot of work that would be nice to do here especially
improving the command parser and adding timeout capabilities (i.e. making this
Kermit "smart") and adding the server capabilities. My encouragements to all!
KERMIT-RT Commands:
C #h/f/d/v$ Connect #Half/Full duplex, Debug/Verbose modes$
(any combination of 3 switches possible.)
S <filename> æ,<filename>å Send fileæså
R æ<filename>å Recieve files
P Print files recieved on local printer
H Help on Commands
The Gandalf PACX is used as a port contention unit at Columbia, supporting
line speeds up to 4800 baud.
- 44 -
E Exit Kermit
Q Quit
A file KERMIT.PRM may be used change the defaults; here is a sample line which
should be the first and only line of the file:
( Ø-Æ
This is just the raw data field from the Kermit SEND-INIT packet. The meaning
of each character is as follows:
<rcv size><timout><npad><pad char><eol char><quote char>
All characters are the CHAR function numeric equivalents except the quote char
which is itself and the PAD char which is the CTL function equivalent. Hence
the above line decodes to:
Receive size: 94
Time out: 8 seconds
Number of PAD chars:
0
PAD character: null
EOL character: Carriage return
QUOTE character: Æ
See the GETPARAM procedure in the RT KERMIT program, or the Kermit Protocol
Manual, for further details.
3.9. 8080/Z80 CP/M KERMIT
Implementations of Kermit-80 presently exist for the DEC VT180 (Robin), the DEC
Rainbow-100 and DECmate II, the Intertec Superbrain, the Heath/Zenith 89 and
Z100, the Apple II with the Z80 SoftCard, the Osborne 1, the TRS-80 II with
CP/M, the Telcon Zorba, and the Vector Graphics CP/M system. There is also a
"generic" CP/M version that should run any any 8080-compatible CP/M system, but
which may provide less performance.
Warning -- The Rainbow-100 implementation only works at speeds of up to 1200
baud!
Since Kermit-80 runs on a standalone micro, it is always in control of the
screen -- it is always local. Thus, it always keeps the screen updated with
the file name and the packet number, whether sending or receiving. Kermit-80
can't time out, so if the transmission gets stuck (and you can tell that this
has happened if the screen fails to change for a while) you can type carriage
return to have the micro do what it would have done on a timeout, namely
NAK the expected packet to cause to foreign host to send it again (or, if the
micro is sending, to retransmit the last packet). If the foreign host is
capable of timeouts (as the DEC-20 is) this action should not normally be
necessary, but micro/micro or micro/IBM-mainframe transfers could require this
kind of manual intervention.
Most CP/M versions of Kermit only allow files to be received onto the default
disk, the disk you are connected to. This means in order to receive files onto
your B: disk you must give the CP/M command B: and see the B> prompt before
- 45 -
running Kermit-80.
CP/M file specifications are of the form DEV:NAME.TYP. DEV is a device, such
as disk A: or B:. NAME may be up to 8 characters in length, TYP up to 3.
NAME.TYP is sent in the Kermit file header packet.
Kermit-80 Commands:
CONNECT Establish a "virtual terminal" connection to any host that may be con-
nected to the serial port, i.e. pass all typein to the serial port and
display all input from the serial port on the screen. Also, emulate a
DEC VT52 to allow cursor control, screen clearing, etc., if
VT52-EMULATION is ON (see below), in which case you should also set
your terminal type on the remote host to VT52. (Some versions emulate
other terminals.) The escape character differs from micro to micro.
Here is a list of the present versions and their default escape charac-
ters ("^" indicates that the following character is typed while holding
down the CTRL key), and what terminals they emulate:
- VT180 (Robin) ^ (CTRL-backslash) (VT100)
- DECmate II ^ (CTRL-backslash) (VT100)
- Rainbow-100 ^ (CTRL-backslash) (VT100, 1200b or
below)
- Heath/Zenith 89 ^ (CTRL-backslash) (VT52)
- Heath/Zenith Z100 ^ (CTRL-backslash) (VT52)
- Apple II (with SoftCard) ^$
(CTRL-rightbracket) (VT52)
- Osborne 1 ^ (CTRL-backslash) (ADM3A)
- TRS-80 II ^_ (CTRL-downarrow) (ADM3A)
- SuperBrain ^$ (CTRL-rightbracket) (VT52)
- Vector Graphics (tilde) (VT52)
- Ohio Scientific ^$ (CTRL-rightbracket) (dumb terminal)
- Telcon Zorba ^$ (CTRL-rightbracket) (VT52)
- Generic ^ (CTRL-backslash) (dumb terminal)
The available arguments to the escape character are:
B Send a BREAK signal. No Kermit-80 currently implements this func-
tion.
C Close Connection, return to Kermit-80> command level.
S Display Status of connection, but maintain remote connection.
? List available arguments.
^$ (or whatever - a second copy of the escape character) Send the es-
cape character itself to the remote host.
SEND <filespec>
Send file(s) specified by <filespec> to the remote Kermit. The
<filespec> may contain CP/M wildcards.
RECEIVE Receive file(s) from the remote Kermit. Store them under the names
provided in the file headers supplied by the remote host. If the names
aren't legal, use as many legal characters from the name as possible
(see the description of SET FILE-WARNING below). If there's a con-
flict, and FILE-WARNING is ON, warn the user and try to build a unique
name for the file. When Kermit-80 is talking to a Kermit Server on the
host, you may include a filespec in order to request the server to send
- 46 -
files to you, for example: receive hlp:k*.hlp
LOG <filespec>
When CONNECTed to a foreign host as a terminal, log the terminal ses-
sion to the specified diskette file. This functionality depends on the
remote host's ability to do XON/XOFF flow control.
BYE When talking to a remote Kermit Server, this command shuts down the
server and logs it out, and also exits from Kermit-80 to CP/M command
level.
LOGOUT Like BYE, but leaves you at Kermit-80 command level.
FINISH Like LOGOUT, but shuts down the remote server without logging it out.
Leaves you at Kermit-80 command level; subsequent CONNECT commands will
put you back at host system command level.
SET <parameter> #<value>$
Set the specified parameter to the specified value. Possible settings:
FILE-WARNING ON (or OFF)
Warn user of filename conflicts when receiving files from
remote host. This is especially important when the remote host
has less restrictive (e.g. longer) filenames than the local
micro. ON by default.
VT52-EMULATION ON (or OFF)
When connected as a terminal to a foreign host, controls
whether the micro emulates a VT52 or runs in "native mode".
VT52 emulation is ON by default, except on micros that already
have terminal functionality built in, such as the DEC VT180 and
Rainbow, that act as VT100-series terminals. The Osborne and
TRS80 Kermits emulate the ADM3A.
LOCAL-ECHO ON (or OFF)
When you CONNECT to a remote host, you must set LOCAL-ECHO ON
if the host is half duplex, OFF if full duplex. OFF by
default.
ESCAPE Change the escape character for virtual terminal connections.
Kermit-80 will prompt you for the new escape character, which
you enter literally.
BAUD SuperBrain and Osborne only. Display menu of available baud
rates for serial port, allow user to select one of them. For
other systems, you must set the port baud rate from CP/M or
other setup mechanism before running Kermit-80.
PARITY Sets parity for outgoing characters to one of the following:
NONE, SPACE, MARK, EVEN, or ODD. On input, if parity is NONE,
then the 8th bit is kept (as data), otherwise it is stripped
and ignored. The parity setting applies to both terminal con-
nection and file transfer.
IBM ON (or OFF)
Allow the transfer of files to and from the IBM VM/CMS system.
- 47 -
This makes Kermit-80 wait for the IBM turnaround character
(XON), ignore parity on input, send appropriate parity, and use
local echoing during CONNECT. If you don't give this command,
IBM mode is OFF. SET IBM, however, is equivalent to SET IBM
ON.
CPM-CREATED-FILE ON (or OFF)
Indicate to Kermit-80 that the file to be sent was created by
CP/M (e.g. by ED) rather than transferred to the micro by Ker-
mit from some other kind of system. If you do not set this
flag when sending files created under CPM they may wind up with
extraneous characters at the end (after a CTRL-Z) on the remote
host.
The various versions of KERMIT-80 should be available in the KERMIT area on
your host computer for downloading, under names like CPMROBIN.HEX,
CPMHEATH.HEX, etc. See the section on installing KERMIT for more information.
Work will continue on KERMIT-80. Some areas that need improvement include:
1. A better logging function for capturing remote session transcripts,
"unguarded" capturing of remote files. The current facility loses
characters at high baud rates. Double buffering, with larger buf-
fers, might do the trick.
2. During terminal emulation, the ability to transmit a BREAK signal to
the remote host. Very important for IBM mainframes.
3. 8th-bit quoting for exchanging binary files with systems that can't
control the parity bit.
4. More commands for servers -- remote directory, type, delete, etc.
5. Initialization files.
6. Printer control.
7. Isolation of system-dependent sections of code to allow new im-
plementations to be added more easily, without even recompiling the
system-independent part.
3.10. Generic KERMIT-80
"Generic Kermit-80" is a implementation of Kermit that should run on any 8080-
compatible CP/M system no modification at all, or perhaps only a minor one.
Unlike other Kermit-80 implementations, it contains no system-dependent
manipulation of the serial port or keyboard. All I/O is done with standard
CP/M BIOS calls, and I/O redirection is done using the CP/M IOBYTE function,
which, according to the Digital Research CP/M Operating System Manual, is an
optional feature of any particular CP/M implementation. If your system does
not provide the IOBYTE function, Generic Kermit-80 will not work; furthermore,
not all systems that implement IOBYTE do so in the same way.
The reason all Kermit-80 implementations aren't generic is that a good deal of
speed is sacrificed by getting all services from the operating system. While a
- 48 -
specific implementation of Kermit-80 may be able to operate at 4800, 9600, or
even 19200 baud, Generic Kermit will fail to work on some systems at speeds in
excess of 1200 baud.
Generic Kermit also differs from other Kermit-80 implementations in that it
does not do fancy screen control during file transfer; it simply types the file
names, packet numbers, and messages in sequence across and down the screen.
This works best if you can put your micro or terminal in "autowrap" mode;
otherwise the packet numbers will pile up in the rightmost column; the
filenames and messages will always appear on a new line, however.
Note that VT180, DECmate-II, and Rainbow-100 Kermit are simply adaptations of
Generic Kermit that do VT100 (ANSI) screen control during file transfer.
To get Generic Kermit on to your system (if you can't get it on a floppy disk),
use whatever procedure is available to you on your micro to download the file
KER:CPMGENERIC.HEX. The DDT program listed later will do the trick on most
systems. DEC Rainbow users who also have access to a VT180 Robin can use the
Robin's Kermit to get Generic Kermit-80 onto the Robin's floppy, which can then
be read directly by the Rainbow.
3.11. 8086/8088 KERMIT
Kermit-86 is almost identical to Kermit-80 in functionality. If you are new to
Kermit, you should go back and read the section on 8080/Z80 CP/M Kermit. This
section will concentrate on the differences from the 8080 version.
Kermit-86 was written initially to run on the IBM PC, and has also been adapted
(by Nick Bush at Stevens Institute of Technology) to run on the Heath/Zenith
Z100. The IBM PC version also works on PC-compatible systems, like the Compaq
portable.
When acting as a virtual terminal, Kermit-86 emulates the DEC VT52 . The
Kermit-86 command interpreter is modeled after the DEC-20's, allowing keyword
abbreviation (and completion and guide words if you type ESC) and "?" help at
any point in the command. Unlike Kermit-80, Kermit-86 is interrupt driven; an
interrupt is generated whenever data comes in to the serial port. Kermit
stores the characters in a buffer and attends to them later - this way data is
not normally lost if the host is too fast for the PC.
PC-DOS or MS-DOS file specifications are of the form DEV:NAME.TYP. DEV is a
device, such as disk A: or B:. NAME may be up to 8 characters in length, TYP
up to 3. NAME.TYP is sent in the Kermit file header packet.
Kermit-86 Commands:
BYE When talking to a remote Kermit Server, this command shuts down the
server and logs it out, and then exits from Kermit-86 to DOS.
CONNECT Make a terminal connection to a remote system. Type an escape se-
Hint: the Delete key is CTRL-Backarrow on the IBM PC.
- 49 -
quence to get back to the PC. The escape character is CTRL-$ by
default (you can SET it to be something else if you like, see below).
Arguments to the escape character are:
C Close the connection.
S Tell status of the connection.
? List these arguments.
^$ (or whatever the escape character is) -- send the escape charac-
ter itself to the remote host.
You can send a BREAK to the host by typing CTRL-BREAK.
EXIT Exit from Kermit-86 back to PC DOS.
FINISH When talking to a remote Kermit Server, this command shuts down the
server but does not log out your job on the remote host.
HELP Print a message similar to this list.
LOGOUT When talking to a remote Kermit Server, this command shuts down the
server and logs it out. This command is similar to BYE, but leaves
you at the Kermit-86 command level.
RECEIVE #<filespec>$
Get a file or group of files from the other Kermit. Incoming file
names that are illegal under DOS are transformed to legal names by
deleting illegal or excessive characters, etc. When the remote Ker-
mit is a server, you may include a filespec to request the server to
send the file(s). If you include a filespec and the remote Kermit is
not a server, you will probably get an error message about an illegal
packet type.
SEND <filespec>
Send a file or group of files to the remote system. The filespec may
contain the wildcard character "*" to match a whole field (filename
or filetype) or the trailing characters of a field, For example,
*.FOR, A*.B*. Alternatively, the wildcard "=" matches one or zero
characters. For example, A==.TXT will match the files ABC.TXT and
A.TXT, but not ABCD.TXT.
SET Set the value of a parameter or flag. The SET options are as fol-
lows:
BAUD <d> Set terminal communications port speed to 300, 1200,
1800, 2400, 4800 (the default), or 9600 bits per
second (baud).
DEBUG Set debug mode ON or OFF (normally should be OFF).
If ON, outgoing packets will also be displayed on
your screen.
END-OF-LINE <d> Change the character used at the end of outgoing
packets to something other than the default of CR
(13). It must be a number between 0 and 31 (decimal
value of ASCII character).
- 50 -
ESCAPE <c> Change the escape character that gets Kermit-86's at-
tention when CONNECTed to a remote host. The default
is CTRL-$.
FILE-WARNING ON/OFF, default is OFF. If ON, Kermit will warn you
when an incoming file has the same name as an exist-
ing file, and rename the incoming file so as not to
destroy an existing one.
IBM Allow communication with an IBM VM/CMS system. Sets
appropriate parity, local echo for CONNECT; activates
half duplex line handshaking.
LOCAL-ECHO ON/OFF, default is OFF. This sets the duplex. It
should be ON when CONNECTing to an IBM mainframe and
OFF for CONNECTing to most other systems, including
the DEC-10, DEC-20, UNIX, etc.
PARITY EVEN, ODD, MARK, SPACE, or NONE. Select parity for
outgoing characters, during both CONNECT and file
transfer, to match the requirement of the remote
host. NONE is the default. If other than NONE, the
parity bit is stripped from incoming characters and
ignored, and binary files cannot be transferred.
VT52-EMULATION ON/OFF, default is ON. Sets the local terminal type
when CONNECTing to a remote host. Should be ON un-
less the host supports the IBM PC as a terminal in
"native mode".
STATUS Display the values of parameters that can be modified via the SET
command.
Kermit-86 only receives files onto the default disk. Therefore, before running
Kermit to get files from a remote host, you must "connect" to the disk you want
to put the files on, using the "A:" or "B:" command. You can send files from
any disk.
Kermit-86 provides complete support for standard ASCII files but does not treat
binary files in a general way. Some special cases of eight-bit and binary
files are programmed.
A special case exists for EasyWriter files. EasyWriter stores information in
the beginning of the file which is non-standard ASCII. Therefore, to send an
EasyWriter file to the DEC-20 or VM/CMS, first use the TRANSFER program
provided on the EasyWriter diskette. (Use the mode to translate the file to
ASCII). After you send the file to the DEC-20, run EZFIX on the -20. EZFIX
prevents extra information used by EasyWriter from becoming incorporated into
your text file. Optionally, EZFIX will change a bare linefeed to carriage
return-line feed thus making the file a standard ASCII file and suitable for
editing in EMACS. If, however, you add the carriage returns and send the file
back to the PC, you will find that EasyWriter considers that each line has an
end-of-paragraph marker. This cannot be avoided (see page E-7 of the
EasyWriter manual). No changes need to made after running the TRANSFER program
if sending to VM/CMS.
- 51 -
Since the IBM PC has a pictorial representation for every character, a small
circle is printed on the screen when the host sends a tab character. To get
the tab translated to spaces, tell the DEC-20 "term no tabs." The IBM VM/CMS
system does not replace the tab with spaces, and the user will see the circle.
Work on Kermit-86 continues. Plans for future releases include:
- General binary file support (8-bit quoting).
- Device specification for incoming files.
- Heath/Zenith-19 terminal emulation. This is a superset of VT52 that
allows insert/delete character/line editing functions, which lets the
PC take advantage of host video editors (like EMACS) that support
these functions.
Kermit-86 was written at Columbia by Daphne Tzoar, based on Bill Catchings's
8080 implementation. Acknowledgements to Bill Westfield at SRI International
for help with the terminal emulation code, and to Dick Gillmann at USC-ISI for
moderating the ARPAnet INFO-IBMPC mailing list, where we got a lot of valuable
information.
3.12. Apple II DOS Kermit
KERMIT-65 (so called because of the Apple $# 6502 processor) was contributed by
Antonino N.J. Mione of Stevens Institute of Technology in Hoboken, New Jersey.
It is modeled after KERMIT-80, and has mostly the same commands and style. It
is described here in terms of its differences from KERMIT-80:
KERMIT-65 is currently missing some features which exist in KERMIT-80. There
are also some restrictions which apply. The differences and restrictions are
as follows:
- Session logging is not included in KERMIT-65 at this time.
- KERMIT-65 does not have the commands that pass commands to a SERVER
mode KERMIT (BYE, etc.).
- IBM-mode support has not been written.
- There is no wild-carding of filenames as in KERMIT-80.
- When transferring files, the file type must be made known to
KERMIT-65 by setting the FILE-TYPE parameter to one of the following:
1. TEXT
2. APPLESOFT
3. INTEGER
4. BINARY
There is no timeout support in KERMIT-65 since the standard Apple configuration
has no accessible clock. To time out KERMIT-65 and have it resend a packet,
hit any printable character on the keyboard except a 'Q'. Typing a 'Q' during
a transfer will quit the entire transfer.
- 52 -
Seven-bit ASCII file transfer should only be attempted for text files, other-
wise data integrity may be sacrificed. Using seven-bit transfer on both KER-
MITs will cause KERMIT-65 to strip off the high order bit when sending and turn
on the high order bit when receiving. This will insure that the receiving sys-
tem gets positive ASCII text as opposed to negative ASCII which is used on the
Apple. KERMIT-65 will write negative ASCII characters to disk when receiving
in seven-bit mode.
If you wish to edit BASIC programs on the mainframe system, you should convert
them to text files on the Apple before you send them since the BASIC inter-
preters store keywords as single character tokens. Documentation on how to
convert BASIC programs to and from text files can be found in the DOS Manual
for the Apple $#. If the receiving system does not handle eight-bit ASCII or
negative ASCII characters well, KERMIT-65 should have its FILE-BYTE-SIZE set to
SEVEN-BIT. It will send positive seven-bit ASCII to the receiving KERMIT.
When KERMIT-65 is receiving from such a system, this will pick up the seven-bit
characters and write out negative ASCII on the disk file.
- 53 -
4. Installing KERMIT
A paradox is involved in the installation of KERMIT on a system that never had
it before: You need a mechanism to get the Kermit program on to your system,
and KERMIT is that mechanism -- so it seems you can't get it unless you already
have it.
Kermit is normally distributed only to central sites on magnetic tape. These
sites can simply read the Kermit programs and documents from the tape onto the
system and run them directly. The following sections are aimed at those who
want to customize and rebuild one of the Kermit programs, or who need to
"bootstrap" Kermit on to a microcomputer when no it's not available on any
directly readable medium (like a floppy disk). Bootstrapping usually means
writing a small program that does some part of what Kermit does, in order to
get Kermit itself from a system that has it onto one that does not. The fol-
lowing sections give hints for several implementations. It is assumed that you
have access to a system on which there resides a copy of the implementation of
KERMIT that interests you.
4.1. TOPS-20
Normally, TOPS-20 systems get Kermit on magnetic tape, and store all the Kermit
files in the directory PS:<KERMIT>. The source for Kermit-20 is the file
20KERMIT.MAC; it depends only upon the standard DEC assembly language program-
ming tools MONSYM, MACSYM, and CMD. The latter may be missing from some sys-
tems, so it is also provided with the KERMIT distribution as 20CMD.MAC. These
tools should reside in MAC:, SYS:, or UNV:. The CONNECT capability of
KERMIT-20 is provided by a separate program, TTLINK, which KERMIT-20 runs in a
lower fork. The source for TTLINK is also provided. If you need to modify
KERMIT-20, copy it to your directory as KERMIT.MAC, use an editor to make the
desired changes, compile, load, and save it:
Øcopy <kermit>20kermit.mac (to) kermit.mac
Øload kermit.mac
MACRO: Kermit
LINK: Loading
Øsave
KERMIT.EXE.1 Saved
Ø
TTLINK may be built similarly.
4.1.1. Site Dependencies
When building KERMIT-20, you can elect whether it starts by default as a
server or as an interactive program. In location DFSTRT, put the value SERVER
for the former, PROMP for the latter. These values are simply symbolic start-
ing addresses. This should be done with an editor, before assembling, but can
also be done to KERMIT.EXE with DDT. If KERMIT-20 is built as a server, the
only way to run it as an interactive program is with a special command line ar-
gument, PROMPT:
Økermit prompt
Kermit-20>
- 54 -
The "IBM-FLAG" is used for connecting over an assigned TTY line to a remote IBM
mainframe. Setting the IBM flag on selects half duplex terminal emulation,
mark parity, and half duplex line handshaking, using CTRL-Q as the turnaround
character. If you need to communicate to an IBM system that has different
characteristics, you must modify the definitions of IBMDPX (duplex for IBM
system), IBMPAR (parity for IBM system), DTRNRN (line turnaround character for
IBM system) in the KERMIT.MAC source and reassemble it.
Interpacket pausing may be elected by DEC-20 sites that have delicate front
ends. First experiment with the SET SEND/RECEIVE PAUSE command to find an op-
timal value, and then set the defaults by redefining the symbols DSPAUS (pause
when sending files) or DRPAUS (receiving files) to that value.
Similarly, many other defaults can be changed by redefining symbols found in
the section marked "subttl Definitions" -- maximum retries, padding, packet
size, timeout interval, packet delimiters, prefix characters, initial delay,
and so on.
4.1.2. Bootstrapping Kermit-20
Read this section if you have Kermit-20 on line and want to "download" it to
another DEC-20 that does not.
A procedure is available for propogating Kermit from one DEC-20 to another.
The two machines are connected via dialup or other means, and then a "baby
Kermit", called PIGGY, is "downloaded" to the target machine using a program
called KERBOO. The procedure is as follows: Log in on the target machine and
do
COPY TTY: PIGGY.MAC
Then escape back to the local DEC-20, run KERBOO, and send PIGGY.MAC. PIGGY is
a bare bones version of KERMIT.MAC, with no command parser and every comment
and extraneous character stripped away; when run, PIGGY executes the Kermit
RECEIVE command. KERBOO sends a character at a time, waits for it to echo, and
then sends the next character, until done . When KERBOO has finished sending
PIGGY, connect back to the remote system, assemble PIGGY (if you get errors,
then some characters may have been garbled in transmission -- fix them with an
editor), and run it. Escape back to the local system, start the real KERMIT,
and send KERMIT.EXE. You now have a real KERMIT on both ends, and you can send
whatever other files you may desire.
By the way, you could use KERBOO in this way to download any text file to any
full duplex system.
No error checking is done, although a fancier variation could compare the
sent and echoed characters and when they don't agree, send a DELETE or BACK-
SPACE character and resend the original. This sounds simple, but complications
arise.
- 55 -
4.2. VAX/VMS KERMIT
This is the first implementation of the Kermit protocol for the VAX/VMS system.
Kermit-32 implements a subset of the functionality required for a full KERMIT.
To install Kermit-32 on the VAX/VMS system, the following files should be
available:
1. KERMIT.EXE
2. KERSYS.RNH
3. KERUSR.RNH
Use the INSTALL.COM file to install Kermit-32 on the system.
There are two different versions of Kermit-32, a Bliss-32 version and a
Macro-32 version generated from Bliss-32. If changes must be made to Kermit,
it is preferable to make the changes to the Bliss-32 source file and rebuild
the program from it. If you don't have a Bliss-32 compiler, it is possible to
make changes to the Macro code and assemble it. If you received KERMIT-32 on a
tape that was not written by a VAX, then you will only receive the Bliss and
Macro source files, and you will have to either compile the Bliss or assemble
the Macro.
If you wish to build Kermit you can use the INSTALL.COM command procedure. The
following files are required to rebuild Kermit-32; the names are shown as they
would appear on the VAX. In the normal Kermit distribution, the "KER" prefix
is replaced by "VMS".
1. KERMIT.BLI (or KERMIT.MAR)
2. KERMSG.BLI (or KERMSG.MAR)
3. KERTRM.BLI (or KERTRM.MAR)
4. KERFIL.BLI (or KERFIL.MAR)
5. KERERR.MSG
6. KERERR.REQ (BLISS-32 version only)
7. KERCOM.REQ (BLISS-32 version only)
8. KERSYS.RNH
9. KERUSR.RNH
To build Kermit-32 do the following:
Å ØINSTALL
Kermit-32 Installation procedure.
#Q 1$ The command procudure will then ask you if you wish to rebuild Kermit-32
from the source files. If you do answer YES to the question, else answer NO.
The default is NO. If you answered NO or take the default the next question
that will be asked will be Q3.
Rebuild from sources? (YES or NO)
- 56 -
#Q 2$ You will now be asked if you wish to rebuild from the Macro-32 or the
Bliss-32 version of Kermit. This question has no default.
Which version? (BLISS or MACRO)
You will then be told that it may take a while to rebuild Kermit-32.
#Q 3$ The next question that will be asked is if you want to install Kermit-32
on the system, otherwise the command procedure will exit.
Install Kermit-32 on the system? (YES or NO)
You will now have on your area a KERMIT.EXE and KERMIT.HLP.
4.3. IBM VM/CMS
Kermit distribution tapes written on the IBM VM/CMS system include the ex-
ecutable Kermit module. The Kermit distribution from both DEC and IBM systems
includes the necessary source files for building KERMIT-CMS. These are
KERMIT ASM, NEXTFST ASM, and WILD ASM. To build Kermit on the VM/CMS system,
assemble each one, load them together, and then generate the Kermit module:
.a kermit
.a nextfst
.a wild
.load kermit nextfst wild
.genmod kermit
You should now have an executable KERMIT MODULE.
4.4. 8080/Z80 CP/M
Kermit-80 was written originally for the Intertec SuperBrain -- painfully -- in
lowest-common-denominator 8080 code with the standard assembler, ASM (no mac-
ros, no advanced instructions), so that it can be assembled on any CP/M-801
system
Kermit-80 should be able to run on any 8080-, 8085- or Z80-based microcomputer
under CP/M with only minor modifications (see below). Thanks to Bernie Eiben
at DEC for the VT180, Rainbow, and Generic code, and for constant support, en-
couragement, and promulgation of KERMIT. Thanks also to Jim Grossen and John
Bray of the University of Tennessee for several important bug fixes, and for
adding XON/XOFF during CONNECT to allow logging to work to some degree; to
Charles Bacon of NIH for the Osborne code, to Bruce Tanner of Cerritos college
for the TRS-80 code, to Nick Bush at Stevens for Heath/Zenith 100 and Telcon
code, to Scott Robinson at DEC for the Apple code, and to anonymous donors at
DEC for the Heath 89 code and DECmate II code.
The 8080 assembler is distributed as a standard part of CP/M-80, whereas
the fancier Z80 assembler is normally a commercial product
- 57 -
All versions of Kermit-80 are assembled from the same source, with system
dependencies taken care of by assembly-time conditionals. The most important
system dependencies are terminal emulation (when CONNECTed to the remote host)
and screen handling, which are dependent on the individual micro's escape codes
(these features are table driven and easily modified for other CP/M systems),
and the lowest level i/o routines for the serial communications port. The lat-
ter routines do not call on CP/M 2.x Basic I/O System (BIOS) because:
1. The BIOS routines are slow.
2. BIOS always sets the 8th bit to 0, preventing transfer of binary
files.
3. Using BIOS calls, there's no way to poll the serial port; you must
hang until input appears. Kermit-80's routines are able to check
the port status and go elsewhere if no input is available; this al-
lows for virtual terminal connection, keyboard interruption of stuck
transmissions, etc.
Many CP/M micros don't have hardware clocks and the 8080 interrupt facility is
so primitive and system dependent that Kermit-80 does not time out nor are most
implementations driven by data-available interrupts at the keyboard or serial
port.
The "ibm-flag" setting is site dependent. As shipped from Columbia, it turns
on half duplex line handshaking, using CTRL-Q as the turnaround character, sets
LOCAL-ECHO ON, and sets PARITY MARK.
4.4.1. Downloading Kermit-80
If you need to install Kermit on your micro, and you cannot borrow a Kermit
floppy but you do have access to a mainframe computer with a copy of the
Kermit-80 distribution, you should read this section.
There are several ways to get Kermit from a host system to your micro. The
easiest is to "download" the precompiled "hex" file into your micro's memory
and then save it on the disk. The following is a procedure which, though far
from foolproof, should allow you to get a version of Kermit to your CP/M based
micro. It depends upon the host prompt, or at least the first character of the
host prompt, being some character that cannot appear in a hex file (the valid
characters for hex files are the digits 0-9, the upper case letters A-F, the
colon ``:'', carriage return, and line feed). As soon as any other character
is encountered, the transfer will terminate. If your host does not issue a
prompt that will accommodate this scheme, you can achieve the same effect by
modifing the adding an atsign ``Ø'' to the very end of the hex file before
sending it from the host. The program below looks for an atsign (the normal
DEC-20 prompt). DECSYSTEM-10 users would look for a dot, hex 2E.
1. Look for the appropriate hex file in the host's KERMIT area. The
name will be something like CPMROBIN.HEX, CPMHEATH.HEX,
CPMOSBORN.HEX, etc. If you don't find it, but you do find a cor-
responding .ASM or .M80 file, you'll either have to build a new hex
file on the host using a cross assembler (see below for how to do
this on a DEC-10 or DEC-20), or else bring the ASM source file to
your micro and assemble it there.
- 58 -
2. Connect to your host using a terminal or a terminal emulation
facility. Ensure that your host does not have your terminal in
"page mode". E.g. on the DEC-20, give the Exec command TERMINAL NO
PAUSE END-OF-PAGE.
3. Tell the host to display the hex file at your terminal. E.g. on the
DEC-20, give the Exec command TYPE KERMIT.HEX, without a terminating
carriage return.
4. Return to your micro. Connect to a floppy disk with plenty of free
space. Make sure your IOBYTE is set so that RDR: and PUN: cor-
respond to the I/O port that is connected to the DEC-20 (this would
normally be the case unless you have done something special to
change things). Run DDT and type in the following (the comments
should not be typed in; they are there just to tell you what's
happening):
-ikermit.hex ;Setup FCB for file KERMIT.HEX.
-a100 ;Begin assembling code at 100.
0100 lxi h,ffe ;Where to put HEX file.
0103 shld 300 ;Save the address.
0106 mvi e,d ;Get a CR.
0108 mvi c,4 ;Output function.
010A call 5
010D mvi c,3 ;Input function.
010F call 5
0112 ani 7f ;Turn off the parity.
0114 cpi 40 ;Our DEC-20 prompt atsign?
0116 jz 124 ;Yes, we have whole file.
0119 lhld 300 ;Get the pointer.
011C mov m,a ;Else, store the char.
011D inx h ;Increment the pointer.
011E shld 300 ;Save the pointer.
011F jmp 10d ;Go around again.
0124 mvi a,1a ;Get a control-Z.
0126 lhld 300 ;Get the pointer.
0129 mov m,a ;Store the char.
012A shld 300 ;Save the pointer.
012D lxi h,1000 ;Pointer to file.
0130 shld 310 ;Save the pointer.
0133 mvi c,16 ;Make file.
0135 lxi d,5c
0138 call 5
013B lhld 310 ;Get the file pointer.
013E xchg ;Put it in DE.
013F mvi c,1a ;Set DMA.
0141 call 5
0144 mvi c,15 ;Write DMA to file.
0146 lxi d,5c
0149 call 5
014C lhld 310 ;Get the file pointer.
014F lxi d,80 ;Get the DMA size.
0152 dad d ;Adjust file pointer.
0153 shld 310 ;Save it.
0156 lda 301 ;Get high order byte.
0159 cmp h ;Have we passed the end?
- 59 -
015A jm 170 ;Yes.
015D jz 163 ;Maybe.
0160 jmp 13b ;No.
0163 lda 300 ;Get low order byte.
0166 cmp l ;Passed the end?
0167 jm 170 ;Yes.
016A jz 170 ;Yes.
016D jmp 13b ;Not quite.
0170 mvi c,10 ;Close file.
0172 lxi d,5c
0175 call 5
0178 ret
0179
-g100,179 ;Execute the program.
- ;Reboot
Now there should be a file KERMIT.HEX on your connected disk.
5. Load this using the CP/M command LOAD to produce KERMIT.COM. This
should be a runnable version of Kermit. Note that CP/M hex files
have checksums on each line. If there were any transmission errors
during the downloading process, the CP/M loader will notice a bad
checksum and will report an error (something like "Illegal Format").
If you get any errors during loading, either fix the hex file
locally with an editor, or repeat the previous step.
You now should have a running version of Kermit-80.
4.4.2. Building KERMIT.HEX
The source for Kermit-80 should be available on your host computer. It is
written using 8080 assembler mnemonics, so it can be assembled on most 8080s
and Z80s using the standard 8080 assembler provided with CP/M. If you have
KERMIT.ASM on your CP/M system, you can assemble it directly on the micro using
ASM, setting the desired assembly switches as explained below. If you don't
have it, you can attempt to download the source file from the host using the
procedure outlined above.
A cross assembler is provided that runs on the DEC-10 and DEC-20, called MAC80,
contributed by Bruce Tanner at Cerritos College, that may be used for cross as-
sembling KERMIT-80 as shown in this example (for TOPS-20):
1. Copy PS:<KERMIT>CPMKERMIT.ASM (the 8080 assembler source file) to
your directory, as KERMIT.ASM (TOPS-10 filename rules must be
followed).
2. Edit KERMIT.ASM to set the conditional assembly switch for your
machine. These are right near the top of the file, after the edit
history. The switch for your machine should be set to 1 and all the
others to 0. The switches currently available are:
BRAIN Intertec SuperBrain.
HEATH Heath/Zenith H89
Z100 Zenith Z100 running CP/M-85.
OSI Ohio Scientific
- 60 -
ROBIN DEC VT18X "Robin"
DMII DECmate II word processor with CP/M
VECTOR Vector Graphics
RAINBO DEC Rainbow 100
GENER Any CP/M systems that implements IOBYTE.
APPLE Apple II, with Z80 SoftCard, D.C. Hayes Micromodem
II.
TRS80 TRS-80 II, running Lifeboat CP/M 2.25 or later.
OSBRN1 Osborne 1.
TELCON Telcon Zorba.
Look in the source file; there may be new ones since this manual was
written.
3. Run MAC80:
Ømac80
*kermit=kermit.asm
*^Z
The result will be in your directory as KERMIT.HEX.
4. Use Kermit to transfer KERMIT.HEX to the micro, or download it using
the DDT program shown above.
5. On the micro, load the hex file:
A>load kermit
KERMIT.COM will appear on the floppy.
6. The new Kermit should be ready to run.
4.4.3. Generic Kermit-80
If your CP/M system implements i/o redirection via the (optional) IOBYTE
mechanism, you can probably run Generic Kermit on it, either without modifica-
tion, or by a very simple change to the program. The standard CP/M IOBYTE is
set up as follows:
I/O Byte assignments (four 2-bit fields for 4 devices at location 3)
:
bits 6+7 LIST field
0 LIST is Teletype device (TTY:)
1 LIST is CRT device (CRT:)
2 LIST is Lineprinter (LPT:)
3 LIST is user defined (UL1:)
bits 4+5 PUNCH field
0 PUNCH is Teletype device (TTY:)
1 PUNCH is high speed punch (PUN:)
2 PUNCH is user defined Æ1 (UP1:)
3 PUNCH is user defined Æ2 (UP2:)
- 61 -
bits 2+3 READER field
0 READER is Teletype device (TTY:)
1 READER is high speed reader (RDR:)
2 READER is user defined Æ1 (UR1:)
3 READER is user defined Æ2 (UR2:)
bits 0+1 CONSOLE field
0 CONSOLE is console printer (TTY:)
1 CONSOLE is CRT device (CRT:)
2 CONSOLE is in Batch-mode (BAT:); READER = Input, LIST = Output
3 CONSOLE is user defined (UC1:)
(Here, bit zero is the least significant, "rightmost", bit).
I/O redirection is accomplished by switching the IOBYTE between two values,
"batch i/o" and "normal i/o". In normal i/o mode, the keyboard is defined to
be the console. In batch i/o mode, the serial port is defined to be the con-
sole. This switching is necessary because the console is the only device that
can be tested to see if input is available, but KERMIT must shuttle back and
forth between the keyboard and the serial port looking for input. Here are the
batch and default i/o mode definitions used in "standard" Generic KERMIT-80:
batio EQU 056H ;I/O byte CON=BAT,LIST=CRT,READER=RDR
defio EQU 095H ;I/O byte CON=CRT,LIST=LPT,READER=RDR
Other systems may have other logical devices that point to the serial port, in
which case you'll need to redefine these symbols to point to those devices and
then reassemble the program (with assembly switch GENER set to TRUE, all others
FALSE).
4.5. 8086/8088
Kermit-86 is written in 8086 Macro Assembler (ASM86), and assembled locally on
the micro. Versions for the IBM PC (PC DOS) and the Heath/Zenith Z100 (MS DOS)
are prepared from common source using conditional assembly switches similar to
those in KERMIT-80. The IBM flag has site-dependent meaning. As shipped from
Columbia, it means local echo during CONNECT, mark parity, and half duplex line
handshaking using CTRL-Q as the turnaround character. If you need to install
Kermit on your PC, and you do not have a Kermit floppy but you do have access
to a mainframe computer with a copy of the IBM PC Kermit distribution, you
should read this section.
Since the PC assembler is not provided with the minimum system, IBM PC users
cannot be expected to have it. Assembler source plus the runnable version
(.EXE) of Kermit are distributed , along with some special "bootstrap" files,
described below.
The PC assembler's object (.OBJ) files are not printable, like CP/M hex
files, so the Kermit-80 bootstrapping technique would not work here.
- 62 -
4.5.1. Bootstrapping
The KERMIT.EXE file is converted by an assembler program on the PC, KFIX, which
makes all bytes in the file printable by breaking each one up into two 4-bit
"nibbles" and adding a constant. The result is a printable file called
KERMIT.FIX. It is assumed that a copy of KERMIT.FIX is available to you on a
mainframe computer. To download the file to the PC, two cooperating programs
are run: a Fortran program, KSEND, on the mainframe and a Basic program, KGET,
on the PC. These programs are very short; they are shown in their entirety
below. KSEND reads a line at a time from KERMIT.FIX, types the line, and waits
for a signal from KGET that it can send more data. KGET reads each line and
converts the text back to the format of an executable (.EXE) file. Here's the
procedure:
1. You should have a version of KGET on the PC and KSEND on the
mainframe; if you don't have them, copy them (i.e. type them in,
using an editor ) from the listings below.
2. Log in on the mainframe. This could be tricky if you have no ter-
minal emulation facility on the PC. If you have the IBM
asynchronous communication package, you can do this at low speeds
(baud rates). If your PC has no terminal emulation facility, you'll
have to use a real terminal to log in, and then switch the cable to
the PC.
3. Compile KSEND.FOR on your mainframe, if it needs compiling. Define
logical unit numbers 5 and 6 to be the controlling terminal, and
logical unit number 7 to be KERMIT.FIX. On the DEC-20, for example:
Ødefine 5: tty:
Ødefine 6: tty:
Ødefine 7: kermit.fix
On a DECsystem-10, do something like:
.assign tty: 5:
.assign tty: 6:
.assign dsk: 7:
.rename for007.dat=kermit.fix
On an IBM system under VM/CMS,
.filedef 5 term ( lrecl 64 recfm f
.filedef 6 term ( lrecl 64 recfm f
.filedef 7 disk kermit fix ( lrecl 64 recfm f perm
Start KSEND on the mainframe. It will print a message, and then sit
and wait for the PC to send back an OK; don't change any connectors
until you see the message.
You'll also have to compile and load the KSEND program on the mainframe.
- 63 -
4. Escape back to the PC, or connect the PC to the mainframe. The PC's
communication port should be connected with a cable to the modem
that's connected to the mainframe (dialup, dedicated, switched,
whatever hookup you normally have available for logging in on the
mainframe from a terminal). If you were using a different terminal
to log in to the mainframe, make sure the PC's communication port is
set at the same speed.
5. Enter BASIC and run KGET on the PC. If KGET prints messages about
i/o errors, run it again. If it still gets errors, reboot the PC
and try again. Once KGET is running, the transmission will begin.
KGET will print each 64-character line of nibbles as it arrives from
the mainframe. Each line should be the same length -- if you see a
ragged edge, you can assume there has been a transmission error, and
you should start the process again.
6. When transmission is complete, you'll see the BASIC "Ready" prompt
again. Leave BASIC by typing SYSTEM. You should now have
KERMIT.EXE on your PC. Try to run it. If you see the "Kermit-86>"
prompt, try to CONNECT to the host mainframe and transfer some
files. If Kermit doesn't run correctly, there may have been trans-
mission errors, in which case you should start the process again
from step 2 above.
4.5.2. KSEND.FOR - Mainframe Side of Bootstrap
This is the mainframe side, KSEND, in transportable Fortran (it should run on
both DEC and IBM mainframes):
C KSEND -- Download a file over the terminal line. No special checking is done,
C except to wait for response (any response at all) from other side.
C
C This Fortran program should be run on the mainframe in conjunction
C with the KGET program on the IBM PC to transfer KERMIT.FIX to the PC.
C
C Daphne Tzoar, CUCCA, Jan 83
INTEGER A(64)
WRITE(6,50)
50 FORMAT(' Ready to transfer data......')
C - Get terminal handshake
100 READ (5,10,END=35)X
10 FORMAT(A1)
C - Get line from file
35 READ (7,20,END=90)A
20 FORMAT(64A1)
C - Write to tty
WRITE (6,25)A
25 FORMAT(' ',64A1,';')
GOTO 100
90 CONTINUE
- 64 -
C - Send final handshake
WRITE (6,30)
30 FORMAT(' ',65('Ø'))
STOP
END
The final Ø's tell KGET that the transmission is done. This works because the
technique for forming KERMIT.FIX ensures that the file will contain no Ø's.
4.5.3. KGET.BAS -- PC Side of Bootstrap
This is the PC side, KGET, in PC Basic. Note that the communication port is
opened at 4800 baud (you could substitute any other speed).
1 'KGET.BAS
5 'Run this program on the PC in conjunction with a Fortran program on the
6 'mainframe to get Kermit to the PC. Daphne Tzoar, CUCCA, Jan 83
10 OPEN "com1:4800,n,8,1" AS Æ1 ' Clear the port status.
20 CLOSE Æ1
30 OPEN "com1:4800,n,8,1,cs,ds,cd" AS Æ1 ' Open it for real.
40 OPEN "KERMIT.EXE" FOR OUTPUT AS Æ2
50 OKÅ = "ok"
60 PRINTÆ1,OKÅ ' Tell host we're ready for data
70 XÅ=INPUTÅ(65,Æ1) ' Data plus semi-colon
80 VALUEÅ = LEFTÅ(XÅ,1) ' First char of input
90 VALUE = ASC(VALUEÅ)
100 IF VALUE = 64 OR VALUE = 192 GOTO 430 ' Ø means we're done
110 IF VALUE >= 160 AND VALUE <= 175 THEN GOTO 140 ' Kill all illegal chars
120 IF VALUE >= 32 AND VALUE <= 47 THEN GOTO 140
130 XÅ = MIDÅ(XÅ,2) : GOTO 80
140 IF VALUE <> 174 GOTO 210 ' Not a dot (for read) - don't worry
150 TWOÅ = MIDÅ(XÅ,2,1) ' Look at char after the dot.
160 TWO = ASC(TWOÅ)
170 IF TWO >= 160 AND TWO <= 175 THEN GOTO 210 ' It's ok.
180 IF TWO >= 32 AND TWO <= 47 THEN GOTO 210
190 XÅ = MIDÅ(XÅ,3) ' Kill the char
200 GOTO 80
210 SIZ = LEN(XÅ) ' How much input was actual data
220 READIN = 65 - SIZ
230 XTWOÅ=INPUTÅ(READIN,Æ1) ' Get rest of data
240 XÅ = XÅ + XTWOÅ : XÅ = LEFTÅ(XÅ,64)
250 PRINT XÅ ' Optional - use this line to follow the transmission
260 GOSUB 290
270 PRINTÆ2,XÅ; ' Put data to the file.
280 GOTO 60
290 ' Get two chars, subtract space (20 hex) from each, and combine
300 ' to one digit.
310 FOR A = 1 TO 32
320 YÅ = MIDÅ(XÅ,A,1)
330 ZÅ = MIDÅ(XÅ,A+1,1)
340 YNUM = ASC(YÅ) : ZNUM = ASC(ZÅ)
350 IF YNUM > 127 THEN YNUM = YNUM - 128 ' Turn off hi bit if on
- 65 -
360 IF ZNUM > 127 THEN ZNUM = ZNUM - 128
370 YNUM = YNUM -32 : ZNUM = ZNUM -32 ' Subtract the space
380 XNUM = (16 * YNUM) +ZNUM
390 NEWCHRÅ = CHRÅ(XNUM)
400 XÅ = MIDÅ(XÅ,1,A-1) + NEWCHRÅ + MIDÅ(XÅ,A+2)
410 NEXT A
420 RETURN
430 PRINT " #All done.$"
440 CLOSE Æ1,Æ2 ' Clean up.
450 END
If you already have a working Kermit on your PC and you want to get a new one,
you should use Kermit itself to transfer the KERMIT.FIX file. Once you have
the new KERMIT.FIX on your PC disk:
1. Rename KERMIT.EXE to something else, so you'll still have it in case
something goes wrong.
2. Modify KGET:
a. Remove lines 10 and 20.
b. Change line 30 to
30 OPEN "KERMIT.FIX" FOR INPUT AS Æ1
c. Remove line 60, since we're not handshaking with a remote host
any more.
d. In line 70, change "65" to "64".
e. Remove line 250, since there's no need to monitor a transmis-
sion line.
f. Change line 280 from "GOTO 60" to "GOTO 70".
Alternatively, you can use your old Kermit to bring KEXE.BAS from
the mainframe.
3. Save the modified KGET under a new name, say KEXE.BAS, and run it.
It will end with some error like "Input past end in 70", which just
means it came to the end of file (of course, you could avoid this
error by trapping it, but no harm is done in any case).
4. You should now have a new, working version of KERMIT.EXE on your PC
disk.
4.6. Apple II DOS KERMIT
KERMIT-65 is written in a special language processed only by the cross as-
sembler known as CROSS, which is found only on DECsystem-10 and DECSYSTEM-20
mainframes. HEX files for the more common configurations and modems are in-
cluded in the distribution. The following sections describe how to download a
hex file, and how to build a new version of KERMIT-65 from the CROSS source.
- 66 -
4.6.1. Bootstrapping
The procedure to bootstrap an assembled KERMIT object file to the Apple is as
follows:
1. On the Apple, type in the APPLBT.BAS program, listed below. It is
recommended that you save this program, as it may be needed to
bootstrap newer versions of KERMIT-65 or APPHXL in the future. You
can leave out the REMarks when you type it in to speed things up.
2. Call and login to the mainframe on which KERMIT-65 resides. Do the
following (the part you type is underlined; control characters are
denoted by a preceding "^", e.g. ^A is Control-A):
a. $INÆn ! Where n is between 1 and 7
b. For Communication card, do the following:
i. Dial number for computer system.
ii. Seat phone receiver in modem cradle.
iii. $^A^F ! Full duplex, 300 baud
For the D.C. Hayes Micromodem, do the following:
i. $^A^F ! Full duplex, 300 baud
ii. MICROMODEM II: BEGIN TER ^A^Q
iii. MICROMODEM II: DIALING: nnn-nnnn ! nnn-nnnn is phone
number of computer system.
3. In your directory on the mainframe, the following files should be
present:
a. APPLBT.FOR - Sends the file APPHXL.HEX to the micro, a line at
a time.
b. APPHXL.HEX - A hex loader to be sent to the micro by
APPLBT.FOR. Once this program is resident on the micro, it
will be used to load KERMIT.HEX from the mainframe.
c. KERMIT.HEX - Make sure this is the correct copy for your
micro. Normally, this would be a copy of either APPAC2.HEX
(for the Apple communications card in slot 2) or APPDC2.HEX
(for the D.C. Hayes Micromodem II in slot 2) from the KERMIT
distribution area.
If your communication card is not in slot 2, do the following:
a. Edit APPHXL.M65.
b. Change the address which is assigned to the symbol SLOT to
"ÅCn00", where n is the number (from 1 to 7) of the slot hold-
ing the communication interface.
c. Reassemble with CROSS:
- 67 -
Øcross (TOPS-20) or .r cross (TOPS-10)
*APPHXL.HEX/P/PTP=APPHXL.M65/M65
*^C
Ensure your DEC-20 terminal is not in page mode -- TERMINAL NO PAUSE
END does the trick for TOPS-20. Then compile and execute
APPLBT.FOR. This will be used along with APPLBT.BAS on the Apple to
load the APPHXL program. Once APPLBT is executing on the mainframe,
give control back to the Apple and then run APPLBT.BAS on the Apple.
For either the Communication Card or the D.C. Hayes Micromodem, the
procedure is as follows (all commands terminated by carriage
return):
a. ^A^X ! Give control to Apple's Brain
b. $LOAD APPLBT.BAS
c. $LOMEM:9500
d. $RUN
4. Relocate and save APPHXL. Type the following (each command ter-
minated by carriage return):
a. $CALL -151 ! Enter Apple's system monitor
b. *9000<2000.21FFM ! Move APPHXL from Å2000 to Å9000
c. *^C ! Reenter Apple BASIC
d. $BSAVE APPHXL,AÅ9000,LÅ1FF ! Save APPHXL to disk
5. Now start executing APPHXL:
a. $CALL -151 ! Enter monitor
b. *9000G ! Start APPHXL
c. ENTER FILENAME TO LOAD KERMIT.HEX ! Tell APPHXL what to load.
You could also supply any other filename, e.g. KER:APPAC2.HEX. The
APPHXL program simply sends this name to the mainframe in a TYPE
command, like "TYPE KERMIT.HEX". As the mainframe "types" the file,
APPHXL will print what it is receiving on the screen as well as
loading it into memory.
6. When APPHXL finishes, type the following to the Apple to save KERMIT
on disk:
$BSAVE KERMIT,AÅ800,LÅ3600
7. You may set up a turn-key system by having the hello file on the
disk load and run KERMIT. Otherwise, to load and run KERMIT, you
must type:
a. $BRUN KERMIT ! Execute KERMIT-65 on the Apple The Apple will
- 68 -
display the following:
STEVENS - APPLE $# KERMIT-65 VER. 1.0
KERMIT-65>
8. You are now ready to transfer files.
4.6.2. Building KERMIT-65
KERMIT-65 is written in the CROSS language, for the CROSS assembler, which runs
only on the DECsystem-10 and DECSYSTEM-20. This assembler is actually a ver-
sion of MACY11, a cross assembler for the PDP-11, which has been modified to
generate code for a variety of micros.
The following files should be available:
APPLBT.BAS Initial bootstrap program to load APPHXL.HEX.
APPLBT.FOR Program on mainframe to talk to APPLBT.BAS.
APPHXL.M65 Source of hex loader program that loads KERMIT-65.
APPHXL.HEX Downloadable hex-format assembled version of APPHXL.M65.
APPLEK.M65 The KERMIT-65 source program.
APPDC2.HEX Assembled version of KERMIT-65 with the defaults:
1. Apple $# computer
2. D.C. Hayes Micro-modem
3. Slot 2 as communication port
APPAC2.HEX Assembled version of KERMIT-65 with the defaults:
1. Apple $# computer
2. Apple communication card
3. Slot 2 as communication port
APPLE.RNO KERMIT-65 user and system instructions, source for the DEC
RUNOFF or DSR text formatter.
APPLE.MEM KERMIT-65 user and system instructions, suitable for reading or
printing.
CROSS.MAC CROSS Microprocessor Assembler (Source).
CROSS.EXE CROSS Microprocessor Assembler (Object).
CROSS.DOC The CROSS Manual.
CROSS.HLP A brief description of CROSS.
Two versions of KERMIT-65 are assembled for use. If the configuration of the
machine is either of these, nothing need be done. Otherwise, the file
- 69 -
APPLEK.M65 must be altered and the KERMIT-65 program must be assembled. A
listing of the parameter portion of APPLEK.M65 for the D.C. Hayes Micromodem in
slot number 2 may be found below.
The feature test FTCOM must be set to the type of computer for which KERMIT-65
is being assembled. The only machine KERMIT-65 is available for currently is
the Apple $#. This parameter must be set to FTAPPL.
The feature test FTCDEV represents the communication device being used. The
currently defined and implemented devices are:
FTASER Apple communication card
FTHAYS D.C. Hayes Micromodem II
That parameter should be set to one of the above according to which device is
being used.
There is a definition for KERSLO which must be set according to the slot in
which the board resides. This is the address of the I/O rom for the board and
is in the format "ÅCn00" where n is the slot number.
After setting any options neccessary in APPLEK.M65, do the following:
1. .R CROSS ! Run the CROSS Microprocessor Assembler
2. *KERMIT.HEX/P/PTP=APPLEK.M65/M65 ! Generate .HEX file
This command will produce an ASCII HEX file which can be downline loaded onto
the Apple using APPHXL. If a listing is desired, one can be produced by adding
",KERMIT.LST" after the "/PTP" in the command line to CROSS.
4.6.3. APPLBT.BAS - Bootstrap Program For APPHXL
10 REM - LOADER FOR HXLOAD
11 OAD = 0
100 NÅ = "0123456789ABCDEF"
110 DÅ = CHRÅ (4)
130 PRINT DÅ;"INÆ2" : REM CHANGE '2' TO SLOT OF COMM. CARD IF NECCESARY
135 PRINT CHRÅ (1); CHRÅ (6)
136 PRINT DÅ;"PRÆ2" : REM CHANGE '2' TO SLOT OF COMM. CARD IF NECCESARY
137 PRÆ2 : REM THIS LINE SHOULD BE HERE ONLY FOR THE APPLE COMM. CARD
140 C3 = 0
150 HOME
199 REM - REQUEST NEXT LINE
200 REM - PUT A DOT ON THE SCREEN FOR EACH LINE RECEIVED
201 C3 = C3 + 1: POKE 1024 + C3, ASC (".")
202 LÅ = "":Y2% = 1: PRINT
203 GET AÅ:LÅ = LÅ + AÅ:Y2% = Y2% + 1: IF Y2% < 81 THEN 203
205 C1 = 0:C2 = 0:I = 0
208 IF LEFTÅ (LÅ,1) > = "0" AND LEFTÅ (LÅ,1) < = "9" THEN 220
210 LÅ = RIGHTÅ (LÅ, LEN (LÅ) - 1): GOTO 208
220 LL = LEN (LÅ)
249 REM - FETCH THE DATA BYTE COUNT FOR THIS LINE
250 GOSUB 1000:C1 = C1 + B:CO = B
- 70 -
255 IF CO = 0 THEN 990
259 REM - CONSTRUCT THE LOAD ADDRESS FOR THIS LINE
260 GOSUB 1000:C1 = C1 + B:AD = B: GOSUB 1000:C1 = C1 + B:AD = AD * 256 + B
265 AD = AD - 28672
266 IF AD < OAD THEN 990
267 OAD = AD
270 FOR X = 0 TO CO - 1
275 REM - GO GET A BYTE AND PUT IT IN THE NEXT MEMORY LOCATION
280 GOSUB 1000:C1 = C1 + B
290 POKE AD + X,B
300 NEXT X
310 GOSUB 1000:C2 = B: GOSUB 1000:C2 = C2 * 256 + B
320 IF C1<>C2 THEN POKE 1024+C3,ASC("E")
330 GOTO 201
990 FOR X = 1 TO 1000: NEXT X
995 PRINT DÅ;"INÆ0": PRINT DÅ;"PRÆ0": HOME : END
999 REM - GET BYTE
1000 GOSUB 1501:B = N1: GOSUB 1501:B = B * 16 + N1
1010 RETURN
1500 REM - GET NIBBLE
1501 IF LEN (LÅ) = 0 THEN N1 = 0: RETURN
1510 HÅ = LEFTÅ (LÅ,1)
1511 IF LEN (LÅ) = 1 THEN LÅ = "": GOTO 1525
1515 LÅ = RIGHTÅ (LÅ, LEN (LÅ) - 1)
1520 REM - RETURN VALUE OF HEX NIBBLE
1525 FOR X1 = 1 TO 16
1530 IF HÅ = MIDÅ (NÅ,X1,1) THEN 1610
1540 NEXT X1
1550 REM - DIGIT WAS NOT FOUND, RETURN ZERO
1560 N1 = 0: RETURN
1600 REM
1610 N1 = X1 - 1: RETURN
4.6.4. APPLBT.FOR - Mainframe side of Bootstrap
Note, this uses Fortran-77 conventions in the OPEN, READ, and WRITE statement;
these can be translated to the older notation easily on systems that do not
have Fortran-77.
CHARACTER LINE*80,SENTNL*1
OPEN (UNIT=00,FILE='APPHXL.HEX',MODE='ASCII')
10 READ (UNIT=05,FMT=20) SENTNL
20 FORMAT (A1)
READ (UNIT=00,FMT=25,END=999) LINE
25 FORMAT(A80)
WRITE (UNIT=05,FMT=30) LINE
30 FORMAT(A80)
GO TO 10
999 READ (UNIT=05,FMT=20) SENTNL
STOP
END
- 71 -
4.6.5. Parameter Region of APPLEK.M65
.SBTTL Feature test definitions
; Machines
ftappl = Å01 ; Apple (under DOS 3.3)
; Communication devices
ftaser = Å01 ; Apple serial communications board
fthays = Å02 ; D.C. Hayes modem
.SBTTL Kermit feature test options
ftcom = ftappl ; Assemble for Apple $# under DOS 3.3
ftcdev = fthays ; Assemble for D.C. Hayes Micromodem
.SBTTL Additional definitions
kerslo = Åc200 ; Slot rom address (default slot is 2)
kercsr = kerslo^ ; High order byte address of comm card rom
kercsi = <kerslo^>*16-Å0c00 ; Communication card slot index
- 72 -
I. The ASCII Character Set
ASCII Code (ANSI X3.4-1968)
There are 128 characters in the ASCII (American national Standard Code for In-
formation Interchange) "alphabet". The characters are listed in order of ASCII
value; the columns are labeled as follows:
Bit Even parity bit for ASCII character.
ASCII Dec Decimal (base 10) representation.
ASCII Oct Octal (base 8) representation.
ASCII Hex Hexadecimal (base 16) representation.
EBCDIC Hex EBCDIC hexadecimal equivalent for Kermit translate tables.
Char Name or graphical representation of character.
Remark Description of character.
The first group consists of nonprintable 'control' characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 000 000 00 00 NUL ^Ø, Null, Idle
1 001 001 01 01 SOH ^A, Start of heading
1 002 002 02 02 STX ^B, Start of text
0 003 003 03 03 ETX ^C, End of text
1 004 004 04 37 EOT ^D, End of transmission
0 005 005 05 2D ENQ ^E, Enquiry
0 006 006 06 2E ACK ^F, Acknowledge
1 007 007 07 2F BEL ^G, Bell, beep, or fleep
1 008 010 08 16 BS ^H, Backspace
0 009 011 09 05 HT ^I, Horizontal tab
0 010 012 0A 25 LF ^J, Line feed
1 011 013 0B 0B VT ^K, Vertical tab
0 012 014 0C 0C FF ^L, Form feed (top of page)
1 013 015 0D 0D CR ^M, Carriage return
1 014 016 0E 0E SO ^N, Shift out
0 015 017 0F 0F SI ^O, Shift in
1 016 020 10 10 DLE ^P, Data link escape
0 017 021 11 11 DC1 ^Q, Device control 1, XON
0 018 022 12 12 DC2 ^R, Device control 2
1 019 023 13 13 DC3 ^S, Device control 3, XOFF
0 020 024 14 3C DC4 ^T, Device control 4
1 021 025 15 3D NAK ^U, Negative acknowledge
1 022 026 16 32 SYN ^V, Synchronous idle
0 023 027 17 26 ETB ^W, End of transmission block
0 024 030 18 18 CAN ^X, Cancel
1 025 031 19 19 EM ^Y, End of medium
1 026 032 1A 3F SUB ^Z, Substitute
0 027 033 1B 27 ESC ^#, Escape, prefix, altmode
1 028 034 1C 1C FS ^, File separator
0 029 035 1D 1D GS ^$, Group separator
0 030 036 1E 1E RS ^^, Record separator
1 031 037 1F 1F US ^_, Unit separator
The last four are usually associated with the control version of backslash,
right square bracket, uparrow (or circumflex), and underscore, respectively,
- 73 -
but some terminals do not transmit these control characters.
The following characters are printable:
First, some punctuation characters.
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
1 032 040 20 40 SP Space, blank
0 033 041 21 5A ! Exclamation mark
0 034 042 22 7F " Doublequote
1 035 043 23 7B Æ Number sign, pound sign
0 036 044 24 5B Å Dollar sign
1 037 045 25 6C % Percent sign
1 038 046 26 50 & Ampersand
0 039 047 27 7D ' Apostrophe, accent acute
0 040 050 28 4D ( Left parenthesis
1 041 051 29 5D ) Right parenthesis
1 042 052 2A 5C * Asterisk, star
0 043 053 2B 4E + Plus sign
1 044 054 2C 6B , Comma
0 045 055 2D 60 - Dash, hyphen, minus sign
0 046 056 2E 4B . Period, dot
1 047 057 2F 61 / Slash
Numeric characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 048 060 30 F0 0 Zero
1 049 061 31 F1 1 One
1 050 062 32 F2 2 Two
0 051 063 33 F3 3 Three
1 052 064 34 F4 4 Four
0 053 065 35 F5 5 Five
0 054 066 36 F6 6 Six
1 055 067 37 F7 7 Seven
1 056 070 38 F8 8 Eight
0 057 071 39 F9 9 Nine
More punctuation characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 058 072 3A 7A : Colon
1 059 073 3B 5E ; Semicolon
0 060 074 3C 4C < Left angle bracket
1 061 075 3D 7E = Equal sign
1 062 076 3E 6E > Right angle bracket
0 063 077 3F 6F ? Question mark
1 064 100 40 7C Ø "At" sign
- 74 -
Upper-case alphabetic characters (letters):
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 065 101 41 C1 A
0 066 102 42 C2 B
1 067 103 43 C3 C
0 068 104 44 C4 D
1 069 105 45 C5 E
1 070 106 46 C6 F
0 071 107 47 C7 G
0 072 110 48 C8 H
1 073 111 49 C9 I
1 074 112 4A D1 J
0 075 113 4B D2 K
1 076 114 4C D3 L
0 077 115 4D D4 M
0 078 116 4E D5 N
1 079 117 4F D6 O
0 080 120 50 D7 P
1 081 121 51 D8 Q
1 082 122 52 D9 R
0 083 123 53 E2 S
1 084 124 54 E3 T
0 085 125 55 E4 U
0 086 126 56 E5 V
1 087 127 57 E6 W
1 088 130 58 E7 X
0 089 131 59 E8 Y
0 090 132 5A E9 Z
More punctuation characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
1 091 133 5B AD # Left square bracket
0 092 134 5C E0 Backslash
1 093 135 5D BD $ Right square bracket
1 094 136 5E 5F ^ Circumflex, up arrow
0 095 137 5F 6D _ Underscore, left arrow
0 096 140 60 79 ` Accent grave
- 75 -
Lower-case alphabetic characters (letters):
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
1 097 141 61 81 a
1 098 142 62 82 b
0 099 143 63 83 c
1 100 144 64 84 d
0 101 145 65 85 e
0 102 146 66 86 f
1 103 147 67 87 g
1 104 150 68 88 h
0 105 151 69 89 i
0 106 152 6A 91 j
1 107 153 6B 92 k
0 108 154 6C 93 l
1 109 155 6D 94 m
1 110 156 6E 95 n
0 111 157 6F 96 o
1 112 160 70 97 p
0 113 161 71 98 q
0 114 162 72 99 r
1 115 163 73 A2 s
0 116 164 74 A3 t
1 117 165 75 A4 u
1 118 166 76 A5 v
0 119 167 77 A6 w
0 120 170 78 A7 x
1 121 171 79 A8 y
1 122 172 7A A9 z
More punctuation characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 123 173 7B C0 æ Left brace (curly bracket)
1 124 174 7C 4F ø Vertical bar
0 125 175 7D D0 å Right brace (curly bracket)
0 126 176 7E 7E Tilde
Finally, one more nonprintable character:
0 127 177 7F 07 DEL Delete, rubout
- 76 -
Index
EBCDIC 72
.COM Files 25 Eight Bit Files 25, 29
.EXE Files 25 End-Of-Line (EOL) 31, 32,
.REL Files 25 Error Recovery 19
Escape 29, 49
7-bit 29 Escape Character 11, 45, 4
Escape Sequence 10
8-bit 25, 29
8080 47, 56 File Format 24
8086/8088 48, 61 FILE-BYTE-SIZE 29
File-Warning 45, 46, 50
Aborted-File Disposition 27 FINISH 17, 18, 26, 46, 49
ADM3A 45 Flow Control 6
APPHXL 65
APPLBT 65 Generic Kermit-80 1, 45, 4
Apple II 1, 45, 51, 60, 65 GET 26
ASCII 72
AUTO Byte Size 29 Heath/Zenith H89 45, 59
Autoanswer 16 Hex File 60
Autodialer 14 Holes in Files 25
Baud 46, 49 IBM 36
Binary Files 25 IBM PC 48, 61
BIOS 47, 57 IBM-flag 30, 46, 50
Bootstrap 53, 57 Initial Filespec 20, 27
Buffer 6 IOBYTE 60
BYE 17, 18, 25, 46, 48 ISAM Files 25
Byte 20
Byte Size 24, 29 KERBOO 54
Kermit Commands 11, 24, 33
Cables 14, 16 KERMIT Protocol 6
Checksum 6 Kermit server 17
Command Parsing 23 KEXE 65
CONNECT 9, 11, 25, 45, 48 KFIX 62
Control Characters 10, 72 KGET 62
CP/M 56 KSEND 62
CPM-Created-File 47
Crash 20 Line 30
Cross Assembler 59 Line Sequence Numbers 24
Local 11, 25, 44
Deadlock 19 Local-Echo 46, 50
Debugging 28 LOG 46
DEC VT18X 59 LOGOUT 18, 46, 49
DECmate II 45 LRECL 37
DECmate-II 1, 45, 60
DECsystem-10 33, 59, 62 MAC80 1, 60
DECSYSTEM-20 24, 59
Delay 29 NAK 19, 44
Dialup 14 Noise 6
Diskette 20 Null Modem 14, 16
Downloading 54, 57, 62
Duplex 29 Ohio Scientific 45, 59
Osborne 1 1, 45, 60
EasyWriter 50
- 77 -
Packet 6, 8
Packet-Length 38
Padding 31
Page 29
Parity 21, 31, 46, 50, 72
Pause 31, 32
PIGGY 54
Prompt 9, 26
Protocol 6
Quote 31, 37
Rainbow-100 1, 45, 60
RECEIVE 11, 13, 18, 27, 31, 37, 45,
49
RECFM 37
Remote 11, 25
RETRY 31
RMS Files 25
Robin 45, 59
SEND 11, 13, 18, 20, 27, 32, 37, 45,
49
Server 17, 27, 53
SET 11, 27, 37, 46, 49
Seven Bit Files 29
SHOW 11, 33, 38
SOH 32
Start-Of-Packet 32
STATISTICS 33
SuperBrain 45, 56, 59
SYMBOL 1
Synchronization 6
Telcon Zorba 1, 45, 60
Timeout 32, 33, 36, 44, 57
TOPS-10 33
TOPS-20 24
TRS-80 II 1, 45, 60
TTLINK 25
VAX/VMS 1
Vector Graphics 45, 60
Virtual Terminal 9, 11, 45
VM/CMS 14, 36, 46
VT100 46
VT18X 45, 59
VT52 46
Wildcard 11, 13
Word Size 24
XON/XOFF 6, 46, 72
Z80 56
Zenith Z100 45, 48, 59
- i -
Table of Contents
Ordering Information 4
1. Introduction 6
2. How to Use KERMIT 8
2.1. The KERMIT Program 8
2.2. Talking to Two Computers at Once 9
2.3. Transferring a File 10
2.4. Basic KERMIT Commands 11
2.5. Real Examples 12
2.5.1. PC to Host 12
2.5.1.1. Receiving from the Host 13
2.5.1.2. Sending to the Host 13
2.5.2. Host to Host 14
2.5.3. Micro to Micro 16
2.6. Another Way -- The KERMIT Server 17
2.7. When Things Go Wrong 19
2.7.1. The Transfer is Stuck 19
2.7.2. The Micro is Hung 19
2.7.3. The Remote Host Crashed 20
2.7.4. The Disk is Full 20
2.7.5. Host Errors 20
2.7.6. File is Garbage 20
3. KERMIT Implementations 22
3.1. Command Interface 23
3.2. Notation 24
3.3. TOPS-20 KERMIT 24
3.4. TOPS-10 KERMIT 33
3.5. VAX/VMS KERMIT 35
3.6. IBM VM/CMS KERMIT 36
3.7. UNIX KERMIT 40
3.7.1. Cornell UNIX Kermit 41
3.7.2. Columbia UNIX Kermit 41
3.8. RT-11 KERMIT in Pascal 43
3.9. 8080/Z80 CP/M KERMIT 44
3.10. Generic KERMIT-80 47
3.11. 8086/8088 KERMIT 48
3.12. Apple II DOS Kermit 51
4. Installing KERMIT 53
4.1. TOPS-20 53
4.1.1. Site Dependencies 53
4.1.2. Bootstrapping Kermit-20 54
4.2. VAX/VMS KERMIT 55
4.3. IBM VM/CMS 56
- ii -
4.4. 8080/Z80 CP/M 56
4.4.1. Downloading Kermit-80 57
4.4.2. Building KERMIT.HEX 59
4.4.3. Generic Kermit-80 60
4.5. 8086/8088 61
4.5.1. Bootstrapping 62
4.5.2. KSEND.FOR - Mainframe Side of Bootstrap 63
4.5.3. KGET.BAS -- PC Side of Bootstrap 64
4.6. Apple II DOS KERMIT 65
4.6.1. Bootstrapping 66
4.6.2. Building KERMIT-65 68
4.6.3. APPLBT.BAS - Bootstrap Program For APPHXL 69
4.6.4. APPLBT.FOR - Mainframe side of Bootstrap 70
4.6.5. Parameter Region of APPLEK.M65 71
I. The ASCII Character Set 72
Index 76
«eof»