What is a Dumb Terminal?

Question

There seems to be some confusion what a 'Dumb' terminal is as visible in answers and comments to this question about portable dumb terminals. So:

• What is a Dumb Terminal?

Points that would help to distinguish might be:

• What features or missing thereof make it dumb or not?
• What is a non-dumb/intelligent terminal?
• Where does the term originate?
• When was this term coined?
• Examples for dumb/non-dumb terminals

Please note: This question is about terminals. Terminals are by definition devices that work only connected to and operated by a host. Anything able to work on its own is not a terminal, but something different (usually a computer) acting as a terminal. Further it's about the (historical) use of dumb or non-dumb in this context, not application for other areas (like programs or computers) or in a more general definition of what's dumb.

Answer 1

Like any non-hard term, the label 'dumb' terminal is not only open to interpretation, but also used in different ways over time. Even more so for making others look bad (dumb) or one's own products better (non-dumb) was always part of marketing spin.

---

TL;DR:

Dumb terminals as best described what abilities they do not offer:

• use of complex encodings to reduce output data,
• enabling generation of rich content,
• offloading low level operations, like editing.

Thus

• Dumb Terminals are essentially Glass TTY. They only display what is sent without any processing. Only minimal commands are interpreted; the host has little to no ability to modify displayed content.

• Smart Terminals offer a wide variety of control over the way content is displayed (fonts, colour, size) and allow the host to manipulate content already displayed at the terminal with subsequent output. This enables dynamic content and complex screen designs like (text-)windows. Top models provide local edit features, offloading many low-level functions from the host to the terminal. This greatly reduces CPU load while at the same time speeding up user feedback.

Of course all of this is a continuum with the (Glass-) TTY at the Dumb end and everything past that becoming more and more Smart, all the way to stations like the IBM 3270 or Hazeltine 1500.

---

In the beginning ...

... terminal and printing terminal were redundant terms; it wasn't until the late 1960s that CRT-based terminals became a thing at all. They were essentially 1:1 replacements for existing printing terminals, in the most simple case the classic Type 33 Teletype. Such terminals only supported a very basic set of control functions, barely modified from TTY usage. Hence the name 'Glass TTY'.

• CR and/or LF to move the cursor to the next line
• BS to erase the previous character
• BEL to give some sound
• FF to clear the screen/reposition the cursor to home

Some terminals did split up Home and Clear Screen into two functions - which already started the development of 'less-dumb' terminals. Additions like basic cursor functions (CTRL-H/J/K/L) followed soon. A real arms race started; each manufacturer with its own, usually incompatible(*1), extensions. A look at mid-1980s termcap with collections of hundreds of differing terminals sheds some light.

In the late 1960s and early 1970s 'smarter' terminals began to appear, eventually cumulating in 1971 with block mode terminals like the IBM 3270 and independent operating stations like the Cogar 4 or Datapoint 2200. While the 3270 offered a great way to offload low-level interactivity (aka editing) without leaving the basic terminal paradigm, later development stopped them being terminals but rather stations with local programming and local data processing. Essentially the point when the modern PC was born.

<Insert> In some way this can be compared to the development of the web:

• A dumb terminal is like displaying a text file in a browser.
• A smart one uses HTML instead to format and beautify the output.
• A block mode terminal (like 3270) is like having cgi-forms.
• A RJE station (like a Datapoint 2200) is like Web 2.0 with all its local execution of JS, i.e. a computer. </Insert>

---

Getting Smarter

The way terminals developed at DEC gives a compact example for the gradual 'smartification'.

(The same can be seen when looking at a timeline of many more models from various manufacturers. Narrowing this to a single manufacturer and simplifying the points made should show the overall development)

Their 1970 VT05 already improved over a basic dumb terminal with

• cursor home
• directional cursor movement
• cursor positioning
• erase to end of line
• erase to end of screen
• horizontal tab stops

These additions already allowed improving the output stream by not having to blank out every character at the end of a line or at the end of the output when redrawing a screen. This may sound primitive to today's eyes, but it resulted in much higher output speed - especially considering the slow line speeds of that time.

While the VT05 and its variants were still using ASCII control characters like CTRL-H/J/K/L to handle the extended functionality, it was the VT50/52 of 1974 that broke off from ASCII use and moved all control functions into ESCape sequences. This followed the same line as standardisation efforts of ECMA for smart terminals, but was only partly compatible.

