Open a modern terminal and there is still a type name hiding under the glass. It may say xterm-256color, screen, or tmux, but the family tree still points back to names like vt100, vt220, and vt320. Those names are not decoration. They are compatibility promises: which escape sequences move the cursor, what function keys send, how attributes like inverse video behave, and how much of a character-cell screen a program can safely assume.

That is why a terminal emulator is not just a black rectangle with a font. It is a machine pretending to be another machine. The "vt" part survived because DEC's video terminals became a vocabulary for software.

Digital VT200 family from the 1983 Terminals & Printers Handbook

Digital's 1983 Terminals & Printers Handbook presents the VT220, VT240, and VT241 as the new VT200 family.

How VT became a type

DEC did not invent the idea of a video terminal with the VT220. The line starts earlier, when a terminal was still understood as a replacement for paper. VT100.net's DEC terminal history describes the VT05 in 1970 as a "glass Teletype"; the VT52 followed in 1975 with a useful but DEC-specific escape-code language. That mattered because, before standard terminal control became normal, cursor movement, clearing the screen, keypad reporting, and text attributes were all vendor dialects.

The important date is late 1977, when ANSI published X3.64 for additional controls for character-imaging devices. The VT100 arrived in 1978 and turned that standards work into a practical compatibility target. The useful correction is that DEC did not make ANSI by itself. ANSI defined the control-function language; the VT100 made an affordable, popular DEC implementation that software authors, Unix termcap entries, and later terminal emulators could not ignore.

That is why TERM=vt100 became a cultural shortcut. It rarely means "a literal VT100 is attached". It means "speak a conservative DEC/ANSI character terminal language". Modern xterm and xterm-256color added layers on top, but the old promise is still visible underneath.

Where the VT220 sits

By the time the VT220 arrived in 1983, the question was no longer whether a screen could replace paper. The problem was making a smaller, more international, more programmable terminal that still spoke to the VT100 software estate.

The VT220 inherited the VT100/VT102 text world, but it belonged to the VT200 generation. There is no generic "VT200" terminal in the way people casually say "a VT100". The family split its roles: the VT220 was the self-contained monochrome text terminal, while the VT240 and VT241 carried ReGIS and Tektronix-style graphics. That split is important. The VT220 is not a graphics workstation hiding in a wedge case. It is the DEC text terminal becoming mature, compact, multilingual, and desk-friendly.

The rough family memory looks like this: VT100/VT102 made DEC/ANSI text compatibility famous; VT220 carried that world into the VT200 generation; VT320/VT330/VT340 lowered cost and extended the late-1980s line; VT420 and the later VT500-family terminals kept the personality alive into the 1990s. Terminal emulators kept the names because old software still needed a name for the contract.

DEC VT220 brochure page from Bitsavers

DEC's VT220 brochure sells the machine as a high-productivity office terminal: human engineering, VT100 compatibility, function keys, multilingual support, and a compact detached keyboard.

The Computer History Museum even has a gold-painted artifact labeled as the "One Millionth VT220 Terminal". That is a good way to read its status. The VT220 is not beloved because it was a rare laboratory curiosity. Its collector and retro-computing appeal comes from the opposite quality: it was a real working terminal, common enough to define muscle memory, distinctive enough to recognize instantly, and still practical enough to drive from a Unix serial login today.

Look at the object

The VT220 looks simple because it is honest: a CRT, a keyboard, a serial port, and firmware that knows how to turn bytes into a screen. That simplicity is also why it is still interesting. It sits at the point where the video terminal had become mature, standardized, internationalized, and almost invisible - just before personal computers and terminal emulators began to absorb its job.

This article has two halves. The first half is historical: where the VT220 came from, what DEC changed from the VT100 generation, and why the case, keyboard, character sets, and ports matter. The second half is practical: the exact wiring and protocol notes from bringing my unit back as a Linux serial console.

Rotate the 3D model before reading the wiring notes. The wedge body, separate LK201 keyboard, rear connector bay, and CRT depth explain why the VT220 is both a designed object and a protocol endpoint.

From standard to setup screen

The VT220 manual calls the machine a general-purpose video display terminal using ANSI standard functions. Its operating modes show DEC's transitional strategy:

  • VT200 mode, 7-bit controls: the default, full VT220 behavior in an 8-bit communication environment while still encoding controls as 7-bit escape sequences.
  • VT200 mode, 8-bit controls: the same family of ANSI functions, but with 8-bit C1 controls when the link and host software can handle them.
  • VT100 mode: a compatibility mode for old software written for the VT100/VT102 world.
  • VT52 mode: a backward door into DEC's pre-ANSI private control style.

That is why "terminal emulation" is never only about drawing letters. It is a parser, a compatibility layer, a keyboard protocol, a character-set story, and a set of negotiated compatibility promises made to old software so it keeps working.

What the VT220 added

The headline specs are modest by modern standards and very revealing by terminal standards. DEC's Programmer Reference Manual lists a monochrome display with 24 rows and 80 or 132 columns, with character cells sized for those two modes. It also lists reverse video, underline, bold, blink, double-height/double-width lines, user-definable function keys, and a down-line-loadable character set. Those are not decorative extras. They are how form-based software built interfaces before pixels, CSS, and GUI toolkits were assumed.

