I've had this terminal sitting under my desk gathering dust for... close to two decades, I think. This is an Ann Arbor Ambassador 60, manufactured in 1982 or 1983. It is a terminal. You probably think that word means "a GUI window that runs a command line shell in it". You think this thing must be a computer because it looks like what computers used to look like. But it is not a computer, it is a peripheral. This object consists of a keyboard, a serial port, and a CRT screen, and that's about it. A screen, I must emphasize, that is capable of displaying only text, and that text can be in any two colors you like, as long as those colors are green and black.
Look at the sustain on that phosphor. Just look at it! The video is a little long, but it's moody.
You plug the serial port on the back into the serial port of your mainframe, or into a modem, and boom, Thus We Go Forth Into Cyberspace.
Now, this is a pretty sweet terminal, because as you see, it's portrait mode. Mos terminals of this 1982 vintage had 80x24 screens. This bad boy does a glorious 80 columns by 60, sixty rows! You could emacs for days on this thing, it was glorious.
And all this at a screaming 19,200 baud! That's about two kilobytes per second, and that means you could redraw the entire screen in under two and a quarter seconds! Amazing! (Assuming you didn't blow the serial buffer, but more on that later.)
Actually this terminal has two serial ports. One is for the uplink, and the other is for a printer. That's right, this terminal could do a screen shot of your entire screen of 60 lines of text right to your line printer! The whole screen!
The keyboard is a bit mushy, and these days, being much more of a keyboard connoisseur, I'm not very excited about the placement of some of its keys. It plugs in with an RJ11 telephone cable, so who knows what protocol it speaks. Certainly not something even as modern as PS/2 which it predated by 5+ years.
You know how those things in /dev/ are called "TTYs"? That stands for "teletypewriter", because the earliest terminals were literally electric typewriters with modems stuck on the back, and a scroll of tractor-feed paper running through them. I learned FORTRAN on one of those.
So this box was just sitting there under my desk, not really in the way but just getting dustier and dustier by the year, and I thought, what the hell, it might as well be a computer. So I popped it open, made a cable to internally bypass the serial port on the back panel, and stuffed a Raspberry Pi 3 inside. I didn't want to mess around with figuring out how to pull 5v off of the board, not even knowing what the built-in power supply is rated for, so I just patched a 3-prong plug in right after the power switch and stuck a microUSB wall-wart inside the shell.
I had to buy a cheap dingus to translate between what Raspberry Pis call a "serial port" and what History knows as a serial port, though. Those TX/RX pins on a Pi are TTL, that is, +0.5v to +5v, whereas "real" serial is -12v to +12v (though ±5v typically works). It is also a great tragedy that you don't get DSR/DTR lines on these "modern" serial ports, which means you have to use inline XON/XOFF flow control. Like an animal.
Here's a big surprise: even with the Pi inside this metal box, sitting right next to the CRT coils, wifi still works just fine! So I didn't have to drill the case to stick an ethernet port on it. Not that this thing is exactly in pristine condition -- as you can see, I spray-painted it black at some point from its original lustrous beige -- but it's always nice to be able to do these things non-destructively. I'm surprised that wifi works because the tube in this thing throws off a likely-carcinogenic amount of EMF: there was a time in the past when I had it sitting next to a color monitor, and when this terminal was powered on it would make that monitor's colors go wonky from three feet away. Kind of impressive, really.
So now when you turn it on, it boots Linux. The next time someone asks to use my computer to check their mail or look something up, I'm just going to point them at this. (But why does Linux still take so long to boot? Why isn't this crap just instant-on at this point? We've got supercomputers in our pockets that we wave at like god damned wizards but Linux still takes like two minutes before it gives you a shell. It's madness, madness I tell you.)
I did a significant portion of my Emacs development on this terminal. When I was working from home, this is what I worked on. I think I wrote BBDB and the byte-compiler on this thing.
I don't remember how I ended up with it -- I probably liberated it from work some time in the late 80s. But it served me well.
At one point, I built a 50' serial cable so that I could drag the terminal out onto the back deck and work outside. I remember also routing audio for a headphone jack over some of the unused lines inside that cable, since I didn't have speakers outside.
An elegant cable, from a simpler age.
Here's the problem with this device, as you can see in the video: the character buffer on the serial port is not large. I'm guessing it is dozens of bytes deep. Dozens. And the CPU that moves those bytes from the serial port into display memory is... not fast. So it keeps up pretty well at 4800 baud, but at 9600, or when you light up the afterburners and go for the full 19,200, it falls behind.
The way terminals deal with this is flow control: either end can say, "Hold up, I am suffering" and data transmission stops until the other side is ready. The proper way to do this over a serial connection is with DSR/DTR lines, which are extra copper on the RS-232 cable, one for each side, that signal when we're ready to go. But as noted, the not-quite-a-serial-port that Pis have doesn't have that. Which leaves you with inline flow control, XON and XOFF, typically the ASCII bytes ^S to stop and ^Q to resume.
Nobody who uses Emacs can use XON and XOFF for flow control, because you need ^S and ^Q to work, dammit.
So your only other option is, don't send so fast, or send padding.
Back in the early Triassic, this led me to commit some indignities with my termcap entries.
Termcap is the thing that tells the computer how terminals work: it's a database that describes the command set of each terminal. Because they were all different: there were a lot of terminal manufacturers, and they all invented their own languages for speaking to them. If you want to move the cursor to a particular absolute position, you had to know that on a VT52, it was this sequence of bytes, but on a Heath19, it was this totally other sequence.
So I eventually figured out which sequences were the troublesome ones: for example, I remember that the command for "clear screen and move to the upper left corner" was a command that took the terminal a relatively long time to execute: after all, it had to zero out every one of those 4,800 bytes in the display RAM! This took it, let's say, 5× as long as simply sending a character to the screen, which means the serial buffer would accumulate a 5 byte debt and eventually fill up. So the fix was to modify the termcap entry to tell it that the clear-screen command should also send 5 NULs! The terminal ignores NULs, those don't go in the buffer, but they take up time on the serial line, allowing the dislay processor to keep up!
Over a period of months, as I was running Emacs I would note when the display would glitch out, make my best guess as to what display addressing commands Emacs might have decided to send, and I manually tweaked the number of NULs on the various termcap options until I really had the thing completely dialed in.
Updating the screen efficiently is effectively a compiler-optimization problem. You know what's on the screen right now, and what you want it to be, and you have to get from here to there using the absolute minimum number of bytes, because each of those bytes takes an amount of time that can actually be perceived by the user. Naïve programs might just do the obvious thing, and when they want to put text on line 3, they move to line 3 and draw the text. But if you were running a sophisticated lisp system that happened to have a text editor inside it, nothing so simple would stand. It would run the permutations and figure out that these two commands would both work, but this one was shorter. Or things like: if I scroll three lines, mark a rectangle, and then indent that rectangle by 5 spaces, I only have to send an additional 17 bytes to finish up, instead of 480 to do the whole thing. The text-mode display optimization module in Emacs was truly a "Here Be Dragons" situation.
Right, so since I haven't really used this terminal since the Clinton administration, here I am using it with a "modern" Unix system, so I'm back to the stock termcap entry instead of my customized one (oh, sorry, it's not termcap any more, now it's terminfo, which is exactly the same but totally different for no reason, you kids why I oughta) and with the stock entry, the screen glitches in a most undignified manner. Time to dig down into the archives, and...
Oh, HELLO THERE OLD FRIEND!
Except... it turns out that file is actually too old. It's got entries for Concept-LNZ, an entry to fix some bugs in the idiosyncratic Heath19 emulation that Perqs used, and a hacked version of the VT100 termcap that worked with the TI Explorer terminal emulator (which had the bug that absolute cursor addressing used variable-width numbers instead of fixed-width. That looked like "cm=5\E[%i%2;%dH", in case you were wondering. Greets to Crash Override and also Joey.)
But my carefully-crafted aaa-60 termcap entry, that piece of perfection that looked almost exactly like line noise, is now lost to us forever.
Alas.
Sometimes people ask me why my web sites use those colors. This is a thing that people sometimes ask.
Update: Part two, where I tried and failed to get RTS/CTS working.
Previously, previously, previously, previously, previously, previously, previously.
