An Initial Pragmatic Bridge to the Past

Kermit history from the creators

Beginning in the fall of 2024, the project's first stage was defined by a fundamental logistical problem: how to transfer newly edited source code from a modern host computer onto the SIMH PDP-10. The initial solution was Kermit, a venerable client-server protocol that characterized the project's first development workflow. This approach required running Kermit on both ends, a modern host and the PDP-10, to establish a communications bridge for file transfers. Originally created in 1981 at Columbia University to allow users to move files between smaller computers and campus mainframes, Kermit requires the user to manually run executables on both the local host and the mainframe. In some sense Kermit is a serial terminal style ASCII connection between two user-layer executables, and piggybacks its own file transfer protocol on top of that. This can be juxtaposed with the early 70s ARPANET protocols such as TELNET and FTP which are in some sense lower-level and more deeply integrated into the operating system layer.

The concept for Decwar was to edit Fortran source files locally, then use Kermit to transfer them to the PDP-10. Another apparently simple alternative was to edit Fortran source interactively on the PDP-10 via telnet session using vintage DEC tools such as SOS and TECO. While entertaining, this very quickly proved too slow and cumbersome.

The Kermit workflow, though an indirect way to code and test, was at least somewhat automateable using Kermit's scripting capabilities. One would edit Fortran source files on their local machine, and an automated script would then use Kermit to move those files over to the PDP-10 in order to rebuild Decwar and prepare it for testing. This workflow had a dual nature. It was a learning tool that enabled the project to get started quickly, and it was indeed worthwhile to learn more about Kermit because of its familiarity and relative ease. At the same time, this method imposed significant limitations. The process was comparatively slow and more than a little bit awkward, highlighting the friction between the modern and historical systems and ultimately serving as the catalyst for a more integrated methodology.

In retrospect, this workflow, while functional for initial system exploration, presented significant efficiency bottlenecks. It likely slowed down progress compared to what would have been possible using better approaches. The reliance on manual, multi-step file transfers created an indirect and cumbersome development cycle that was ripe for optimization.