Function-wise, the VT50/52 added more codes to manipulate existing screen content, such as insert/delete line/char. Together with a hold mode, that prevented scrolling, host-controlled update could be made in many ways without redrawing the whole screen. The VT52 enjoyed widespread use, with several competing manufacturers adding compatible modes to their terminals.

By 1978 DEC introduced the VT100. This time fully compatible to ECMA-48, or as we call them now ANSI sequences (*2). But the VT100 also added private sequences to improve content manipulation - like requesting cursor position from the host. Quite handy when multiple applications share a screen.

By 1983 the VT220 further extended abilities for a host to control content, including now being able to configure character sets on the fly. Options allowed the addition of graphic output. The VT220 had much impact(*3), and more than a million were sold.

In 1987 the VT320 marks essentially the last update DEC did to classic terminals (*4). It added even more character and graphics abilities and functions for local editing - much like IBM or Hazeltine decades before. Perhaps most remarkably, a way to handle multiple sessions over a single line was added.

Each of these generations got 'smarter' than the one before and as usual advertisement was made by noting how much better it was than any competing 'dumb' model.

---

Enter 'Dumb' Again

Like so often when a derogatory term is repeated often enough, people go ahead and redefine it in a positive way. That's what Lear-Siegler did in 1975 when marketing their new ADM-3 explicitly as a dumb terminal.

With that move, the terms Dumb Terminal and Glass TTY finally became indistinguishable.

The ADM-3 went on to become quite successful, becoming a main replacement for printing terminals (like the Teletype Model 33) and an icon for terminals in general, not least due to the low price making it pop up an many places with mini computers and even more micros. Albeit usually with the lower caps add on :))

It wasn't until a year later that Lear-Siegler introduced the ADM-3A with improvements like default lower char display, many display attributes, basic cursor movement and cursor positioning. With these additions the ADM-3A was put on par with the DEC VT-05 and stayed firmly on the simple side compared to a DEC VT52 with all its edit commands.

A good contrast of the same time might be the 1977 Hazeltine 1500 'smart terminal'. It featured not only quite comprehensive edit functions for dynamic content, but also a block mode, much like the IBM 3270, but still keeping compatibility with 'standard' terminals, all the way back to Teletype-like devices. Applications could send out format definitions (think of them like a HTML Form) and let all intermediate editing be done locally with zero interaction needed from the host. All entered data is sent back at the end as one large transmission.

The same way the ADM-3(A) captured large part of the dumb(er) end, the Hazeltine 1500 became extremely successful in the business world. Usage of a 1500 resulted, despite its high price, in notable savings by enabling to serve more terminals without bigger computers - the same way IBM mainframes kept an advantage.

---

Bottom Line

• Dumb Terminals are terminals without much control over content format, attributes or handling. Usually barely more than Glass-TTY.

• Smart Terminals allow the host wide control over content display and direct manipulation of existing content.

• Devices that can download programs and execute them are no longer terminals, but computers.

---

*1 - Incompatible in every way - not even the use of ESCape was considered settled, as the 1977(!) Hazeltine 1500 used '~' as escape character for control sequences.

*2 - Much loved from DOS times they are :))

*3 - It's said the IBM-AT keyboard is shaped after the VT220 keyboard

*4 - The 1990 VT420 is barely more than a cost improved variant of the VT320.

Answer 2

I suggest a somewhat different definition of dumb terminal. While clearly some terminals were smarter than others, I don't think things such as programmable selection of fonts and colors, direct cursor addressing, or even limited block mode operation really makes a terminal "smart". But there are a few key things that do make a terminal smart:

• Local storage beyond the bare minimum needed for configuration. A terminal with a few bytes to store settings instead of dip switches isn't "smart". But a terminal with a local floppy drive, hard drive or magnetic tape for storage is "smart". Punched paper tape or other storage that is used simply as direct load & store to the remote location with no local processing (beyond parity checking or similar) doesn't count.
• Ability to run local programs. It doesn't matter whether the programs are loaded locally by typing in on the keyboard or loading via punched paper tape, or loaded remotely (like Javascript downloaded in a browser), but if a terminal can run real programs locally, that is "smart". Could be BASIC, assembler, direct binary load (but programs, not loading an alternate character set), APL, whatever.

