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.¹ 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.² Unfortunately, no HOSTCM server software came with the machine, and the details of the protocol were not provided in the standard system documentation.³

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

Beyond the SuperPET and the later PC port, the HOSTCM protocol was also used for communication in the Waterloo microNet distributed filesystem.⁵ 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.

• Since Commodore diskette formats are not PC compatible, it can be hard to bootstrap a bare or nearly bare Commodore computer without the appropriate media.

  In the past, enthusiasts have usually resorted to buying or building custom hardware to communicate with either the IEEE488 interface or one of the other non-standard PET edge connectors. In contrast, HOSTCM provides a mechanism for reading and writing files from a modern machine to a SuperPET that involves hardware no more complicated than a serial cable and a null modem.

• For related reasons, it can occasionally be difficult to move software and data on Commodore compatible diskettes to newer machines. HOSTCM makes this trivial.

• Since HOSTCM relies entirely on firmware support on the client side, a SuperPET can be used (in 6809 mode) with no attached “physical” drives. It’s not fast, but it works.

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:

• For a general review of how HOSTCM was originally used, have a look at the SuperPET Gazette, volume 1, issue 8, pages 102-103.

• You can copy files in the editor using the “copy” command – and this will allow the upload and download of program files using HOSTCM, eg.

    copy (v)host.BASIC,PRG to disk/0.BASIC,PRG
  

  Note the ‘(v)’ preceding the ‘host’ device specification. This tells the SuperPET that the file is a non-text, variable record length file, and the protocol encodes the transfer so as to preserve the binary data. For more details about file specifications and naming, have a look at Chapter 5 of the System Overview.

• You can load a program from the host directly at the SuperPET 6809-mode menu screen:

    host.<path_to_program>
  

  will do it. This is particularly useful if you don’t have a disk drive.

• Waterloo MicroPIP is the best way I’ve found to do file transfers and other disk operations in SuperPET 6809 mode. That said, it’s not great – it’s minimally documented and has a number of annoying limitations. In particular, it does not support wild card filename matching for files on the host, which makes bulk operations much more tedious than they should be.

  You can find some notes on MicroPIP’s operation in the SuperPET Gazette, volume 1, issue 9, page 129.

  MicroPIP can be found as part of the disk image here.

  I’ve extracted MicroPIP as a standalone file for easy use with HOSTCM, and that can be found here.

• I’ve written some simple utilities to allow you to examine and unpack archived Commodore disk images in a matter that will allow them to work with HOSTCM.

• The HOSTCM protocol presumes a 7 bit data path; thus, all binary transfers are encoded in ASCII. The scheme that HOSTCM uses is particularly inefficient, and inflates the data by a factor of 2. Moving large binary files and loading remote programs will not be fast. Be patient.

• The ROM rename command doesn’t allow renames across devices, and so the second argument to the command does not recognize a device identifier prefix – it is presumed to be the same as the first. You’ll see this behaviour in any SuperPET program which uses the rename ROM routine, e.g. MicroEditor, MicroPIP.

• Like the SuperPET ROMs/file system, HOSTCM supports fixed record length files. This part of the protocol contains a number of subtle gotchas – see the file digression.txt included in the source distribution for more details. Caveat emptor.

• This is a reverse engineering effort. While I’ve tried to test the major functions, there may be corner cases that are broken. Compiling with -DDEBUG will allow you to trace the details of the communications between the two machines. Please let me know about any problems or difficulties you might have, and include a DEBUG trace with your report.

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.