While in the process of restoring my Superbrain QD to operation, I stumbled upon the related fascinating history of the Kermit communications application. I decided to someday exhibit both together. The time had come.The pertinent fact was that the first microcomputer version of Kermit was written on and for the Superbrain. I had recently been seeing old copies of it show up in disk images for various vintage computers Back in the day, I was only exposed to Kermit as a file transfer protocol option in my C64 terminal emulator programs. I did not know it was much more than that, why it came to be, nor the significance the application had in the 80s and 90s. What follows the whole story- a bit about Kermit, how I progressed putting the exhibit together, and finally the exhibit itself. Videos of the demonstrations of building and running Kermit-80 are at the end.
A short summary of the long history of Kermit. See this for the whole story.
Columbia University, in the late 1970’s, had storage space limitations on their large systems making it difficult to store all of the student working files. They saw a possible solution by leveraging newly emerging microcomputers in place of the campus terminals. With the right software, the microcomputers could provide smart terminal features with upload and download capability to local mini floppy disk media, which the students could take with them and manage themselves. They chose to solve this problem with the Intertec Superbrain.
They decided to write the required software themselves so that they could have control of it. Bill Catchings and Frank da Cruz designed the original protocol. An early innovation of the protocol included a feature negotiation exchange which permitted adding protocol features yet remaining backward compatible. Frank later published the book: “Kermit: A File Transfer Protocol”.
Kermit’s first implementation was Kermit-20, written by Bill Catching in PDP-10 assembly language for the University’s DECSYSTEM-20. On April 29, 1981 the first Kermit file transfer was done on the DECSYSTEM by two sessions of Kermit-20 across two serial ports. Soon afterwards, the Kermit-80 program was written on the Intertec Superbrain in Intel 8080 Assembly Language, again by Bill Catchings. In June the Kermit-80 exchanged files with Kermit-20, making local storage of large systems files a practical reality.
Kermit-80 was next adapted by Digital Equipment Corporation for the DEC VT-180, followed by support of many other CP/M computers. When the IBM PC was released, Kermit-80 was converted to an MSDOS version. Remarkable new features later contributed in 1985. When Bill Catchings left the University, Frank da Cruz continued on, adding numerous features and optimizations. Over the next several decades organizations and individuals worldwide contributed to porting efforts that brought a version of Kermit to hundreds of computer models and their numerous operating systems, written in over 36 computer languages. Users could obtain most all but two versions of Kermit for free, simply by request. Two required licenses- E-Kermit which can be integrated into other software and firmware, and the Windows version, Kermit 95, which was also offered as a shrink-wrapped commercial product.
Kermit served as the main connectivity tool for the campus until the late 1990s. Frank da Cruz continued to lead the self-funded The Kermit Project until it was canceled in 2011. His work transitioned to kermitproject.org where it has focused on modern versions of Kermit. These versions, such as the modular and portable C-Kermit, can operate over networks and serve as a handy “super-terminal shell” tool combining terminal emulation, security, file transfer control, and an interesting scripting language.
Kermit continues to be available as Open Source under a BSD license. Columbia University still holds the copyright. A number of the contributors to Kermit over time have published related materials, some are listed here.
A fun fact in Kermit lore is that though denied initially, its name did originate with the Sesame Street character. But they did not have permission to use it a first. For a while they invented fanciful explanations of the name, until they secured permission. Some examples were
KERMIT STANDS FOR (K)L10 (E)RROR-FREE (R)ECIPROCAL (M)ICROPROCESSOR (I)NTERCHANGE OVER (T)TY LINES and ” Celtic for ‘free’ “.
It is interesting to me just how progressive this use of microcomputers was back in 1981. In the same time frame, 1979 to 1983, my college ran a DECSYSTEM-20. We operated it with punch card machines (which the first year engineering students were obligated to use), DEC Writers, and DEC VT terminals. Conspicuously absent from the data centers were microcomputers of any kind. We had no offline storage of our own except punched cards and printouts. In the dorms I did cross paths with an Apple II and later spent a long weekend with a VIC-20.
The Kermit Project appeared to me a notable forerunner of today’s open source/open development software approach, having world wide collaboration and no cost source and executable releases. Frank da Cruz informed me that in the 1970s and 1980s computing staffs commonly shared their software development with other Universities. Such he says, was the genesis of “free” and “open source”. The 1990s, things changed, and in his estimation Kermit may have been the last major university-based software development project of its kind.
A particularly interesting historical aspect to me was the Herculean effort involved in porting the software to all of the different machines and languages and supporting them over the years. Kermit may be THE most ported single application program of all time. If anyone can show me an another application that can run on a list of different computers as long as this one– written in as many different programming languages- please do.
Vintage computer hobbyists should familiarize themselves with Kermit. It is one of the tools we have that can get files on and off of network challenged computers. Thanks to the protocol’s negotiation phase feature, variants of Kermit can be mixed and matched at the ends of the cable without severe interoperability problems.
In order to combine Kermit and the Superbrain into an exhibit, I had to get up to speed on operating Kermit and its capabilities. Further, I had yet verify that the Superbrain was up to the task. I had not tested the serial ports nor ever ran Kermit on it.
I prepared floppies containing executable versions of Kermit for both the Superbrain and the Kaypro II that I located in my current stashes. I hooked up the Superbrain Aux port and the Kaypro II with an RS-232 breakout box. The breakout box’s LEDs seemed to indicate that both sides of the wire were correctly driving their respect pins (2 and 3) correctly. I launched Kermit on each machine. I set both baud rates to 1200. I issued a RECEIVE command on the Kaypro II, and a SEND command on the Superbrain with some file name that was on the A: drive. To my delight the file was transferred to the Kaypro II successfully.
I turned my sights to find out what the earliest version of Kermit available was. The folks from The Kermit Project told me that they didn’t think there was anything available earlier than the 1991 v4.11 of Kermit-80, available in their archive. Outside the archive, there was one floppy disk that they believed had the original Kermit-80 version on it that was with the Superbrain when they sent it to the Computer History Museum following their 30th Anniversary Commemoration. It was unknown whether there was source code is on that disk. Unfortunately, the Computer History Museum failed to catalog this disk. So I did not pursue it.
Out in the wild various CP/M archives capture releases of Kermit, usually with source code. In the few places I poked around, I only found a couple older versions of the 4 release, nothing particularly interesting. There are probably earlier to be found out there. Keep your eyes open for me! Bottom line, the 1991 4.11 version would have to do for the exhibit.
So I downloaded and examined the Kermit Project archive files for CP/M Kermit-80 4.11. It contained the assembler files, build documentation, and the tools required to do the build. The build has two major portions- a set of assembler files that are common to all the 8080 CP/M computers supported, and a set of source files that are independent of the particular machine. Further, the set includes prebuilt object files for the independent portion and prebuilt object files for each supported CP/M system. Normally a user would simply link a prebuilt machine specific object file of their choice with the prebuilt machine independant object file to obtain a working Kermit.com for their machine. Otherwise, they could re-assemble all the files themselves if they wanted to, especially in the case where they intended to customize the program.
I then decided I not only wanted to run the Kermit-80 4.11, I wanted to build it too- directly on the Superbrain at the exhibit- as a demonstration of a period build system on CP/M with dual floppy drives.
Preparing the Kermit-80 build demonstation
To test the feasibility of this, it was time I finally set up a CP/M emulator on the PC and load it up with the sources from the Kermit Archive. Though I have a number of CP/M computers, I never bothered with this before. After poking around, I settled on using a variant of MyZ80 called MaxZ80, which comes preconfigured with a lot of nice CP/M extensions and extras. I ran the emulator under DOSBOX.
The Kermit User’s manual includes documentation about navigating the source code and for building the software. Wow, think about that… Not a technical reference manual, a USER’S manual documents the build! Back then anyone getting this program was presumed able to build their own copy of an application. My how things have changed, unless you are on Linux…
I was able to import the Kermit-80 source files onto a virtual CP/M drive and look at the code with the CP/M TurboPascal editor with Wordstar like commands. Here are the sources, shown via dir *.asm:
The CPS*.asm files are system INdependant sources- source that is identical across all types of systems. The CPX*.asm files are system DEpendant- sources that contain code specific to particular systems.
The build was quite simple, 3 steps: Assemble the system common code, assemble the system specific code- and link the two together into a .com file. The manual gave step by step instructions on how to modify the sources to build a version a specific CP/M machine. The file CPXTYP.ASM needed to have “braina” type set to TRUE:
The sources supported being assembled by one of three different assembler and linker systems of the day. The archive included an assembler and linker, and the sources expected them by default. So guess which one I used. The included tools simply had to be turned into .com files using the normal CP/M hex to com process- the LOAD command.
Then I starting issuing the build commands. The first being the assembly of the machine INdependent portion, via “lasm cpsker”. cpsker.asm pulls in the other system INdependent .asm files.
Second, I issued the command for the machine DEpendent portion, “lasm cpxtyp”. cpxtyp.asm pulls in the rest of the system DEpendent cpx asm files.
The third and final command is the link of the machine dependent and machine independent object files creating kermit.com, namely “mload kermit=cpsker,cpxtyp”.
At this point I created a SUBMIT command file (CP/M’s version of a DOS batch file) to perform the build with a single command:
I exported kermit.com out of the emulator and put it on a Superbrain formatted floppy using 22DISK tools. It worked. Now the challenge was to make this build work on a dual floppy system.
A typical dual floppy build organization would likely have the boot disk and tools in drive A and sources on drive B. I could immediately see that the sources would not fit on a single DSDD 340K disk. The original machine that Kermit was built on, not being a QD model, probably was even more constrained by SSDD drives! I prepared to have two source disks- an independent and a dependent set of disks and even went so far as to write a short program that prompted you to change disks. This turned out to be more complicated than it was worth. So I bailed on that and decided to simply reduce the size of the sources by stripping the voluminous comments out. I wrote an AWK program to do this which truncated an apostrophe and everything following it.
The files were processed with a brute force batch file containing:
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpsker.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpspk1.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpspk2.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpscmd.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpscom.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpscpm.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpsdat.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpsdef.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpsmit.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpsrem.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpsser.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpstt.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpsutl.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpswld.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpxtyp.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpxtor.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpxcom.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpxlnk.asm
f:\UnxUtils\usr\local\wbin\gawk -f decom.awk disk1/cpxswt.asm
After this, the file set easily fit on the B drive disk now and I put them there with 22DISK.
Running the build for the first time, it chugged way very nicely on the dual floppies. However, the assembler caught an error caused by the awk program. Any quoted string (like a console message string) that had an apostrophe embedded in it would lose the apostrophe and everything after it including the ending double quote. There was one such message in the file set, and I fixed it by hand.
I then modified the submit file I used in the emulator to operate on the floppy system, with the drive letters inserted in the commands and added the tools and the submit file to the A: floppy disk with 22DISK.
The build took about ten minutes to run. Again to my delight, the resulting kermit.com file was functional. I could now expect to demonstrate the build process at the exhibit, and run the executable that resulted.
The Kermit operation demonstration
Now it was time to decide how I would demonstrate Kermit on the Superbrain. I had already successfully exchanged data with a Kaypro II running another copy of Kermit-80, but this required operating both computers. My preference was to operate the demo just from the Superbrain if possible. The Kaypro II could not operate like this.
In the original Kermit use-case you would be operating both sides of a connection from the Superbrain: dropping into the Kermit terminal emulator and manipulating Kermit running on the large system side, and dropping out of the terminal emulator and manipulating the local side of Kermit running on the Superbrain. An example of transferring a file from the Superbrain to the large system is as follows: From the Kermit terminal emulator session you would start the large system’s copy Kermit by invoking its Kermit command. You would then command the large system’s Kermit program to go into Receive mode by issuing the Kermit command “RECEIVE”. At which point you would exit out of the Kermit terminal emulator function and issue a local command to the Superbrain’s Kermit to SEND a file. The Superbrain would send the file off the floppy drive to the waiting large system Kermit. When the transfer completed, the user would invoke the Kermit terminal emulator to access the file out on the large system. This mode works on computers where the remote serial port is a console, which is not the case on the Kaypro II. So I sought a different arrangement. In retrospect, I likely could have redirected the Kaypro II’s CP/M console to the serial port and operated the transfers as in the large system use-case.
Instead I decided to use a later Kermit innovation called a Server Mode that allowed a machine running Kermit to monitor a port and respond to server mode commands from the other side. This feature was not available in Kermit-80. I found it was supported on MS-DOS Kermit, which I installed it on my trusty IBM PS2 Model 70 portable computer. This worked very well. The PC was put in server mode with the SERVER command, where it waited for communications from the Superbrain. The PC was a good substitute for the DECSYSTEM-20 that the Superbrain would have communicated with back in the day.
The day before packing this all up to go to the show I had some trouble. The A drive stopped working like the B: drive sometime back. So I had tear the machine back open again and pull the drive. This motor was ceased too. So I did another replacement. I put the drive back in, tested, and still had trouble. Jiggle cables and it worked. Then it quit. Close examination of the data cable showed a bent pin inside the drive connector. These are difficult to repair, so I replace it with a Kaypro II cable which only just barely reached the main edge connector. It seemed solid, so I buttoned it up for the trip. This would later still be trouble.
The demonstration of Kermit in action included showing how to launch Kermit, issue commands to the server and transferring a set of ASCII art files from the PC to the Superbrain’s B: drive. The last part of the demo showed the result of the file transfers by getting the Superbrain to print out the ASCII artwork.
I put together a slide show for the 32″ LCD that summarized much of the above activity and history. Finally all the pieces had come together and it was ready for exhibit.
- The restoration of the Superbrain QD
- The Kermit build
- The Kermit demonstration
Except for one piece: a Kermit the Frog. I was warned that there would be severe disappointment if the frog was not there. I scoured ebay and only found ratty old ones. Amazingly, two weeks before the show, I found a new-in-the-bag jumbo Kermit the Frog not 10 miles south of VCF East and arranged to pick it up on the way out.
Friday evening setup went surprisingly well. Even though I only had a mental concept of how this would go together, it worked pretty much how I envisioned. Even Kermit the Frog fit slid right into place. And all the computers worked too.
Saturday began well, and I did a full demo for one eager attendee. On the next demo, the Superbrain refused to boot. ARGH not again. I decided to use the Kaypro II as the demo machine but now I was frazzled and was making mistakes getting it configured to talk to the PC Server. It had different DCE/DTE configuration than the Aux port of the Superbrain. It should have been easy, but I was in the hot seat. With help from a colleague, we got it going. On the Kaypro I could demo Kermit but not the build.
During some downtime I opened up the Superbrain and played with that drive cable, but no matter what I did with it I couldn’t get it to be reliable. It would work, then if you breathed on it it wouldn’t. Not be until the next morning would I get to the real issue: The power cable 5v line that daisy chained from the B: drive to the A: drive was intermittent. I was able to do a quick but schlocky repair on that and got the Superbrain back in action for Sunday.
I was pleased with the reaction folks had to the exhibit. Many of the attendees were unaware, as I was, of the scope of The Kermit Project and how widely the application and protocol was ported. A handful of people had stories of using Kermit during their entire careers to move mission critical data around the globe. Many were simply pleased to be reminded of their old friend Kermit, watch the software build and see it the program run. And naturally a lot were interested in the Superbrain restoration details.
A fully remarkable thing about this project was there were no hitches, really, in anything that I attempted to do with the Kermit pieces that I worked with. Everything worked as it was intended, from the 100% assembly language version under CP/M, to the MS-DOS version on the PC- the build, the commands, the file transfers- all of this was pretty essentially flawless. It is a testament to the care invested in the crafting of the design, coding, storage, and documentation all along the way.
The production and display of this exhibit was very rewarding indeed. Perhaps it will get used again in the future! Next I look forward to checking out the features of Modern Kermit and talking a look at the C-Kermit sources.
Special thanks to Frank da Cruz for his help with information for the exhibit and this blog entry, and the referring page at KermitProject.org.