This clearly puts machines like the Datapoint 2200 into the smart category. It also keeps machines like the range of DEC VT terminals, Wyse terminals, etc. in the dumb category. Heath/Zenith H-19/Z-19 dumb, Heath/Zenith H-89/Z-89 smart.

As a simple example of why I think features such as fonts/attributes should not be something that makes a terminal "smart", consider boldface and u̲n̲d̲e̲r̲l̲i̲n̲e̲: (and ironically had to cheat here to get underline because Markdown as used by SE doesn't support user-designated underline...)

• Teletype - Boldface: print text, CR without LF, print spaces to position, print text; Underline: print, CR without LF, print spaces to position, print _
• First dumb terminals - no bold or underline!
• Later dumb terminals - send attribute (control or escape code) for bold or underline, display text, send attribute to turn off bold or underline
• HTML - Bold - <b>text</b>; Underline <u>text</u>

In all of the above cases, the host computer is sending a stream of characters that are interpreted by the terminal in some manner. No real "smart" capabilities needed. It is only later with:

• HTML with CSS - style sheet sent at the beginning or as a separately loaded file, followed by user's choice of tags surrounding the text.

and of course Javascript really making things "smart" that the terminal needs to do anything more than an incrementally more advanced "process the incoming character stream in a well-defined manner".

This keeps a number of color and/or graphics terminals in the "dumb" category as well. For example, the Tektronix 4010 and later emulations such as the Wyse 99GT included high resolution graphics but no permanent storage and no local processing beyond processing the simple drawing commands in the input stream.

Where I do see some fuzziness is with block/batch mode terminals. IBM 3270 is the classic, but there were plenty of other terminals with similar (at least conceptually) capabilities. Even just protected space/unprotected fields is a certain level of "smart", and if there is any validation included (e.g., send a code to indicate a field must be numeric) then that does seem to cross over to "smart". On the other hand, is the ability to mark fields and enforce some validation enough of a "program" to merit "smart"?

Once microcomputers became more common, particularly with advent of affordable PC networks, the distinction became, in my opinion, a little clearer again. In the mid-1980s and beyond, anything with no local storage and no ability to run "real" programs was "dumb". PC that used a ROM to boot over the network with no local floppy or hard drive? Smart because it could run local programs, even if they had to be loaded over the network. Terminal with block mode but no ability to run user programs and no storage? Dumb.

While conceptually similar to dumb terminals in terms of power/capability relative to a remote system, any device capable of running a modern web browser is, by my definition, a smart terminal. If nothing else, if a device can run downloaded Javascript, it qualifies as smart.

Answer 3

As a practical matter, a "dumb" terminal is a terminal that has little more than the capabilities specified in the Unix terminfo database for TERM=dumb. Those are:

dumb|80-column dumb tty,
    am,
    cols#80,
    bel=^G, cr=\r, cud1=\n, ind=\n,

or, in English: it displays 80 columns of fixed-width ASCII text; it can move the cursor position back to the beginning of the current line, and to the beginning of the next line, and it can ring a bell. And that's it. You don't even get backspace. (I am not sure what the binary "am" capability means -- "automatic right margin" is the only explanation the manual gives.) This is essentially what a classical teleprinter like the Teletype Model 33 could do.

I would personally set the dividing line between "dumb" and "not dumb" a little bit higher, with the "glasstty" capability set still qualifying as "dumb":

glasstty|classic glass tty interpreting ASCII control characters,
    am, OTbs,
    cols#80,
    bel=^G, cr=\r, clear=^L, cud1=\n, cub1=^H, kcud1=\n, kcub1=^H,
    nel=\r\n, ht=^I,

Here we have backspace (and thus the ability to edit the current line) and screen clear, but we don't have an addressable cursor, fonts, colors, graphics, or non-ASCII characters. Anything with an addressable cursor is definitely "not dumb". A tty with font and charset control but no cursor addressing could still count as "dumb"; there were teleprinters that had those, after all.

"Smart" is another matter. Personally, the features that other answers say are required for a terminal to be "smart" — local persistent storage, programmability, etc — to me they sound like features that make the device not a terminal anymore, but rather a full-fledged computer. Even X terminals didn't have those. Maybe that means to me there's no such thing as a "smart terminal."

Answer 4

"Dumb" terminals had a simple enough basic feature set (add character, scroll up, backspace, etc.) that their logic could be completely implemented without a CPU or microprocessor, some using just TTL SSI and MSI logic devices, plus memory (RAM or shift registers). There were even cookbooks published with logic schematics so you could build one from simple IC parts (and no CPU).

Smart terminals often had a rich enough interface protocol that a processor and software or microcode was required to decode the command sequences, and perhaps control a display with more features (fonts, status bars, colors, etc.)

Dumb terminals could exist and were manufactured years before single chip microprocessors were available. Later, after more advanced ICs were available, a vendor could segment their market with a microprocessor based terminal that only included mostly features possible in earlier non-microprocessor based terminals. Thus called "Dumb" for marketing reasons.

Answer 5

Firstly let me say that in the UK, using the term "dumb" to mean "unintelligent" is considered offensive by those with speech disorders. It appears to be perfectly acceptable in the US.

My recollection (I'm not going to try and research it) is that the term "dumb terminal" has a rather confused history. I first encountered it in the context of mainframes (specifically ICL mainframes) where a significant amount of input/output processing was offloaded from the central computer, but the usual configuration was to do this processing in a "cluster controller" that supported perhaps 16 or 32 terminals. These terminals had very little logic beyond being able to display a particular character at a particular location. The cluster controller did everything, from reflecting keystrokes onto the screen (if you got the wiring wrong, your keystrokes would appear on someone else's screen) to some quite complex functionality such as checking that particular input fields were required to be numeric. The intelligence was all in the controller, not in the terminal. But sometimes you needed a single terminal in a location where there was no cluster, and then you could use an expensive terminal that contained all the logic built in. So you had the choice between using a dumb terminal as part of a cluster controlled by an intelligent controller, or using an intelligent terminal.

The functionality of the mainframe terminal was not unlike that of a simple HTML form. You could send a message out from a transaction processing application with control sequences to mark which parts of the screen were editable and which were fixed, to control the tab order between fields, and to do basic validation. When the user hit SEND, only the input fields were sent back (perhaps only those that had actually been edited). This all served to reduce the IO and processing load on the mainframe, allowing it to support hundreds of terminals despite having remarkably little CPU power.

Later, in the 1980s, when UNIX came along, this all changed. By this time mainframe terminal functionality had moved into the terminal and out of the controller, so in the old sense of the word, all terminals were intelligent. At the same time UNIX and VAX minicomputers had enough CPU power to do all the low-level keystroke processing in the main processor; they had none of the offloaded processing that mainframes had, so in this sense their terminals were "dumb".

However, because the application on a UNIX or VAX machine was notified of every keystroke on the terminal, they were able to deliver a much more interactive and responsive user experience. This led to an inversion of the terminology: the mainframe terminals were referred to as "dumb terminals" not because they lacked internal processing logic, but because they lacked the interactivity to deliver the same kind of user interface.

Answer 6

The other answers provide lots of details while missing the point.

On business computer systems the terminals were used to fill in forms that were then submitted to a computer program that then returned the next form to be displayed and/or filled in. As well as forms a computer program may present a multiple level menu and be reactivated when the user had chosen an option. (Think IBM mainframe)

On technical computer systems terminals were used to edit files (with vi for example) and to display auto-updated data like readings from sensors on an industrial process. (Think PDP 11)

---

We will only consider the form filling for business computers from now on.

Clearly form filling needs logic to move between fields and edit the text in a field. There are a few locations this logic was implemented in:

• Within the application as was common on Unix, this was the most flexible option but limited how many users could be supported on a single machine. It also resulted in very slow movement between fields if the data link was slow or the program had been paged out. (Often the application had to respond to each key press as it was pressed.)

• In a separate IO processor (common with VMS) this permitted the main computer to support many more users but still has the issue with slow response over poor data links.

• In a smart terminal when the application sent a description of the form to the terminal, and the terminal returned the value of the fields to application when the user submitted the form. Often these would be multiple page forms with restrictions on the format of data that could be entered into a field for example a date field. (Hidden fields were often used to track application state, so a form could still be processed if application has been restarted.) Very common with IBM 360 system using IBM smart terminals.

---

A 'Dumb' terminal was a terminal without the ability to locally edit forms. The form functions in HTML logically (before Javascript was used) behaved much like a mainframe smart terminal.