Archive
Projects
About

See figure 1.

Retrocomputing and other indulgences.

HOSTCM

Summary: A modern implementation of the “HOSTCM” protocol for use with Commodore SuperPET computers. You can download the latest version of the package here.

The Commodore SuperPET was an odd machine. Even though it was produced as the attentions of Commodore were shifting away from the PET to the lower end of the mass market, the SuperPET represented the ultimate development of the original PET line. It consisted of two different computers – one 6502- and the other 6809-based – bundled into a single PET chassis.

Much of the hardware in the SuperPET was identical to the CBM 8032 that Commodore had shipped a year previously, but the 6809 boards were new, and were specifically designed to run firmware and language interpreters produced by the University of Waterloo.

The machine was positioned as a professional and educational tool, and the marketing materials emphasized that it could be used as a remote workstation that would easily integrate with larger computing installations. Commodore claimed that the Waterloo languages would allow users to write and debug their software locally, and that the communication capabilities of the SuperPET would allow the resulting code and data to be moved seamlessly to a mainframe for production.

This integration of communication with larger machines was one of the most interesting features of the SuperPET; users could store files on a remote machine just like they did on directly attached storage devices.1 By default, file access was local – for example, operations on a file named

disk/0.filename,prg

would cause the SuperPET to store the data locally on disk 0. However, if the device specifier in any filename was changed to “host”, e.g.

host.filename,prg

the ROMs would automatically redirect the I/O operations to a remote server.

The communication between the SuperPET and the remote host relied on a proprietary protocol called “HOSTCM”, which allowed the file operations supported by the 6809 ROMs to be relayed over a serial line to an appropriately configured server.2 Unfortunately, no HOSTCM server software came with the machine, and the details of the protocol were not provided in the standard system documentation.3

WATCOM (a commercial enterprise associated with the University of Waterloo) offered standalone HOSTCM server software for sale; versions were available for IBM’s Series/1 running RPS and IBM 370/30XX/43XX systems running VM/CMS, as well as DEC PDP-11s running RSTS/E. As is obvious from the list of targeted platforms, these official implementations were distributed to universities and other large institutions, but were not otherwise broadly sold. I am unaware of any surviving copies.

About a year after the launch of the SuperPET, WATCOM ported the Waterloo language processors and system components to the IBM PC. This included HOSTCM client support, which initially required a special “Waterloo serial board” be installed.4

Beyond the SuperPET and the later PC port, the HOSTCM protocol was also used for communication in the Waterloo microNet distributed filesystem.5 microNet implemented a HOSTCM server for RS-232-based workstation communication as part as a heterogenous LAN architecture, and and was in daily production use at Waterloo as late as 1985.

There was a semi-official port of the HOSTCM server to the IBM PC (see the letter from WATCOM in appendix B of this thesis), but it’s unclear if it was ever made commercially available. Either way, the executable is not known to have survived and the source for the port was missing in 1989.

Finally, there was at least one contempory enthusiast HOSTCM server implementation that presumably was based on information from WATCOM, but only fragments of this program have survived.

Even though all of these HOSTCM server implementations are either lost or unavailable, the client side of the protocol is preserved in the SuperPET firmware. In the early 80s, a collection of enthusiasts disassembled the 6809 SuperPET ROMs. Using this as a starting point, it’s possible to isolate the client side of the HOSTCM protocol, and in turn work out what the server-side implementation must have looked like.

This program is the result.

Benefits

Beyond the simple pleasure of rescuing this feature of the SuperPET and documenting the protocol for posterity, a working HOSTCM server has several other nice properties.

Usage

  1. Unpack and compile the HOSTCM server software. On a POSIX compliant system (e.g. Mac OS X), ‘make’ should just work. You may have to adjust the CFLAGS for your compiler and environment.

  2. Using a NULL-modem cable, connect the SuperPET to the host computer’s serial port.

  3. Use the ‘Setup’ menu item on the SuperPET in 6809 mode to set appropriate communication parameters (I use 9600 baud, EVEN parity, 1 stop bit). Leave the remainder of the settings untouched. Note that the settings are not preserved across reboots.

  4. Use the “passthrough” (‘p’ command) feature of the SuperPET’s 6809 monitor to make sure that you can send and receive characters at both ends of the serial link.

    (Many USB-to-RS232 dongle/driver combinations don’t generate the DTR signal by default, and the SuperPET serial hardware is sufficiently old-school that a lack of DTR confuses it. If you have a system which supports the TIOCSDTR ioctl for serial devices, defining UNIX_LIKE in the Makefile will solve this problem in software; otherwise you may have to tie the DTR signal by hacking at the serial cable itself.)

    (See here for detailed RS232 wiring information).

  5. There are two ways of using hostcm. Originally, users would log into the host using the “passthrough” (p) command in the monitor, and then invoke hostcm. To use it in this manner, the host must be configured to allow logins over the serial line; since the serial line is already set properly to allow communication, hostcm itself is used without any arguments.

     hostcm
    

    Once the program is running, return from the passthrough command by pressing the “run/stop” key, and continue as normal.

    To end hostcm use in this mode, return to passthrough, type ‘q’ followed by return, and hostcm will exit.

  6. Alternatively, hostcm may be run from the host directly. To do this, start the hostcm program with arguments to appropriately configure the serial line you wish to use for communication.

     hostcm [-b][-p (even|odd)][-s baudrate] tty
    
     -b 	2 stop bits (default 1)
     -p	parity (default odd)
     -s	baudrate (default 9600)
     tty	name of tty device
    

    The server will run until interrupted, and will exit with -1 as a status in the case of an unrecoverable error.

  7. If everything has worked correctly, start the SuperPET editor and try

     di host./
    

    You should get a directory listing of the root directory of the server.

    Other file operations in the editor (such as ‘get’ and ‘put’) should now work as well.

Notes and limitations:

This program is © Rob Ferguson, 2013, and made available under the BSD 2-clause license. See the LICENSE file included in the distribution for details.

  1. The details of this are described in Chapters 6 and 8 of the SuperPET System Overview manual

  2. Waterloo used the name HOSTCM interchangeably to refer to both the program running on the server and the communication protocol it implemented. For clarity, I’ll use the modifiers “client”, “server”, and “protocol” as needed. 

  3. There were documents describing the protocol available from WATCOM, but I have been unable to find a copy (see a contemporary reference here). 

  4. See F.D. Boswell . et al, “System Overview: IBM Personal Computer - DOS”, Waterloo, Ont: WATFAC, 1982, chapters 2 and 3. 

  5. D.D. Cowan, F.D. Boswell, and T. R. Grove, “A Distributed File-Server for a Personal Computer Network”, UW Computer Science Research Report CS-84-54, December 1984.

    Even though the report doesn’t mention HOSTCM explicitly, Professor Cowan and others from CSG have confirmed to me that HOSTCM was used as the transport protocol between the workstations and the Series/1 minicomputers (see Figure 1 on page 16 of the report). 

—   30 April 2013
(tags: , , , )