A computer terminal is an electronic or electromechanical hardware device that can be used for entering data into, and transcribing data from, a computer or a computing system. The teletype was an example of an early day hardcopy terminal, and predated the use of a computer screen by decades.
Early terminals were inexpensive devices but very slow compared to punched cards or paper tape for input, but as the technology improved and video displays were introduced, terminals pushed these older forms of interaction from the industry. A related development was timesharing systems, which evolved in parallel and made up for any inefficiencies of the user’s typing ability with the ability to support multiple users on the same machine, each at their own terminal/terminals.
The function of a terminal is typically confined to transcription and input of data; a device with significant local programmable data processing capability may be called a “smart terminal” or fat client. A terminal that depends on the host computer for its processing power is called a “dumb terminal” or a thin client. A personal computer can run terminal emulator software that replicates functions of a real-world terminal, sometimes allowing concurrent use of local programs and access to a distant terminal host system.
The console of Konrad Zuse’s Z3 had a keyboard in 1941, as did the Z4 in 1942-45. But these consoles could only be used to enter numeric inputs and were thus analogous to those of calculating machines; programs, commands, and other data were entered via paper tape. Both machines had a row of display lamps for results.
In 1955, the Whirlwind Mark I computer was the first computer equipped with a keyboard-printer combination with which to support direct input of data and commands and output of results. The device was a Friden Flexowriter, which would continue to serve this purpose on many other early computers well into the 1960s.
Early user terminals connected to computers were, like the FlexoWriter, electromechanical teleprinters/teletypewriters (TeleTYpewriter, TTY), such as the Teletype Model 33, originally used for telegraphy; early Teletypes were typically configured as Keyboard Send-Receive (KSR) or Automatic Send-Receive (ASR), the latter including a paper tape reader and punch. This led to the use of the current loop interface that was already used in telegraphy, as well as a thriving market in surplus machines for computer use.
Custom-designs keyboard/printer terminals that came later included the IBM 2741 (1965) and the DECwriter (1970). Respective top speeds of teletypes, IBM 2741 and the LA30 (an early DECwriter) were 10, 15 and 30 characters per second. Although at that time “paper was king” the speed of interaction was relatively limited.
The DECwriter was the last major printing-terminal product. It faded away after 1980 under pressure from VDUs, with the last revision (the DECwriter IV of 1982) abandoning the classic teletypewriter form for one more resembling a desktop printer.
A Video Display Unit (VDU) displays information on a screen rather than printing text to paper and typically uses a cathode-ray tube (CRT). Due to that technology these devices were often called “CRTs”. VDUs in the 1950s were typically designed for displaying graphical data rather than just text. CRT displays in that time frame were used in, e.g., experimental computers at MIT; Commercial computer from, e.g., DEC, ERA, IBM, UNIVAC; military computers for, e.g., BMEWS, BUIC, SAGE.
Two early landmarks in the development of the VDU were the Univac Uniscope 300 and the IBM 2260, both in 1964. Both were block-mode terminals designed to ship a page at a time, rather than character-mode devices. The Hazeltine 2000 of 1970 was a notable later product of the same kind.
The Datapoint 3300 from Computer Terminal Corporation, announced in 1967 and shipped in 1969, was a character-mode device that emulated a Model 33 Teletype. This reflects the fact that early character-mode terminals were often deployed to replace teletype machines as a way to reduce operating costs.
The next generation of VDUs went beyond teletype emulation with an addressable cursor that gave them the ability to paint two-dimensional displays on the screen. Despite this, early devices of this type were often called “Glass TTYs”. The classic era of the VDU began in the early 1970s and was closely intertwined with the rise of time sharing computers. Important early products were the ADM-3A, VT52, and VT100. These devices used no CPU, instead relying on individual logic gates or very primitive LSI chips. This made them inexpensive and they quickly became extremely popular Input-Output devices on many different types of computer system, often replacing earlier and more expensive printing terminals.
After 1970 several suppliers gravitated to a set of common standards:
- ASCII character set (rather than, say, EBCDIC or anything specific to one company), but early/economy models often supported only capital letters (such as the original ADM-3, the Data General model 6052 – which could be upgraded to a 6053 with a lower-case character ROM – and the Heathkit H9)
- RS-232 serial ports (25-pin, ready to connect to a modem, yet some manufacturer-specific pin usage extended the standard, e.g. for use with 20-mA current loops)
- 24 lines (or possibly 25 – sometimes a special status line) of 72 or 80 characters of text (80 was the same as IBM punched cards). Later models sometimes had two character-width settings.
- Some type of cursor that can be positioned (with arrow keys or “home” and other direct cursor address setting codes).
- Implementation of at least 3 control codes: Carriage Return (Ctrl-M), Line-Feed (Ctrl-J), and Bell (Ctrl-G), but usually many more, such as escape sequences to provide underlining, dim or reverse-video character highlighting, and especially to clear the display and position the cursor.
The experimental era of serial VDUs culminated with the VT100 in 1978. By the early 1980s, there were dozens of manufacturers of terminals, including Lear-Siegler, ADDS, Data General, DEC, Hazeltine Corporation, Heath/Zenith, Hewlett Packard, IBM, Televideo, Volker-Craig, and Wyse, many of which had incompatible command sequences (although many used the early ADM-3 as a starting point).
The great variations in the control codes between makers gave rise to software that identified and grouped terminal types so the system software would correctly display input forms using the appropriate control codes; In Unix-like systems the termcap or terminfo files, the stty utility, and the TERM environment variable would be used; in Data General’s Business BASIC software, for example, at login-time a sequence of codes were sent to the terminal to try to read the cursor’s position or the 25th line’s contents using a sequence of different manufacturer’s control code sequences, and the terminal-generated response would determine a single-digit number (such as 6 for Data General Dasher terminals, 4 for ADM 3A/5/11/12 terminals, 0 or 2 for TTY’s with no special features) that would be available to programs to say which set of codes to use.
The great majority of terminals were monochrome, manufacturers variously offering green, white or amber and sometimes blue screen phosphors. (Amber was claimed to reduce eye strain). Terminals with modest color capability were also available but not widely used; for example, a color version of the popular Wyse WY50, the WY350, offered 64 shades on each character cell.
VDUs were eventually displaced from most applications by networked personal computers, at first slowly after 1985 and with increasing speed in the 1990s. However, they had a lasting influence on PCs. The keyboard layout of the VT220 terminal strongly influenced the Model M shipped on IBM PCs from 1985, and through it all later computer keyboards.
By the time cathode-ray tubes were replaced by flatscreens after the year 2000, the hardware computer terminal was obsolete.
An “intelligent” terminal does its own processing, usually implying a microprocessor is built in, but not all terminals with microprocessors did any real processing of input: the main computer to which it was attached would have to respond quickly to each keystroke. The term “intelligent” in this context dates from 1969.
Notable examples include the IBM 2250, predecessor to the IBM 3250 and IBM 5080, and IBM 2260, predecessor to the IBM 3270, introduced with System/360 in 1964.
Most terminals were connected to minicomputers or mainframe computers and often had a green or amber screen. Typically terminals communicate with the computer via a serial port via a null modem cable, often using an EIA RS-232 or RS-422 or RS-423 or a current loop serial interface. IBM systems typically communicated over a Bus and Tag channel, a coaxial cable using a proprietary protocol, a communications link using Binary Synchronous Communications or IBM’s SNA protocol, but for many DEC, Data General and NCR (and so on) computers there were many visual display suppliers competing against the computer manufacturer for terminals to expand the systems. In fact, the instruction design for the Intel 8008 was originally conceived at Computer Terminal Corporation as the processor for the Datapoint 2200.
From the introduction of the IBM 3270, and the DEC VT100 (1978), the user and programmer could notice significant advantages in VDU technology improvements, yet not all programmers used the features of the new terminals (backward compatibility in the VT100 and later Televideo terminals, for example, with “dumb terminals” allowed programmers to continue to use older software).
Some dumb terminals had been able to respond to a few escape sequences without needing microprocessors: they used multiple printed circuit boards with many integrated circuits; the single factor that classed a terminal as “intelligent” was its ability to process user-input within the terminal—not interrupting the main computer at each keystroke—and send a block of data at a time (for example: when the user has finished a whole field or form). Most terminals in the early 1980s, such as ADM-3A, TVI912, Data General D2, DEC VT52, despite the introduction of ANSI terminals in 1978, were essentially “dumb” terminals, although some of them (such as the later ADM and TVI models) did have a primitive block-send capability. Common early uses of local processing power included features that had little to do with off-loading data processing from the host computer but added useful features such as printing to a local printer, buffered serial data transmission and serial handshaking (to accommodate higher serial transfer speeds), and more sophisticated character attributes for the display, as well as the ability to switch emulation modes to mimic competitor’s models, that became increasingly important selling features during the 1980s especially, when buyers could mix and match different suppliers’ equipment to a greater extent than before.
The advance in microprocessors and lower memory costs made it possible for the terminal to handle editing operations such as inserting characters within a field that may have previously required a full screen-full of characters to be re-sent from the computer, possibly over a slow modem line. Around the mid 1980s most intelligent terminals, costing less than most dumb terminals would have a few years earlier, could provide enough user-friendly local editing of data and send the completed form to the main computer. Providing even more processing possibilities, workstations like the Televideo TS-800 could run CP/M-86, blurring the distinction between terminal and Personal Computer.
Another of the motivations for development of the microprocessor was to simplify and reduce the electronics required in a terminal. That also made it practicable to load several “personalities” into a single terminal, so a Qume QVT-102 could emulate many popular terminals of the day, and so be sold into organizations that did not wish to make any software changes. Frequently emulated terminal types included:
- Lear Siegler ADM-3A and later models
- Televideo 910 to 950 (these models copied ADM3 codes and added several of their own, eventually being copied by Qume and others)
- Digital Equipment Corporation VT52 and VT100
- Data General D1 to D3 and especially D200 and D210
- Hazeltine Corporation H1500
- Tektronix 4014
- Wyse W50, W60 and W99
The ANSI X3.64 escape code standard produced uniformity to some extent, but significant differences remained. For example, the VT100, Heathkit H19 in ANSI mode, Televideo 970, Data General D460, and Qume QVT-108 terminals all followed the ANSI standard, yet differences might exist in codes from function keys, what character attributes were available, block-sending of fields within forms, “foreign” character facilities, and handling of printers connected to the back of the screen.
The term Intelligent Terminal can now refer to a store (check-out) computer.
While early IBM PCs had single-color green screens, these screens were not terminals. The screen of a PC did not contain any character generation hardware; all video signals and video formatting were generated by the video display card in the PC, or (in most graphics modes) by the CPU and software. An IBM PC monitor, whether it was the green monochrome display or the 16-color display, was technically much more similar to an analog TV set (without a tuner) than to a terminal. With suitable software a PC could, however, emulate a terminal, and in that capacity it could be connected to a mainframe or minicomputer. The Data General One could be booted into terminal emulator mode from its ROM. Eventually microprocessor-based personal computers greatly reduced the market demand for conventional terminals.
In the 1990s especially, “thin clients” and X terminals have combined economical local processing power with central, shared computer facilities to retain some of the advantages of terminals over personal computers:
Today, most PC telnet clients provide emulation of the most common terminal, the DEC VT100, using the ANSI escape code standard X3.64, or could run as X terminals using software such as Cygwin/X under Microsoft Windows or X.Org Server software under Linux.
Since the advent and subsequent popularization of the personal computer, few genuine hardware terminals are used to interface with computers today. Using the monitor and keyboard, modern operating systems like Linux and the BSD derivatives feature virtual consoles, which are mostly independent from the hardware used.
When using a graphical user interface (or GUI) like the X Window System, one’s display is typically occupied by a collection of windows associated with various applications, rather than a single stream of text associated with a single process. In this case, one may use a terminal emulator application within the windowing environment. This arrangement permits terminal-like interaction with the computer (for running a command-line interpreter, for example) without the need for a physical terminal device; it can even run multiple terminal emulators on the same device.
A character-oriented terminal is a type of computer terminal that communicates with its host one character at a time, as opposed to a block-oriented terminal that communicates in blocks of data. It is the most common type of data terminal, because it’s easy to implement and program. Connection to the mainframe computer or terminal server is achieved via RS-232 serial links, Ethernet or other proprietary protocols.
A text terminal, or often just terminal (sometimes text console) is a serial computer interface for text entry and display. Information is presented as an array of pre-selected formed characters. When such devices use a video display such as a cathode-ray tube, they are called a “video display unit” or “visual display unit” (VDU) or “video display terminal” (VDT).
The system console is often a text terminal used to operate a computer. Modern computers have a built-in keyboard and display for the console. Some Unix-like operating systems such as Linux and FreeBSD have virtual consoles to provide several text terminals on a single computer.
The fundamental type of application running on a text terminal is a command-line interpreter or shell, which prompts for commands from the user and executes each command after a press of Return. This includes Unix shells and some interactive programming environments. In a shell, most of the commands are small applications themselves.
Another important application type is that of the text editor. A text editor typically occupies the full area of display, displays one or more text documents, and allows the user to edit the documents. The text editor has, for many uses, been replaced by the word processor, which usually provides rich formatting features that the text editor lacks. The first word processors used text to communicate the structure of the document, but later word processors operate in a graphical environment and provide a WYSIWYG simulation of the formatted output. However, text editors are still used for documents containing markup such as DocBook or LaTeX.
Programs such as Telix and Minicom control a modem and the local terminal to let the user interact with remote servers. On the Internet, telnet and ssh work similarly.
In the simplest form, a text terminal is like a file. Writing to the file displays the text and reading from the file produces what the user enters. In Unix-like operating systems, there are several character special files that correspond to available text terminals. For other operations, there are special escape sequences, control characters and
termios functions that a program can use, most easily via a library such as ncurses. For more complex operations, the programs can use terminal specific ioctl system calls. For an application, the simplest way to use a terminal is to simply write and read text strings to and from it sequentially. The output text is scrolled, so that only the last several lines (typically 24) are visible. Unix systems typically buffer the input text until the Enter key is pressed, so the application receives a ready string of text. In this mode, the application need not know much about the terminal. For many interactive applications this is not sufficient. One of the common enhancements is command-line editing (assisted with such libraries as readline); it also may give access to command history. This is very helpful for various interactive command-line interpreters.
Even more advanced interactivity is provided with full-screen applications. Those applications completely control the screen layout; also they respond to key-pressing immediately. This mode is very useful for text editors, file managers and web browsers. In addition, such programs control the color and brightness of text on the screen, and decorate it with underline, blinking and special characters (e.g. box-drawing characters). To achieve all this, the application must deal not only with plain text strings, but also with control characters and escape sequences, which allow moving the cursor to an arbitrary position, clearing portions of the screen, changing colors and displaying special characters, and also responding to function keys. The great problem here is that there are many different terminals and terminal emulators, each with its own set of escape sequences. In order to overcome this, special libraries (such as curses) have been created, together with terminal description databases, such as Termcap and Terminfo.
Dumb terminals are those that can interpret a limited number of control codes (CR, LF, etc.) but do not have the ability to process special escape sequences that perform functions such as clearing a line, clearing the screen, or controlling cursor position. In this context dumb terminals are sometimes dubbed glass Teletypes, for they essentially have the same limited functionality as does a mechanical Teletype. This type of dumb terminal is still supported on modern Unix-like systems by setting the environment variable TERM to dumb. Smart or intelligent terminals are those that also have the ability to process escape sequences, in particular the VT52, VT100 or ANSI escape sequences.
A graphical terminal can display images as well as text. Graphical terminals are divided into vector-mode terminals, and raster mode.
A vector-mode display directly draws lines on the face of a cathode-ray tube under control of the host computer system. The lines are continuously formed, but since the speed of electronics is limited, the number of concurrent lines that can be displayed at one time is limited. Vector-mode displays were historically important but are no longer used. Practically all modern graphic displays are raster-mode, descended from the picture scanning techniques used for television, in which the visual elements are a rectangular array of pixels. Since the raster image is only perceptible to the human eye as a whole for a very short time, the raster must be refreshed many times per second to give the appearance of a persistent display. The electronic demands of refreshing display memory meant that graphic terminals were developed much later than text terminals, and initially cost much more.
Most terminals today are graphical; that is, they can show images on the screen. The modern term for graphical terminal is “thin client”. A thin client typically uses a protocol like X11 for Unix terminals, or RDP for Microsoft Windows. The bandwidth needed depends on the protocol used, the resolution, and the color depth.
Modern graphic terminals allow display of images in color, and of text in varying sizes, colors, and fonts (type faces).
In the early 1990s an industry consortium attempted to define a standard, AlphaWindows, that would allow a single CRT screen to implement multiple windows, each of which was to behave as a distinct terminal. Unfortunately like I2O this suffered from being run as a closed standard: non-members were unable to obtain even minimal information and there was no realistic way a small company or independent developer could join the consortium. Possibly because of this the standard disappeared without a trace.
A terminal emulator is a piece of software that emulates a text terminal. In the past, before the widespread use of local area networking and broadband internet access, many computers would use a serial access program to communicate with other computers via telephone line or serial device.
When the first Macintosh was released, a program called MacTerminal was used to communicate with many computers, including the IBM PC.
Dec Terminal was one of the first terminal programs for the popular Altair.
The Win32 console on Windows does not emulate a physical terminal that supports escape sequences so SSH and Telnet programs (for logging in textually to remote computers) for Windows, including the Telnet program bundled with some versions of Windows, often incorporate their own code to process escape sequences.
The terminal emulators on most Unix-like systems—such as, for example, gnome-terminal, qterminal, xterm, and Terminal.app—do emulate physical terminals including support for escape sequences; e.g., xterm can emulate the VT220 and Tektronix 4010 hardware terminals.
Terminals can operate in various modes, relating to when they send input typed by the user on the keyboard to the receiving system (whatever that may be):
- Character mode (a.k.a. character-at-a-time mode): In this mode, typed input is unbuffered and sent immediately to the receiving system.
- Line mode (a.k.a. line-at-a-time mode): In this mode, the terminal is buffered, provides a local line editing function, and sends an entire input line, after it has been locally edited, when the user presses an, e.g., ↵ Enter, EOB, key. A so-called “line mode terminal” operates solely in this mode.
- Block mode (a.k.a. screen-at-a-time mode): In this mode (also called block-oriented), the terminal is buffered and provides a local full-screen data function. The user can enter input into multiple fields in a form on the screen (defined to the terminal by the receiving system), moving the cursor around the screen using keys such as Tab ↹ and the arrow keys and performing editing functions locally using insert, delete, ← Backspace and so forth. The terminal sends only the completed form, consisting of all the data entered on the screen, to the receiving system when the user presses an ↵ Enter key.
There is a distinction between the return and the ↵ Enter keys. In some multiple-mode terminals, that can switch between modes, pressing the ↵ Enter key when not in block mode does not do the same thing as pressing the return key. Whilst the return key will cause an input line to be sent to the host in line-at-a-time mode, the ↵ Enter key will rather cause the terminal to transmit the contents of the character row where the cursor is currently positioned to the host, host-issued prompts and all. Some block-mode terminals have both an ↵ Enter and local cursor moving keys such as Return and New Line.
Different computer operating systems require different degrees of mode support when terminals are used as computer terminals. The POSIX terminal interface, as provided by Unix and POSIX-compliant operating systems, does not accommodate block-mode terminals at all, and only rarely requires the terminal itself to be in line-at-a-time mode, since the operating system is required to provide canonical input mode, where the terminal device driver in the operating system emulates local echo in the terminal, and performs line editing functions at the host end. Most usually, and especially so that the host system can support non-canonical input mode, terminals for POSIX-compliant systems are always in character-at-a-time mode. In contrast, IBM 3270 terminals connected to MVS systems are always required to be in block mode.
A block-oriented terminal or block mode terminal is a type of computer terminal that communicates with its host in blocks of data, as opposed to a character-oriented terminal that communicates with its host one character at a time. A block oriented terminal may be card-oriented, display oriented, keyboard-display, keyboard-printer, printer or some combination.
The IBM 3270 is perhaps the most familiar implementation of a block-oriented display terminal, but most mainframe computer manufacturers and several other companies produced them. The description below is in terms of the 3270, but similar considerations apply to other types.
Block-oriented terminals typically incorporate a buffer which stores one screen or more of data, and also stores data attributes, not only indicating appearance (color, brightness, blinking, etc.) but also marking the data as being enterable by the terminal operator vs. protected against entry, as allowing the entry of only numeric information vs. allowing any characters, etc. In a typical application the host sends the terminal a preformatted panel containing both static data and fields into which data may be entered. The terminal operator keys data, such as updates in a database entry, into the appropriate fields. When entry is complete (or ENTER or PF key pressed on 3270s), a block of data, usually just the data entered by the operator (modified data), is sent to the host in one transmission. The 3270 terminal buffer (at the device) could be updated on a single character basis, if necessary, because of the existence of a “set buffer address order” (SBA), that usually preceded any data to be written/overwritten within the buffer. A complete buffer could also be read or replaced using the
READ BUFFER command or
WRITE command (unformatted or formatted in the case of the 3270).
Block-oriented terminals cause less system load on the host and less network traffic than character-oriented terminals. They also appear more responsive to the user, especially over slow connections, since editing within a field is done locally rather than depending on echoing from the host system.
Early terminals had limited editing capabilities – 3270 terminals, for example, only could check entries as valid numerics. Subsequent “smart” or “intelligent” terminals incorporated microprocessors and supported more local processing.
Programmers of block-oriented terminals often used the technique of storing context information for the transaction in progress on the screen, possibly in a hidden field, rather than depending on a running program to keep track of status. This was the precursor of the HTML technique of storing context in the URL as data to be passed as arguments to a CGI program.
Unlike a character-oriented terminal, where typing a character into the last position of the screen usually causes the terminal to scroll down one line, entering data into the last screen position on a block-oriented terminal usually causes the cursor to wrap— move to the start of the first enterable field. Programmers might “protect” the last screen position to prevent inadvertent wrap. Likewise a protected field following an enterable field might lock the keyboard and sound an audible alarm if the operator attempted to enter more data into the field than allowed.
Common block oriented terminals
Remote job entry
- IBM 2770
- IBM 2780
- IBM 3770
- IBM 3780
- IBM 2260
- IBM 3270
- IBM 5250
- Burroughs Corporation TD-830
- AT&T Dataspeed 40 (3270 clone manufactured by Teletype Corporation)
- TeleVideo 912,920, 925, 950
- Tandem Computers VT6530
- Hewlett-Packard VT2640
- UNIVAC Uniscope series
- Digital Equipment Corporation VT61, VT62
- Lear Siegler ADM31 (optional)
- Honeywell VIP 7700/7760
- ITT Corporation Courier line
- Bull Questar
Was this article helpful?