Fourth Edition


Frank da Cruz, Daphne Tzoar, Bill Catchings

Columbia University Center for Computing Activities

New York, New York 10027

19 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


tonino Mione at Stevens Institute of Technology.

- KERMIT-10 now has CONNECT command, added by Vanya Cooper at Pima


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


(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


- An adaptation of Kermit-80 was done by DEC for the Rainbow-100.


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 and for

systems running CP/M-Plus (3.0) by Bruce Tanner at Cerritos


in Norwalk, California. Another for the Osborne 1 by Charles


at the National Institutes of Health. And another for the


Zorba by Nick Bush at Stevens.

- A version for the Kaypro II was written by Chad Pearce at


Mason & Dickenson Inc, Philadelphia PA.

- 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-


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


Murton of the University of Toronto was fixed up by Michael


- 2 -

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).

- 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.


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


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.


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 host believes that the PC is an ordinary terminal. In order for 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." "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-

3 ting at a personal computer (PC ), which has a serial communication port. The

4 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.

Having "connected" to the host, there must be a way for you to get back to the



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 -

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


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


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.


control-rightbracket), followed by the letter "C" for



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.



Everthing from a "!" mark to the end of line is a comment, not system typeout or part of a command.

- 13 - 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.

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. 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


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


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 two

7 systems. For connecting to remote systems when no autodialer is available, a

8 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-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.



Kermit-20>connect ! Get back to IBM and clean up.