The internationalization work is just as important. The VT220 supports the DEC Multinational Character Set and national replacement character sets. In practical terms, the terminal had to serve more than one language market without abandoning older 7-bit links and older applications. That made character encoding a live operational concern. On a real terminal, "text" is never abstract. It is a code table, a selected graphic set, a shift state, and sometimes a host that still believes the world is seven bits wide.

The communications side is equally direct. The Programmer Reference Manual lists asynchronous communication up to 19.2 Kbit/s, an EIA RS-232C host port, a 20 mA host port, an EIA RS-232C printer port, and both 7-bit and 8-bit character formats. The Technical Manual's table of contents exposes the underlying machinery: CPU logic around an 8051, system communication logic around a 2681 DUART, EIA host interface logic, 20 mA interface logic, printer interface logic, video logic, and a whole chapter for the LK201 keyboard.

That is the useful mental model for the rest of this post: a VT220 is not a computer you "log into". It is the user-facing end of an asynchronous byte stream. The host owns the process. The terminal owns the screen, keyboard, local setup state, and the exact meaning of control bytes.

Reading the object

vt220

The VT220-A2 unit I used for these serial console notes.

The physical machine tells the same story as the manuals. The case is a shallow wedge wrapped tightly around the CRT instead of a large expansion box. The screen is low, the keyboard is separate, and the rear panel is where the modern work begins. The VT220 was meant to live on a desk as an appliance: not glamorous, not general purpose, but always ready to turn a host session into a working surface.

The keyboard is part of the history too. The LK201 made the terminal feel closer to modern input hardware than the earlier VT100 keyboard does: an editing cluster, a numeric keypad, a function row, and a cursor-key arrangement that still feels familiar. For this article, the keyboard matters less as nostalgia than as evidence. The VT220 was not only a screen bolted to a serial port. It was a complete human interface designed around repeated text work.

setup menu

The setup screen is the terminal's BIOS-like self. Baud rate, character format, local echo, flow control, operating mode, display preferences, and printer behavior are not configured by editing a dotfile on the host. They live in the terminal. When a modern USB-to-RS-232 adapter seems "wrong", this screen is usually where the real negotiation starts.

Variants and phosphors

models

  • Mine: VT220-A2 — white phosphor.
  • VT220 shipped with multiple screen/phosphor variants and a large ecosystem of options (keyboards, host modules, serial/printer cabling).

The suffix matters because these machines were sold as configurable office equipment, not a single hobbyist SKU. Phosphor color changes the personality of the terminal more than a screenshot can show. Green, amber, and white phosphors all present the same byte stream, but they do not feel like the same object in use. My A2 unit is a white-phosphor machine, which makes it read less like the stereotypical green-screen artifact and more like a precise monochrome instrument.

Inside the wedge

inside-1

inside-2

ports

The inside view is a useful antidote to treating the VT220 as a prop. The terminal has high-voltage CRT reality, a real power supply, a logic board, keyboard communication, video timing, and serial interfaces. The rear ports are the practical boundary between historical object and usable tool. On one side is DEC's 1980s terminal design. On the other side is a modern host, a USB serial adapter, systemd, and a process waiting on /dev/ttyUSB0.

The bridge between those worlds is not magic. It is voltage levels, pin direction, flow-control expectations, character framing, and terminal control sequences. That is where the restoration stops being museum handling and becomes debugging.

Setup

  • VT220: DB25
  • Host: Linux + USB-to-RS-232 (ttyUSB0)
  • Default framing I used: 9600 8N1
  • Unit: VT220-A2 (white phosphor)

Signal reality

RS-232 idle sits at negative voltage. If I see 0–3.3V idle, I’m not on RS-232.

Scope
MODE
|
TEST
FRAME
|
BYTE
0xA5
TX
RX
STDATA

Cable topology

Two DTEs → cross TX/RX (null-modem) and share ground.

  • DB25 2 → DB9 2
  • DB25 3 → DB9 3
  • DB25 7 ↔ DB9 5

Framing

Framing
byte
0xA5
8N1
0101001011
7E1
0101001011
7O1
0101001001

Bring-up

I start by proving the adapter and cable with minicom, then switch to getty.

  • device: /dev/ttyUSB0
  • framing: 9600 8N1
  • flow control: off (until I see real overruns)

Getty

I ended up with serial-getty@ttyUSB0 and forced 9600 + TERM=vt220.

Control sequences

These are the ones I actually use when driving the VT220 as a display. ESC means \x1b.

Reset / clear (my default)

  • reset attrs: ESC[0m
  • normal video: ESC[?5l
  • cursor off/on: ESC[?25l / ESC[?25h
  • clear screen + home: ESC[2J + ESC[H

This is exactly what ~/Workspace/termino/tools/serial_run.py and serial_panel.py send on startup:

  • ESC[0m ESC[?5l ESC[?25l ESC[2J ESC[H

Cursor + line ops

  • CUP (cursor position): ESC[{r};{c}H
  • EL (erase in line): ESC[K

(See serial_panel.py: it updates only changed lines via CUP+EL.)

SGR (style)

  • reset: ESC[0m
  • bold: ESC[1m
  • underline: ESC[4m
  • blink: ESC[5m
  • inverse: ESC[7m

Big text (DEC/VT100-style)

  • double-height (top/bottom): ESC#3 / ESC#4
  • double-width: ESC#6
  • normal size: ESC#5
Seq preview
SEQ
24×80
\\x1b[0m\\x1b[2J\\x1b[H

References

0xa.eth