Logging in on my Mac using a VT420 terminal (posted 2020-01-25)
At my first job back in 1992 I had three things on my desk: a big phone, a 486SX PC running Windows 3.0 and a DEC VT320 terminal. Even back then those were pretty outdated, but we still used them for our helpdesk ticket system and our in-company email. (By the way, I recommend that everyone in tech starts as a helpdesker.) Five years later, I started a company with four others, and the first business we did was collect a bunch of VT420 terminals, which we then sold for ƒ 25,- a piece. I kept one for myself.
So the Digital VT100 terminal family holds a special place in the retro tech corner of my heart. Over the years, I tried to connect the terminal to my Mac using a USB-to-serial converter a few times, but never got anywhere. Today, I tried again, and finally got everything to work.
The Mac I used for this is a 2007 MacBook Pro running MacOS 10.11 El Capitan. Without testing, I'm fairly confident all of this also works on more recent MacOS versions. The USB-to-serial adapter is a Keyspan USA-19HS, which is quite old in its own right but still has driver support. And then one of these light blue Cisco console cables with DB9 on one end and RJ45 on the other, with an RJ45-to-DB25 converter plug that probably came with a Cisco router at some point a decade or two ago.
In the Unix world, you'd set this up in /etc/gettys or start a getty session manually, but on Macs this doesn't work. What you need to do is set this up using the launch daemons system, as described in the second half of this article: Serial console login on OSX
I changed the terminal to VT420 and the speed to 38400, the highest speed the VT420 can handle, but that leads to garbled output in some situations:
The reason for this is that the terminal can't keep up with a lot of data coming in at line rate at 38400 bps, so the input buffer overruns. This is fixed by telling the terminal to send XOFF at 128 characters (in the comm settings). You can easily see that this slows down the speed of incoming text, but now nothing gets lost.
Back in the day we often used RTS/CTS hardware flow control with our modems, because that way the communication channel would remain 8-bit clean, but I couldn't get that to work here.
The communication settings are 8 databits, no parity, 1 stopbit, no local echo and data leads only. In the General section of the terminal's settings (remember: F3), I set up VT400 mode with 7-bit controls and 8-bit characters. Not entirely sure what the former means, but everything works this way.
The terminal supports a few character sets, but obviously not UTF-8. So I set it to ISO 8859-1 (Latin 1). Telling the shell to use the same with:
export LC_AL="en.US.ISO8859-1
(Note: no - between ISO and 8859 as shown in many places!). But that didn't really do much, als text files with UTF-8 still show incorrect characters. However, you can display or convert those files with the iconv command:
iconv -f -f utf8 -t latin1 -c test.txt
However, Latin 1 supports such a small subset of UTF-8 that in languages that don't routinely use Latin1 characters, it's really not worth the trouble to worry about this and just live with the incorrect characters.
I keep switching between 80 and 132 column mode, as the former is much nicer but the latter shows a lot more data on screen. Unfortunately, the shell doesn't automatically pick up the change, so use:
stty rows 24 cols 80
Happiness. 😃
Also see vt100.net for everything you always wanted to know about the VT100 family but were afraid to ask.