Using a CP/M machine to log into a Linux server using an RS232 connection
Because -- why not?
Also, this is a good test that the serial communications ports and cables are working properly. The objective here is to use my CP/M system, which is based on the RC2014 bus, to operate a Linux server using RS232. It's a reasonable place to start fiddling with serial communications, because we know that Linux will support terminal sessions over a serial connection -- although this can be a little fiddly to set up.
System set-up
The diagram below shows the test configuration.
The CP/M system has its serial console port connected to a terminal emulator
(which is a self-contained unit based on a Raspberry Pi 3, but that's not really important).
The second serial port is connected via a serial cable to the Linux machine which, since
modern PC-type hardware doesn't have a real serial port, uses a USB-serial adapter.
At the Linux level, this serial connection appears as /dev/ttyUSB0. Most
USB-serial adapters are supported by modern Linux distributions without additional software
or configuration.
All the 'RS232' lines in this diagram are actually using 5V TTL logic levels, not real RS232 (which typically uses 12V). In a simple test like this, there's no point adapting the logic levels to real RS232 and back again. Of course, to use a 'real' RS232 device, like a serial printer, you'd need a level converter.
The CP/M system
The system I'm using has a Z180-based main board with two serial ports. One of these is used
for the main user console, while the other is unassigned. This second serial port appears
in CP/M as UC1 ("user console 1"), among other things.
The CP/M system uses ROMWBW firmware, which supplies a CP/M utility mode for setting
the serial port properties (baud rate, etc). This utility is specific to the CP/M implementation
-- other firmwares will have their own ways of setting up ports. Within the mode
utility, the second serial port is referred to as COM1.
I'm using Kermit on CP/M to make the connection, although ROMWBW supplies a simple utility
talk.com which will actually work fine for this simple test. I've been using
Kermit because it's supposed to support software flow control (of which, more later).
CP/M Kermit exists in various versions for particular hardware. I'm using the 'generic'
version, which should work on any CP/M whose BIOS has IOBYTE support. That is,
it has the ability to redirect the standard console to auxiliary hardware. Because
Kermit can be slightly awkward to build,
here is a binary of Generic Kermit 4.11 for CP/M.
The fastest baud rate I've been able to use reliably is 19200. To set the serial port to use this baud rate, I do:
B> mode com1 19200
The Linux system
My Linux system is running Fedora which, for better or worse, uses systemd to
control log-in access to serial terminals. To start a log-in listener on the USB-serial port, I
use systemctl as follows:
# setenforce 0 # stty -F /dev/ttyUSB0 19200 # systemctl start getty@ttyUSB0
setenforce 0 turns off SELinux security enforcement, which might not be a good plan
in a production system. This is only necessary because of a bug (sigh) in the systemd
implementation in my version of Fedora -- other systems might not need this measure.
It's necessary to set the baud rate before starting the listener -- I've noticed that if I do it later, it appears to change but, in fact, does not.
For the record, what systemctl actually ends up doing is to run agetty,
like this:
agetty -o -p -- \u --noclear ttyUSB0 vt220
agetty is a modern, cut-down version of the traditional Unix getty, which
listens for serial connections, and invokes login to start a user session. The way
that systemd invokes agetty can be modified by hacking on various
systemd configuration files, but the default behaviour is fine for simple
testing.
Logging in
With agetty running on the Linux system, and both systems configured to use the
same (low-ish) baud rate, it's just a matter of running kerm411 on the CP/M
system, and typing CONNECT at the prompt. Here is a screenshot of a log-in session, just
to demonstrate that it actually works.
Problems
I expected to have problems with terminal compatibility but, in fact, I did not. I feel that it's only fair to point out that this is because I'm using a Linux-based terminal emulator with my CP/M system. By default, Linux assumes that the terminal -- whether it's a real terminal or just an on-screen console -- is broadly VT100 compatible.
The heyday of CP/M predates the VT100, really. If I weren't using a VT100-compatible terminal emulator,
but a real serial terminal of earlier vintage, things would be a little more complicated. However,
Linux has wide terminal support so, provided I use a supported terminal, probably all I need
to do in Linux is to set the TERM environment variable to match the terminal
I'm using. So, in fact, terminal compatibility isn't really a problem at all.
What definitely is a problem, however, is the lack of hardware flow control in the serial port. My Z180-based main board has full flow control in the console port, but no flow control in the second serial port. This, I'm told, is a limitation of the Z180.
I've been using Kermit for communications because it's documented as supporting software (XON/XOFF) flow control. This should be a viable alternative to hardware flow control but, in practice, it doesn't seem to work very well. If the Linux system sends a large amount of data to the CP/M system (and 'large' here depends on the baud rate), some characters get dropped. I suspect that the Linux system is so fast, compared to the CP/M system that, by the time the CP/M system sends its 'XOFF' to pause transmission, the Linux system has already sent a heap of data. Whatever the explanation, I can't get baud rates greater than 19200 to behave well. To be fair, it I were using a long serial connection between the two computers, or a telephone modem of 1980's vintage, I probably wouldn't be able to get speeds much faster than that anyway.
Closing remarks
I can't think of many good reasons to use a CP/M system as a front end to a Linux server -- especially when the CP/M system has its own Linux-based terminal. Still, it's good to know that ancient technologies can, to some extent, be used with modern ones.