[TTLINK: Connecting to remote host over TTY12:, type <CTRL-Y>C to return.







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

9 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

10 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


Proceed as follows:

1. Run Kermit on the SuperBrain, and give the RECEIVE command:


CUCCA SuperBrain Kermit-80 - V3.2


2. Run Kermit on the Robin, and give the SEND command for FOO.HEX.


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


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.


(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.


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


If you want to run the server with non-default options selected (like


- 19 -

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


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


- 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


- 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 -

11 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


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

Kaypro-II CP/M 8080 ASM CU/MMD L U F I W E

"Plus" CP/M 8080 ASM CU/Cerritos 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.

- 23 -

Under "Capabilities", "T" means it can time out, "F" means it can take some 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


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


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


<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.


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 5character

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


(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


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


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,


transmits only the file name and the contents of the file.


control information is beyond the scope of the KERMIT protocol.


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


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


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


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.


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


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


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


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.


<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).


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


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


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.


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.


a description of the packet format, see the


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.


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.


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.


LOCAL -- Specify echoing during CONNECT to a remote host:


means the remote host echoes, HALF means the local


do the echoing. FULL by default. HALF generally required with

IBM hosts.


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-



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,


@vdir foo


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


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.


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-


or -20 remote host (for example, CP/M .COM files), or

8-bit files that are built on the DEC-20 (or


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


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


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


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.


lets mixed groups of files be sent correctly,

provided they are stored correctly on the


When receiving, AUTO mode is the same as


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.


the default mode.


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


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


to another system's requirements. The possibilities are


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.


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


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


what to expect.


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



The longest packet the other Kermit may send.


values are 10 to 94; default is 80.


Inter-packet padding. The DEC-20 does not need any



When receiving a file, pause the specified number of

seconds (which may have a fractional part, e.g.


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


communications front end. Default is no pause.


The character the other Kermit should use for quoting

control characters, normally ASCII 43 ("#").


- 32 -

should be no reason to change this. Permissible values

are 41 ("!") to 176 ("~"), i.e. the ASCII characters in

the printable range.


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


you may use this command to tell Kermit-20 what control

character to expect. Permissible values are 1


to 37 (CTRL-Underscore).


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.


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.


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,


12) or some other control character.


Maximum packet length to send, decimal number, between

10 and 94, 80 by default.


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.


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.


The printable character to use for quoting of control

characters. 43 ("#") by default. There should be no

reason to change this.


The control character that marks the beginning of an

outgoing packet. Normally SOH (Control-A,


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.


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.


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-


- Terminal interrupts to stop or report status of a transfer in


- Error correction technique options beyond current singlecharacter

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.


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>






LINE <o>

RECEIVE <One of the following>






SEND (same options as RECEIVE)

SHOW (same options as SET, plus SHOW ALL)


KERMIT-10 has self-contained code for the CONNECT command; there is no separate

TTLINK program.

- 35 -


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


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


HELP keyword [keyword...]


RECEIVE [file-specification]

SET parameter value


Display packet traffic and other debugging information at the

console terminal.

DELAY seconds

ESCAPE character



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.


RECEIVE parameter value


Maximum length for incoming packets, 10-96.


Number of padding characters (normally not needed).


Character to use for padding if PADDING nonzero, an oc-

tal number 0 to 37 or 177.


How many seconds to wait for an incoming message before

trying again.


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


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


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


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.


Written in IBM 370 assembly language to run under VM/CMS on IBM 370series 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


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


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


(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).


- 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.




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-


The command SEND CEN SPSS will send CEN SPSS A1. To send the

same file located on your B disk, you must specify: SEND


SPSS B. SEND * FORTRAN will send all fortran files on your


disk. SEND ABC% EXEC will send all exec files with a four let-

ter filename beginning with ABC. If you have the file PLOT


on your A disk and your B disk, SEND PLOT SAS * will send




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


= = B.

SET <parameter> <value>

Set the parameter to the specified value. Legal Set commands are:


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.


Indicates the logical record length. The default is set to 80,

and the maximum allowed is 256.


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


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.


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.


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


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


Kermit-CMS does not always know the micro has stopped sending it in-

formation. Therefore, when you connect back to the IBM, Kermit-


may still be sending packets (they will appear on the screen).


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


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


Kermit-CMS will immediately abort with an error of "Bad sendpacket

- 39 -


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-


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


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



"Illegal packet type" -- This can be caused by sending server com-


"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-


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-


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


mit, connecting to a remote host over another communication port.


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.


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.


"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-20>send *.c

(user types ^B to get back to


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


% (now, let's send to the DEC-20)

% kermit clbe /dev/tty13 4800 2

Kermit: connected.

(now we're on the -20)


^B (user types ^B again to get back)

Kermit: disconnected.


% kermit slb /dev/tty13 4800 *.pl





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,

12 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:


PAD character: null

EOL character: Carriage return

QUOTE character: #

See the GETPARAM procedure in the RT KERMIT program, or the Kermit


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


- 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)

- Kaypro II ^\ (CTRL-backslash) (VT52)

- CP/M Plus (3.0) ^\ (CTRL-backslash) (dumb terminal)

The available arguments to the escape character are:

B Send a BREAK signal. No Kermit-80 currently implements this func-


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.


<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

- 46 -

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

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


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:


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.


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.


When you CONNECT to a remote host, you must set LOCAL-


if the host is half duplex, OFF if full duplex.

OFF by


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.


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


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.

- 47 -


Allow the transfer of files to and from the IBM VM/CMS system.

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




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


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


The various versions of KERMIT-80 should be available in the KERMIT area on your host computer for downloading, under names like


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 systemdependent 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.

- 48 -

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 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


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.



Hint: the Delete key is CTRL-Backarrow on the IBM PC.

- 49 -

CONNECT Make a terminal connection to a remote system. Type an escape se-

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


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


A.TXT, but not ABCD.TXT.

SET Set the value of a parameter or flag. The SET options are as fol-


BAUD <d> Set terminal communications port speed to 300,


1800, 2400, 4800 (the default), or 9600 bits per

second (baud).

DEBUG Set debug mode ON or OFF (normally should be


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


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.


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


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


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


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


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:





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


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


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




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


- 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


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


Then escape back to the local DEC-20, run KERBOO, and send PIGGY.MAC.


a bare bones version of KERMIT.MAC, with no command parser and every comment and extraneous character stripped away; when run, PIGGY executes the


RECEIVE command. KERBOO sends a character at a time, waits for it to echo, and

14 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


SPACE character and resend the original. This sounds simple, but complications arise.

- 55 -


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


To install Kermit-32 on the VAX/VMS system, the following files should be available:




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".






6. KERERR.REQ (BLISS-32 version only)

7. KERCOM.REQ (BLISS-32 version only)



To build Kermit-32 do the following:


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.


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


15 system. It has since been modified to run on many other systems as well.

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


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


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.


name will be something like CPMROBIN.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



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


-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


-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.


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


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


2. Edit KERMIT.ASM or GENERIC.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 -


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



TRS80 TRS-80 II, running Lifeboat CP/M 2.25 or later.

OSBRN1 Osborne 1.

TELCON Telcon Zorba.

KPII Kaypro-II

CPM3 CP/M Plus (3.0)

Look in the source file; there may be new ones since this manual was


3. Run MAC80:




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 =


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-


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


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


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


"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


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.


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


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


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-


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 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 Daphne Tzoar, CUCCA, Jan 83



50 FORMAT(' Ready to transfer data......')

C - Get terminal handshake

100 READ (5,10,END=35)X


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


- 64 -

C - Send final handshake

WRITE (6,30)

30 FORMAT(' ',65('@'))



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


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).


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.


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


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


400 X$ = MID$(X$,1,A-1) + NEWCHR$ + MID$(X$,A+2)

410 NEXT A


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


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



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.


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


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


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


(for the Apple communications card in slot 2) or


(for the D.C. Hayes Micromodem II in slot 2) from the


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)



Ensure your DEC-20 terminal is not in page mode -- TERMINAL NO


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


For either the Communication Card or the D.C. Hayes Micromodem, the

procedure is as follows (all commands terminated by carriage


a. ^A^X ! Give control to Apple's Brain


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


You could also supply any other filename, e.g. KER:APPAC2.HEX.


APPHXL program simply sends this name to the mainframe in a


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


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:



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


CROSS.MAC CROSS Microprocessor Assembler (Source).

CROSS.EXE CROSS Microprocessor Assembler (Object).


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


11 OAD = 0

100 N$ = "0123456789ABCDEF"

110 D$ = CHR$ (4)


135 PRINT CHR$ (1); CHR$ (6)



140 C3 = 0

150 HOME



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$)


250 GOSUB 1000:C1 = C1 + B:CO = B

- 70 -

255 IF CO = 0 THEN 990


260 GOSUB 1000:C1 = C1 + B:AD = B: GOSUB 1000:C1 = C1 + B:AD = AD * 256

+ B


266 IF AD < OAD THEN 990

267 OAD = AD

270 FOR X = 0 TO CO - 1


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


1000 GOSUB 1501:B = N1: GOSUB 1501:B = B * 16 + N1



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)


1525 FOR X1 = 1 TO 16

1530 IF H$ = MID$ (N$,X1,1) THEN 1610

1540 NEXT X1


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.

- 71 -


C -- APPLBT.FOR -- sends Apple II hex loader to Apple, unguarded.

C -- Runs under DEC-10/20 Fortran v6 or later.






20 FORMAT (A1)


25 FORMAT(80A1)


30 FORMAT(80A1)

GO TO 10




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:


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.


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:


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:


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):


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:


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):


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:


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 -


EasyWriter 50

.COM Files 25 EBCDIC 72

.EXE Files 25 Eight Bit Files 25,


.REL Files 25 End-Of-Line (EOL)

31, 32, 37, 49

Error Recovery 19

7-bit 29 Escape 29, 49

Escape Character

11, 45, 46

8-bit 25, 29 Escape Sequence 10

8080 47, 56

8086/8088 48, 61 File Format 24


Aborted-File Disposition 27 File-Warning 45,

46, 50

ADM3A 45 FINISH 17, 18, 26,

46, 49

APPHXL 65 Flow Control 6


Apple II 1, 45, 51, 60, 65 Generic Kermit-80

1, 45, 47, 60


AUTO Byte Size 29

Autoanswer 16 Heath/Zenith H89

45, 59

Autodialer 14 Hex File 60

Holes in Files 25

Baud 46, 49

Binary Files 25 IBM 36

BIOS 47, 57 IBM PC 48, 61

Bootstrap 53, 57 IBM-flag 30, 46, 50

Buffer 6 Initial Filespec

20, 27

BYE 17, 18, 25, 46, 48 IOBYTE 60

Byte 20 ISAM Files 25

Byte Size 24, 29

Kaypro 1, 45, 60

Cables 14, 16 KERBOO 54

Checksum 6 Kermit Commands 11,

24, 33, 44

Command Parsing 23 KERMIT Protocol 6

CONNECT 9, 11, 25, 45, 48 Kermit server 17

Control Characters 10, 72 KEXE 65

CP/M 56 KFIX 62

CP/M-Plus 1, 45, 60 KGET 62

CPM-Created-File 47 KSEND 62

Crash 20

Cross Assembler 59 Line 30

Line Sequence Numbers


Deadlock 19 Local 11, 25, 44

Debugging 28 Local-Echo 46, 50

DEC VT18X 59 LOG 46

DECmate II 45 LOGOUT 18, 46, 49

DECmate-II 1, 45, 60 LRECL 37

DECsystem-10 33, 59, 62

DECSYSTEM-20 24, 59 MAC80 1, 60

Delay 29

Dialup 14 NAK 19, 44

Diskette 20 Noise 6

Downloading 54, 57, 62 Null Modem 14, 16

Duplex 29

Ohio Scientific 45,


- 77 -

Osborne 1 1, 45, 60 Z80 56

Zenith Z100 45, 48,


Packet 6, 8

Packet-Length 38

Padding 31

Page 29

Parity 21, 31, 46, 50, 72

Pause 31, 32


Prompt 9, 26

Protocol 6

Quote 31, 37

Rainbow-100 1, 45, 60

RECEIVE 11, 13, 18, 27, 31, 37, 45,



Remote 11, 25


RMS Files 25

Robin 45, 59

SEND 11, 13, 18, 20, 27, 32, 37, 45,


Server 17, 27, 53

SET 11, 27, 37, 46, 49

Seven Bit Files 29

SHOW 11, 33, 38

SOH 32

Start-Of-Packet 32


SuperBrain 45, 56, 59


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



Vector Graphics 45, 60

Virtual Terminal 9, 11, 45

VM/CMS 14, 36, 47

VT100 46

VT18X 45, 59

VT52 46

Wildcard 11, 13

Word Size 24

XON/XOFF 6, 46, 72

- i -

Table of Contents

Ordering Information


1. Introduction


2. How to Use KERMIT


2.1. The KERMIT Program


2.2. Talking to Two Computers at Once


2.3. Transferring a File


2.4. Basic KERMIT Commands


2.5. Real Examples


2.5.1. PC to Host

12 Receiving from the Host

13 Sending to the Host


2.5.2. Host to Host


2.5.3. Micro to Micro


2.6. Another Way -- The KERMIT Server


2.7. When Things Go Wrong


2.7.1. The Transfer is Stuck


2.7.2. The Micro is Hung


2.7.3. The Remote Host Crashed


2.7.4. The Disk is Full


2.7.5. Host Errors


2.7.6. File is Garbage


3. KERMIT Implementations


3.1. Command Interface


3.2. Notation












3.7.1. Cornell UNIX Kermit


3.7.2. Columbia UNIX Kermit


3.8. RT-11 KERMIT in Pascal


3.9. 8080/Z80 CP/M KERMIT


3.10. Generic KERMIT-80


3.11. 8086/8088 KERMIT


3.12. Apple II DOS Kermit


4. Installing KERMIT


4.1. TOPS-20


4.1.1. Site Dependencies


4.1.2. Bootstrapping Kermit-20






- ii -

4.4. 8080/Z80 CP/M


4.4.1. Downloading Kermit-80


4.4.2. Building KERMIT.HEX


4.4.3. Generic Kermit-80


4.5. 8086/8088


4.5.1. Bootstrapping


4.5.2. KSEND.FOR - Mainframe Side of Bootstrap


4.5.3. KGET.BAS -- PC Side of Bootstrap


4.6. Apple II DOS KERMIT


4.6.1. Bootstrapping


4.6.2. Building KERMIT-65


4.6.3. APPLBT.BAS - Bootstrap Program For APPHXL


4.6.4. APPLBT.FOR - Mainframe side of Bootstrap


4.6.5. Parameter Region of APPLEK.M65


I. The ASCII Character Set




Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF