export TERM=aaa-60

You guys, I got my Ono-Sendai working again!

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


-rw-r--r--  1 jwz  staff  3704 Nov  4  1991 Documents/spicevax/.termcap

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.


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.

Tags: , , , , , , ,

150 Responses:

  1. Steve Holmes says:

    I love that screeen and that keyboard looks pretty cool, except it seems to be designed for people who don't make mistakes, that DEL/BS is weird, I guess everyone just ^h'ed. What was the purpose of Line Feed , was there a teletype option?

    I think I've spent a good portion of the last 30 years debugging Rs232 connections, it doesn't end.

    • jwz says:

      It actually has a local-editing mode where you can just fill up the display RAM with random characters locally, and then you can select rectangles of them to squirt out the serial port as needed. I can't really imagine what kind of application would have called for that, but it's in there. I never figured out how to make the ZOOM key do anything...

      • jrs says:

        Isn't that the mode 3270(ibm mainframe) terminals work in.

        I remember a job I had a few years ago, "computer operator"(yes that's still a thing) where we ran jobs in batch mode on a ibm 360. And I had a hell of a hard time building a matrix program(very important) for the 3270 emulator we used.

        The 3270 gets text and fields and you enter data in the fields(done on the terminal) then the whole thing gets submitted at once.

        While I did get my matrix program built I never did figure out how to get non blocking key input before I left. so no tetris.

      • softweyr says:

        The screen regions could be used to program "forms" into the terminal. Ugh, the 70s were awful.

        I have no idea what happened to my tvi925+, my adm3a clone, or my H-9. Yes, an actual kit-built H-9, attached to a kit-built H-8. And to think, the computer I really really wanted in those days was an H-11.

        • The screen regions could be used to program "forms" into the terminal. Ugh, the 70s were awful.

          Of course, this is exactly like the web ecosystem. I've often reflected that the web was (in spirit) the 1990s answer to the 3270 series terminal.

        • Andrew Klossner says:

          I had an H-19 attached to an H-11, back when I worked at Heathkit writing floppy disc device drivers. It ran a gimped version of DEC's RT-11 with foreground mode disabled so we weren't competing with DEC's customers. Our development "mainframe" was a PDP-11/45 running Unix v6, under which we ran an RT-11 emulator that we hacked together so we could run the DEC assembler and linker. And a Zork binary that we got from DECUS.

  2. Jim says:

    But does it send a serial BREAK on power up? If you aren't professional enough to have backup power for your console your kernel should halt just as Bill Joy intended.

  3. hurtstotouchfire says:

    This was a lovely read and I'm terribly envious of your adorable terminal.

    • hurtstotouchfire says:

      I'm completely smitten. I can't stop thinking about this terminal. Can I run emacs 24 on a raspberry pi? I feel like this is going to make the new macbook reveal really underwhelming for me. They think the world wants more colors.

      • Yes, Emacs 24 (or 25) works fine on the rPi. In fact, running the pi is boringly like running any x86 Linux. But boring is good when you want stuff done.

  4. I strongly suspect you can hack the GPIO pins on the 'Pi to let you do hardware flow control. Just route DSR/DTR to the GPIO. It's not like you're using the GPIO for other stuff. Since you've put the thing inside the case, it should even be fairly easy to route it. It would require some tty driver hackery but it shouldn't be too bad.

    • Oooh, wait, I think I know even better. Hook it up to a serial to USB dongle! Some of those do hardware flow control and there are Linux drivers already! Less work! But then you have the problem that you're not truly hooked up to the console for boot.

      • Kevin Lyda says:

        Not sure how much more can fit in there, but yeah, the usb<->serial dongles are a thing. I have just such a box that also provides a parallel port (shudder) that I used for an old printer for a long time.

    • Not Frank says:

      Indeed, apparently some of the HW flow control signals are on available GPIOs, and someone wrote a program to set them up: https://github.com/mholling/rpirtscts

      • Jay Carlson says:

        Dammit, this is what I get for not refreshing the page before posting. Let me add more to the discussion than that.

        The old way to add level translation was to use 1488/1489 level translator chips. They needed ±12V to operate, so not very convenient even in TTL days. (I had a 1489 in my Amiga 1000 get fried by a lightning strike to a phone line--I found a friendly EE to replace it, and he even put in a socket should I be so unlucky to have this happen again, but lucky enough that only the one chip fried.)

        The great improvement on the 1488/1489 was the MAX232, which had charge pumps built in; you'd supply a couple of external caps and +5V, and it would handle generation of ±7.5V and do translation for two lines in, two lines out--typically used for TXD, RXD, RTS, CTS.

        But you're using one of those silly Raspberry Pis, and it probably doesn't have 5V-tolerant logic. Rejoice, for there is the http://max3232.qggl.it which runs off either 3.3V or 5V. It's the chip in the dongle jwz found. Easier to just buy that. But really, for such a do-it-yourself project, nothing beats the fun of wiring up solder-cup DB9s to some dangling chip. If you don't do SMT soldering, there are a number of MAX3232 breakout boards available.

  5. Nico says:

    Wow, your businesses must really not do well at the moment...

  6. BHN says:

    Just the sort of post I needed to cheer me up on a crappy day. Thank you Jamie.

  7. jservice says:

    Interesting read jwz. It amazed me how well Emacs worked on those low baud-rate terminals of long ago. It has also been a long time since I've seen a discussion of hardware DSR/DTR vs software XON/XOFF for serial handshaking. This reminds me of the days when many test instruments came with serial ports and you had to spend many hours figuring out how to to talk to them, control the instrument and download the test measurements without losing data because of flow control problems.

    • Just the other day, Emacs randomly decided to put my terminal into slow mode. Ever heard of that? It makes incremental search... interesting. (setq baud-rate 2400) fixed that.

  8. Mmmm, teh phosphors. Similar to the bloom on tube cameras I was telling you about. They don't handle YouTube compression well either. Watch for them just above Brian Ferry's shoulder pads where overexposed white/pink contrast is.


    It's great artifact of that era's video cameras which probably isn't simulated often due to most compression algorithms poor handling of gradients. It's really meant for PAL display.

  9. Phil says:

    This is just glorious, but it deserves RTS/CTS. Pop for a cheap USB to serial dingus.

  10. Owen says:

    This is my favorite thing that you've posted in ages, thanks for writing it! I remember years ago when you posted about finding that crazy 50' serial+analog audio cable. The idea of someone working on their back deck programming on a terminal while listening to cassettes over the same wire... I could imagine that person thinking, "I am living in the FUTURE right now!"

    It's funny, just yesterday it occurred to me to wonder how modems were connected to the Internet at dialup ISP POPs. I asked a friend who had firsthand experience of these things, and he said, "Serial concentrators," and sent me some pictures from a Netcom POP he had decommissioned. Oh so much analog.

    • jwz says:

      You know, I never really learned how serial concentrators worked and now I'm curious.

      At CMU, the dialup number just dropped you straight into telnet, and you'd connect to whatever host you had an account on. I'm not sure it was even a restricted version of telnet, it might have been just straight-up telnet. Trusting times.

      • Serial switches and concentrators of various sorts were once big businesses. At Columbia there was a campus-wide system made by Gandalf that ran pretty much everywhere. Every terminal in the terminal rooms had its RS-232 attached to a so-called PACX box which let you select on a little two digit dial which of the computers (mostly mainframes) you wanted to attach to. There was a big crossbar somewhere that made it all work.

        Later the CS department had lots of "Bridge Boxes", which were serial-to-telnet gadgets that all the terminals were hard-wired to, which let them forgo needing to run actual serial cables around at all in order to allow any terminal to connect to any of their Vaxes or the DEC-20. You could even have multiple sessions going to different computers or the same computer at once! (I remember there being a bridge logo on those things that reminds me vaguely of the Cisco logo but I don't think they were made by Cisco, though Cisco already existed.)

        Those were weird times. I think there is still a Sun-1 from back then (serial #42 I believe!) sitting in my mom's garage.

        • Oh, and as you would expect, the terminal concentrators you used (which may very well have been Bridge Boxes as well) were basically just a dedicated OS with a TCP stack, a huge number of serial ports, and an ethernet port. Every user connecting on a serial port got a CLI that let them run Telnet and maybe do a couple of other simple things like changing their port speed and parity. (They typically did have utterly unrestricted telnet. Why wouldn't they have at the time? :) )

          A good box like that would have two other features: a magic sequence would get the user back to the CLI from the telnet session and select between telnet sessions, so you could often run multiple telnet sessions and switch between them quickly, and there was also so-called "milking machine mode" in which you would reverse things the configuration entirely and attach all the serial ports to a mainframe that had loads of serial ports but no TCP stack, and people would telnet in to the terminal concentrator and get attached to a free serial port. "Milking machine" came from the fact that all the short serial cables from the box made it look vaguely like all the hoses going from a milking machine to a cow.

          • Jay Carlson says:

            Doug Barnes was using a BSDi box with 8-port serial cards at io.com (Steve Jackson's ISP) before we expanded to a Zyplex terminal server. On the Zyplex, one side had Ethernet; the other side had Centronics-style 50-pin connectors with many serial ports. These connectors had pinouts suitable for widely-available telco octopus cables to RJ45s (maybe RJ12s?); you would then use RJ45-to-DB25 shell connectors to feed into modems.

            This was the era before the PRI DSP modems. I'm sure people with money had rackmounted modem banks. Instead, Doug had cleverly velcro'd USR Courier modems to pegboard, and so we had a Wall Of Modems. This was surprisingly useful, as you could sit in the server room and glance at the Wall and see how busy we were from the blinkenlights. This was also a good clue about when some modem or port had died, and hence time to "busy out" a dialup line so the hunt group would skip over it when people dialed in.

            We did have one consultant who said it was Very Bad Practice that we let people telnet out from the terminal servers, instead of making them connect to our Unix shells, and telnet out from there. I didn't see the difference; I made people log into the terminal server before giving them a terminal server shell, and hence I had my accounting records for which user was on which terminal port, and could easily track down any user who was being Evil. Not much of that. We were one of the first places in town to offer SLIP and PPP, and users on SLIP and PPP could do exactly the same thing as telnet from the terminal server...

            • Back in '95 at my first tiny, regional ISP job, we bought really cheap GenTek 56K modems wholesale, took them out of the case, and mounted them vertically in a wood box with slots. We had an EE create a power supply with 16 cables to power them, and ran them into a Portmaster 2E. We used a box fan to cool them down. This was a legitimate business that made money!

              From there I went on to a national ISP who had the cash to splurge on US Robotics Total Control rackmount boxes.

              You'd run a PRI into it. Fancy.

              To impress people, they built a glass wall into the machine room adjacent to the main office hallwa and put ten full racks of these things facing outwards. Anyone walking into the office had to stroll past it, which as you can image was very cool to look at during peak hours - it represented every single dial up customer in Toronto. One of my jobs was to manage these racks and there was a control program that allowed you to update firmware or reset individual modems.

              The phone support staff sat next to the sys admin staff and after all the management went home, would chant for me to "clear the board." This involved sending an "all reset" command to all attached arrays. When sent, you'd see the command propagate through all 100+ racks from the top left to the bottom right, hanging up on customers, leaving each blade completely dark for about a minute, until people started redialing back in.

              So, if your dialup internet connection ever mysteriously hung up for no reason, half the time it was probably some punk kid like me amusing his co-workers.

              • bas says:

                The (US) national ISP I worked made modem racks out of Lego (after ripping the modems out of the cases, of course).

                Non-conductive, modular, and dense.

        • Josh Dersch says:

          Regarding the Sun-1 -- if it is still in your mom's garage, there are a few people I know trying to track down the EPROMS for the 68000 board so they can get theirs going. (If you can believe it, these things are getting hard to find!) If you can help here, let me know...

      • Benjy says:

        I used to work for a company which made Telco systems. We used Livingston Portmasters. One Ethernet port, 25 (or was it 30?) serial ports. For system management purposes, you could telnet into it and then use its own command line to talk to any of the connected serial devices, or you could also map incoming TCP ports to specific serial ports (eg 6001 -> serial 1, 6002 -> serial 2 etc). No doubt you could get simple driver software for a machine which mapped all the portmaster-connected serial ports to virtual serial ports on the machine over TCP...

        • softweyr says:

          Portsmashers were quite the thing among smaller fly-by-the-seat-of-the-pants ISPs. There are still tons of them out there, search eBay and be aghast. We had a bunch of them in various test labs, used "backwards" as a way to access the serial consoles on network equipment via ethernet. Yup, you could setup a port on a portsmasher so you could telnet TO it and be connected to the serial port too.

          You could also do this know with a RPi, a usb hub, and a box of usb to serial adapters, and a handful of Python or Perl code.

          • Miguelito says:

            We had tons of xylinx terminal servers for the same thing. They were our serial console ports to our sun servers back in the day.

            The first thing I did that put me on the map as a sysadmin with my peers was tracking down an older rev of the os on them that still buffered the console and setup a way to downgrade any new ones. I actually emailed back and forth with the main dev who admitted they'd dropped the buffering because the code was horrible and spread all over and they were being pushed to rewrite a more modular system. Since the primary selling point was for modem concentrators, they didn't feel the buffering for consoles was worth the effort.

      • Keith says:

        The last wave of ISP modems (the v.90/K56flex/x.2 era stuff) were boxes that had one or more PRIs on one side and Ethernet on the other side. I used the Livingston Portmaster 3 units and the 3COM Total Controls. Each of these had slot-in DSP cards full of modem chipsets, plus enough redundant hardware to basically only need attention when a fault light came on. These were replacements for older serial concentrators which gave you a dozen or two serial ports on one side and Ethernet on the other. Those predated my time as by the time I joined the ISP game dial-up was on the decline, being replaced by SDSL, ADSL, and fiber.

        • -dsr- says:

          Livingston was purchased by Lucent; Lucent also bought Livingston's competitor Ascend, and then decided that Ascend's product line was superior. It kinda was, in the sense that the culmination of dialup ISP hardware was the MAX, a box which took in ethernet on one side and a DS3/T3 on the other and did everything necessary to pretend to answer the phones, connect a fraction of a DSP emulating a modem, negotiate some authentication info and assign an IP for a PPP session. All in one box! If you added a mail server, a web server and an administration machine, you were an ISP in a closet.

          Lucent cleverly sold these to every ISP they could see, kicking off the price war at $20/month all-you-can-eat dialup. Great, and wonderful, but most of the ISPs didn't have cash for fancy new equipment, so Lucent decided to finance the purchases themselves, using the MAX boxes as collateral.

          Each ISP that folded sadly turned in the MAX hardware, which had zero resale value because Lucent had already sold them to every other ISP...

          Lucent folded, too.

      • Owen says:

        My friend said that the concentrators would have Ethernet on the back and plug into a router, so I would guess they had some kind of ASIC for routing those packets. Now that I remember, some other folks I used to hang out with had some old Telenet packet switching gear, and IIRC they told me that when you connected you would effectively be dropped to a telnet prompt (or similar client) right on the box. Then you could open connections elsewhere from there.

    • Owen says:

      This also reminds me of The Cuckoo's Egg, when Cliff Stoll realizes that he introduce line noise into the hacker's connection by jingling his keys over the right serial port in their switching room. He does this to keep the guy on the line longer while PacBell tries to trace his call.

  11. Chad D Altenburg says:

    Wow. You got way too much free time on your hands.

  12. nightbird says:

    That was impressive. Especially the Digital Rain.

    There's got to be something you can do. If not USB, can you buffer or boost the voltage from the UART on the Pi?

    BTW, are you running an Arm version of FreeBSD? I can't imagine you staying with Raspian or whatever Linux ships with the Pi.

  13. Jim Sweeney says:

    Excellent tale of home archeology.

  14. Man, this brings back memories. I remember constantly tweaking the termcap padding too. I never got it quite satisfactory and just went back to 9600bps instead.

    I kept using my aaa for long after I had a bitmap display, because the terminal display was better for emacs. In fact I still have the terminal but I don't power it on anymore. I no longer have spare parts to keep it alive if anything blows.

    Nice hack with the raspi, BTW. That's tempting.

  15. Jolyon Ansuz says:

    You magnificent bastard. That is glorious. 'grats, especially the original CRT. May you never have to mod it to a flat screen.

  16. MattyJ says:

    I was telling my wife the other day to never, ever take cell phone videos in portrait mode because there is never an appropriate time to do that.

    I stand corrected.

  17. Miguelito says:

    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.

    One of the coolest problems I solved at work a few years ago:
    A coworker had been visiting an engineer in one of our buildings to help figure out why his CRT monitor had this weird warble/wave disruption periodically. We ride up to the 3rd floor (of a 4 floor building) and basically loop around backwards to a small office. The guy has his Ultra-60 setup on the back wall with the monitor against the back wall. We chat with the guy waiting to see this issue crop up.. and sure enough, we eventually see this warble happen from bottom to top. A minute or two later, it happens again but from top to bottom. After a few more seconds something dons on me: We're against the back of one of the the elevator shafts! I don't know if it was the cable bundle or the counter-weight, but when the elevator in that shaft passed by, it would warble up or down.

    Thankfully we were just getting in those new-fangled (and damn expensive) LCD monitors, so we set him up with a test unit. Problem solved.

    • jwz says:

      Best "elevator problem" ever!

    • There was a similar wiggle on all CRTs in the Bevatron building at LBL, as the machine cycled on and off every six seconds. You got used to it.

    • Benjy says:

      Client of my former employer (IT services firm) was an actuarial company... whose offices were directly above a private healthcare centre... who had an MRI scanner. shudder

      • bill says:

        My first wall st job in the early 90s was at Broadway and Fulton - right over the subway. The displays did very strange things when express trains blasted through. I'm sure it didn't do anything bad to the meat creatures looking at the displays.

      • Miguelito says:

        I was sitting at my awesome (at the time) 286 many (many) moons ago when a transformer blew just a couple houses down. Didn't take out our power, but holy hell it warbled the monitor something fierce.

        • Benjy says:

          I was a geek at high school (some would say I still am) and was involved on the tech side of school plays. One dress rehearsal the bulb in our light blew. But it took out the circuit breaker. Into which the control computer for the lighting system was plugged. Plunged the whole hall into darkness!

        • This reminds me of a time when the neutral burned in two on an outside power line. For several days, every CRT monitor I owned suffered from insanely wiggly and wobbly images. They never seemed to mind the wildly seesawing line voltage, though. (Interestingly enough, various TV sets didn't even seem to notice.)

  18. Yuma Tripp says:

    I don't know what you just said, kid, but I like your enthusiasm!

  19. mdhughes says:

    Used to have a Perkin-Elmer Data Systems terminal, used as my debug console, and later left behind with a 1200 bps modem for my parental unit to log into my BBS to send me email. I didn't answer phones even then.

    The white-on-black of the PEDS was a little easier to read, but it was slower even on direct connection.

    • I still have nightmares about the Perkin-Elmer Fox terminal. It was a cheap piece of [unprintable]. We had a large number of them at Columbia and they were sort of the terminal of last resort. Every other kind would be in use before those things got touched. The top of the hierarchy were the HDS Concept terminals, although those overheated pretty easily and I knew people who ran them without the top shell on to keep them from frying. VT100s were sort of mid-desirable, because everyone loved the keyboard and the overall feel but they couldn't handle more than 4800bps without lossage.

  20. BBd says:

    The bootup time issue may be addressable by instructing whatever Raspian uses for a bootloader to pass "quiet" on the kernel commandline. I suspect a nontrivial amount of that delay is just Linux yelling at the poor display processor when booting.

    • jwz says:

      Nah, it's slow as shit even on an HDMI console. Seriously, in the 21st Goddamned Century there's no excuse for booting a computer to take any longer than a fraction of a second longer than the DHCP and NTP handshakes take.

      • I'm running Raspbian on my custom pinball machine and it boots in about 10 seconds. I wonder what's different in yours.

      • Eric says:

        If the kernel is configured for serial console, it's sending its boot messages to that serial port (at that baud rate) whether you're connected to it or not. Connecting to another console (e.g. HDMI) doesn't disable this, as far as I know.

        I have handled this in the past by changing loglevel (using the kernel parameter "loglevel=N" where N is (I think) a lower number to filter out the boot-time log spew.

        Or just turn off the kernel serial console altogether; it shouldn't affect your ability to put a getty on the serial port.

      • rollcat says:

        Try http://sta.li/ - works on the Pi, boots in seconds.

  21. PS/2 keyboards use the same protocol as the AT keyboards before them. Passive adapters for either conversion were once quite common.

    Was that terminal offered with other monochromatic phosphors such as amber or white?

    (I've always greatly preferred the green when I had a choice, though white was tolerable. I'm actually looking for an old Samsung "CGA" monitor with long persistence green phosphors. Or maybe it was an MDA/Hercules monitor and my graphics card at the time was merely willing to emulate CGA. I really don't remember now.)

    • ssl-3 says:

      A CGA (remember, Color Graphics Adapter) monitor with long-persistence green phosphors? Nope.

      I had a (color) Samsung CGA monitor in 1987 or '88. It was quite fast for all three colors.

      I only point this out because there were such things as monochromatic CGA, EGA, and VGA displays: These generally just displayed the green channel, IIRC, and were usually white.

      Also, as you suggest, there were monochrome video cards which would emulate CGA. This always seemed like a worst-of-the-worst hack, but they did exist.

      I think the historic object you're looking for is probably an MDA or perhaps "Hercules" monitor, in green form.

      But even then: If you want a lazy-green terminal, I'm sure there are emulators out there that you can download right now to get the same effect. It will probably also be adjustable to match your memories, given a sufficiently-high-density display.

      • Well, there was a reason I put "CGA" in quotes. On the software level at least, the system (a Kaypro PC clone) was compatible with any program I ever ran that required a CGA display. The graphics card was from ATI. Beyond that I don't remember. This was more than 25 years ago.

        I'm not really looking for an emulator. I've managed to acquire two examples of the actual computer I had. Now I'd like to find the monitor, which now that I've done some research, appears to have been a Samsung MA2565.

  22. ssl-3 says:

    I am inspired to spin the Wax Trax! Black Box boxed set and fire up an old VT330, except that wasn't really very archaic.

    Mostly, I wish I still the old Wyse terminal I once had with a keyboard so shitty, the keys had open-cell foam under them, with a bit of metal foil stuck under that. Depressing a key would squish foam and force the foil onto the circuit board traces below, completing the circuit. A tiny, hair-thin metal coil spring provided the (slow) return stroke.

    It didn't have the lazy, slow phosphors of your terminal, but that's OK: It was easily hacked into a crazily-bright, green strobe light, given rapid "invert display" commands and with the brightness cranked.

    It also spent a year or more showing cmatrix until...I have no idea what happened to it after that.

    (At one point it also had a quite long hand-spun serial cable, so that IRC could happen in more than one room at one time. That cable saw plenty of use for serial terminals, before being relegated to SLIP duty between PCs, and then rewired for PLIP because it was faster than SLIP and Ethernet cards and cabling were still not yet included in Crackerjack boxes.)

  23. phuzz says:

    Is that a NewTek pen (or something) on the desk in your fist picture? The people who made the Video Toaster?

    • jwz says:

      Yes, that is my treasured Video Toaster Flat-Head Screwdriver.

      • Carlos says:

        Would you or your clubs have any use for a Toaster? I traded in my original Toaster when I upgraded to the 4000, but I have an Amiga 4000 with Toaster 4000 in it that Ran When Parked and is unlikely to ever see use again here...


        • If our host is not interested, and the offer extends to anyone else, I might be very interested in your old Video Toaster.

          • Carlos says:

            I offered it to jwz because over the years, I have derived a lot of good use from his software, and even more enjoyment from reading his various writings (blog, rants, etc). As I've never done anything to support his efforts, this seemed to be one way I could contribute.

            If I'm going to get rid of the equipment and jwz doesn't want it, then not to put to fine a point on it, I'll sell it, not give it to a stranger that I've no previous connection with.


        • jwz says:

          Thank you for the offer, but I don't think I'd give a Video Toaster the love it deserves.

  24. Cody says:

    This was so awesome. More, please!

  25. jer says:

    What music is it that happens to be running in the background?

  26. yacu says:

    what's the name of the song in the video?

  27. Jon Lennox says:

    On the time boot is taking — what SD card are you using in the Pi? A lot of SD cards are optimized for “write the next JPEG to FAT32,” and are crap slow at any other I/O pattern.

    • jwz says:

      I'm using this, which came with Jessie pre-installed (4.4.22-v7+ #912) and then I did: apt-get --purge remove x11-\*

      Possibly there is more crap I could uninstall. I didn't look that closely.

      DHCP on wlan0 seems to always take about 20 seconds to come up, on top of everything else. And sometimes the connection just randomly goes away (and this was before it was inside a metal box). I had this problem with the payphone too, before I switched it to ethernet. I get the impression that Pi built-in wifi is not terribly stable.

      • Jon Lennox says:

        I think it's not so much the crap on the card, so much as the quality of the card hardware itself. The fact that the Adafruit card says it's only Class 4 makes me a bit dubious, though the SD card classes aren't really that relevant for Linux-style filesystem access.

        This page seems to give a reasonable summary of the current state of the art. Might be worth seeing how your SD card stacks up on those benchmarks.

  28. thx1138 says:

    Is the hampster dance book just pages and pages of frames of the hampster dance animation?

  29. sjthespian says:

    Oh that brings back so many memories... VT100, VT420, the termcap I wrote so I could use Emacs on an ADM-3A and on System V 386.

    The terminal itself reminds me of the AT&T 3B2. They had a similar portrait display and were fantastic for spending long hours writing code in Emacs and reading USENET via. Gnus...

    • Josh Dersch says:

      Ah yes, the AT&T 5620, or "BLIT" terminal. That thing was insane -- it was a bitmapped display terminal that ran an early windowing system called Layers on top of a 32-bit WE32000 processor. Nice slow phosphors on that one, too. (Mostly to reduce headaches, since the display was interlaced.) It had up to a meg of memory onboard and one could compile programs for it and run them locally, which made for some interesting games and demos...

  30. Extra points for retrofitting a piece of cyber history

  31. I have an exceedingly rare copy of the hardware manual for this terminal, including schematics. I really should scan it in before it gets lost or I'm run over by a data bus, and submit it to vt100.net.

  32. Leonardo Herrera says:

    You scored serious karma with this post, jwz. It's beautiful.

  33. Mike Spooner says:

    Utterly fantastic article, superbly written! After what has been a horrid year so far, this makes everything all right again - Thank you! Fond memories of RS232 voodoo... PS: I think you'll find that the ADM glass-teletype physical keyboard wiring/protocol predates PS/2 by 15 years, not just 5+.

  34. Steve says:

    This post reminds me of why I've been an EMACS hater for 30+ years... Someone told me about this new editor, probably '81 or '82. So I fire it up. The first thing I notice is that when I inserted characters in a line, it would redraw to the end of line, for every character typed! (This was on a TVI 910, which had advanced insert-character escape-sequence, unlike those shitty ADM-3As). We were using 2400 baud modems (twice as fast as what we had in high school, after they got rid of the teletypes), so this was pretty painful. Then when I went to save the file, the screen freezes up; oh right, ^S is XOFF... "What moron uses ^S as the save command???"

    So I happily went back to vi. I guess at some point, whoever wrote EMACS for UNIX figured out how to use TERMCAP, but the damage had been done...

    • That's not how Emacs usually painted screens on serial terminals. In fact, GNU emacs had (has?) code taken from Gosmacs that optimally (I mean mathematically optimally) repainted the display using a hairy dynamic programming algorithm that optimized the number of corrections needed to transform one string into another. Even "real" original TECO based Emacs was damn good at this. Note though that in '81 or '82 there wasn't "real" Emacs for Unix at all, only Gosmacs, which (as I note) was damn good at this task. The only reason for behavior like that would have been that the Termcap entry was damaged or incomplete somehow.

      • Steve says:

        I can assure you that my termcap worked just fine with vi and other programs, such as rogue (which I played far too much).

        • I'm sure, but that doesn't mean that it wasn't incomplete or broken for emacs. The code to do everything you describe was there. In 1981 you couldn't just google for a workaround.

          • Steve says:

            Lets think about this logically:

            The termcap entry for "insert character" for a given terminal type is only several characters of gibberish (which, thankfully, I cannot remember). Either it works, or it doesn't.

            At that time I observed that, vi (and other curses based programs) used insert character correctly, EMACS did not

            QED: my termcap file was corrupt??? No...

            But I will point out further that using EMACS on a dumber terminal such as ADM-3A (which lacked escape sequences for character and line inserts) would have had the same problem, because, ahem, EMACS was less optimal than vi at inserts due to the much maligned editor modes of vi.

            It doesn't matter how much arcane calculations gosmacs had, if you update the screen after every character insert, and the terminal lacks the necessary insert command, you will be in for pain. I can only imagine the pain on a 300 baud modem (which we sometimes used from home in 1985).

        • bas says:

          This sounds an awful lot like the class of .xmodmap misconfigurations mentioned here.

      • In the 81-82 timeframe there were at least two Emacsen for Unix. I believe the more popular one was Gosling's. But there was another one that was originally made by Warren Montgomery at BTL. Steve Zimmerman took it and developed into CCA Emacs. This was the competition GNU Emacs faced in its early days.

        I think they were considered real Emacs at the time. Gosling Emacs was programmable in MockLisp, and CCA Emacs in Elisp.

  35. Spook, The Unimaginative Fake Name says:

    but Linux still takes like two minutes before it gives you a shell

    Yeah, and we like it that way. Otherwise, we sink into the wretchedness that is systemd -- which, as we all know, is an ill advised and disfigured attempt at recreating launchd.

  36. Kat Fud says:

    But will it ever display dickbutt? Can you truly bring it into the modern era?

  37. Waider says:

    A mighty cool hack. Brings back some memories, although my experiences postdate yours somewhat. I do recall being very pleased with myself when, coding in x86 assembly on a 286, I managed to crank the serial port up to that mystical 19,200 baud for a goofy replicate-text-screen-to-serial-terminal TSR I wrote (for no reason other than that I had a terminal, and a serial cable, and no actual use for either)

  38. Peter Norvig says:

    When I had my 24-line heathkit H19, I wanted the 60-line ambassador SO MUCH, but it was too expensive.

  39. foo says:

    Back in the early Triassic, this led me to commit some indignities with my termcap entries.

    As if decency could be applicable to termcap in any way.

  40. Tim says:

    Lovely job and writeup.

    Re: booting: presumably part of the reason for slow boot on RPi is that it's cold booting, whereas when you unlock a tablet/phone it's already booted. Tablets take longer to cold boot, e.g. after running out of battery.

    Instant-on is great, though; I still keep old calculators around just for the immediacy.

    • Nate says:

      On real operating systems, they remember previous hardware config and don't reprobe from scratch each time. Also they do the same thing for Wifi settings.

    • Jason says:

      I've used buildroot to assemble an RPi 2 boot image. The kernel is compiled with all the drivers I need, and nothing I don't. The root filesystem contains just the tools I need. No X, no extraneous services, sysvinit instead of systemd or upstart. Power-on to login prompt in seven seconds.

      I know it's work, but if you need fast boot, it's the way to go. (When I need X, I'll generate a hard config file rather than let it probe each time.)

      • jwz says:

        Sounds promising, but I am having a hell of a time figuring out how to get buildroot working on MacOS 10.12. Apparently Apple's "clang can totally just impersonate gcc" theory is false, and even after doing "port select --set gcc mp-gcc7", MacPorts seems to be using the wrong compiler. I can't even find a straight answer on whether I should be installing "arm-elf-gcc" or "arm-none-eabi-gcc", but neither of them will build.

        Fun fact: buildroot requires GNU sed. Because we're still innovating in sed syntax here in the 21st century, FFS.

  41. Zygo says:

    whereas "real" serial is -12v to +12v (though ±5v typically works

    USB serial converters get these details right more often than not. I've used them on modern PCs because it turns out that quite a lot of scientific equipment with RS-232 ports just snorts derisively at the last decade of whitebox PC hardware and says, "Son, come back when you can pull at least -9v."

  42. Walter Heukels says:

    Ahhh now you made me want to dig out my Stratus-branded terminal (a rebadged Televideo, I think?). It's surprisingly sophisticated, with local editing, multiple screens, smooth scrolling and much else. It's the pinnacle of a dying breed, like a particularly fancy VCR.

  43. Mark says:

    This must be the longest comment thread I've ever seen here that wasn't primarily people telling jwz that he's doing it wrong.

  44. RMS says:

    Nobody who uses Emacs can use XON and XOFF for flow control, because you need ^S and ^Q to work, dammit.

    Found your problem -- have you considered using vi instead?

  45. David Konerding says:

    spicevax. That must have been a VAX used for running spice at CMU or Berkeley, during the vax era. Makes me think of https://en.wikipedia.org/wiki/Kremvax

  46. Leigh L. Klotz Jr. says:

    I was so happy when we get two of these at Terrapin -- that was right around the time you were at Lucid, maybe a year or so before.

  47. Clem Cole says:

    Many thanks. Lovely bit of memories. I still have a hard copy of the AAA manual (in the plastic sleave even), but sadly no longer have the terminal. Most people don't know that the AAA was the first terminal specifically designed with UNIX in mind by a manufacturer. I was working at Tektronix (a then large terminal manufacturer) in the late 1970's/early 80s when it came out. A couple of us took some serious management rath when we insisted on getting them. We eventually defended the position as a way for Tek to learn what was so unique about them.

    BTW: the original had a parallel keyboard on a flat ribbon cable. The newer unit you have, they switched to a serial cable to make it more flexible because one of the original complaints we had was the ribbon cable limited they way we could move the kybd around.

  48. witheld says:

    Dude. My UBUNTU install boots in like 30 seconds off a hard drive INCLUDING FIRMWARE. If your Linux takes two minutes to boot you are doing it wrong.

  49. I was going to do the exact same thing, marrying an rPi to the VT320 I got for my kid. I have it set up to boot straight into Forth.

    I love using the terminal, but I dearly miss the Meta key. How do you deal with that?

    Speaking of here be dragons, the forerunner of Emacs' newdisp.c was Gosling's display.c with its infamous scull-and-crossbones comment at the top. After a long time of obscurity, James has agreed to publish tarballs of his editor. There's even a 2007 update.

    • jwz says:

      Oh, man! I totally remember the skull and crossbones - in fact, I wanted to post that, but I forgot that it was gosmacs. I don't have a copy of 18.57 or gosmacs and there was no skull in lemacs 19.0 so I was questioning my memory!

      The aaa60 uses the bottom far left key as meta, so that's not a problem.

      I understand the new MacBooks don't have an ESC key, so ha ha screw vi.

  50. Evan Jones says:

    This post was a work of art, bravo and thank you.

  51. eric says:

    Brilliant post! Brings back all kinds of memories (using terminals, front end processors on mainframes, emacs in the early days, termcap entry editing, ...). Thanks!

  52. nbby says:

    Fuck terminals. Fuck James and Richard's shitty fucking 'dynamic' display code. May their mutually devouring software licenses unlink /dev/null forever. Fuck termios and the god-awful plusering posix kernel drivers. Fuck meta-meta-snarkburgle UART overflowing pinky spasms. Fuck my auto padding termcap generator using deadlock autokill inducing arcane answerback timing bullshit. Fuck serial pin 7 and vt100 / adm3a dirt coated dip switches. Fuck ncurses ripoffline-ing, magic cookie eating, 'programmable' function keys. Let radiation retroactively erase every last damn termcap and terminfo entry. Fuck that spackle crusted no-n-key-rollover-having bloated un-normalized unicode region snarfling USB dongle. Fuck the ten thousand layers of cruft that, to this millisecond, every bit has to struggle through.

    But ...
    before the beige plague, those cases, solid metal, smoothly rounded, and clicky-keys. We shall likely never again see such robust artistry.

  53. CT says:

    Isn't this terminal on your desk in PBS' Code Rush documentary? What type of computer was it connected to then?

  • Previously