26

Assume that the following computer terminal is connected to a large computer:

VT100 displaying text

When I type something on the keyboard (for example: pwd), is it the computer terminal the one that receives the keystrokes and displays the corresponding characters on the screen? Or will the keystrokes go to the large computer and then the large computer will send back the characters to the computer terminal, and then the computer terminal will display the characters on the screen?

Note: I am talking about how the pwd itself is displayed, and not the result of the pwd.

4 Answers 4

35

Terminals fall into two broad categories:

  1. Character-at-a-time
  2. Line- or Screen-at-a-time

The VT100 is a character-at-a-time terminal, which means that when you press a key on the keyboard, a character gets sent to the computer. If you have "local echo" enabled, then as soon as the character is sent it is also immediately displayed (often done using a loopback circuit that copies transmitted data to the receive pin), but typically you would have local echo turned off, because there are some things you don't want to see displayed on the screen as you type them (like passwords).

This means that typically, anything shown on a character-at-a-time terminal was sent by the host computer (because the host computer assumes you have local echo turned off). In your "pwd" example the 3 characters 'p', 'w' and 'd' were either echoed back by the terminal driver (due to it being in "line mode"), or they were echoed back by the shell (common in modern shells that support command editing). For more information about this look up the Unix terminal line disciplines "raw", "cooked" (also known as Canonical) and "cbreak" (sometimes jokingly called "rare" or "half cooked").

The other broad category of terminal includes half-duplex terminals and IBM mainframe terminals.

Half-duplex terminals were made to support a communications line that only allowed transmission in one direction at a time. When your terminal was in transmit mode, you could type on the keyboard. When it was in receive mode, the keyboard was typically locked. As a result, when you were typing input, you would generally type out an entire line (with local echo enabled so you can see what you're typing), then when you pressed the Enter key that would signal the host computer to "turn the line around" so that it could use the line to send a response to your command . When the computer was done sending output it would send a signal to enable the terminal to transmit (and re-enable the keyboard).

IBM mainframe terminals took this a step further by allowing you to fill out an entire screenful of information, all done locally within the terminal itself. Everything you typed was processed locally (nothing got sent to the host computer at all). Then, when you pressed Enter it would send a burst of data to the host computer containing all your screen input. This was more efficient on those types of systems than character-at-a-time transmission because on those systems servicing an I/O interrupt was computationally expensive and doing so for each individual character wasted too much CPU capacity, so this scheme was used even when you had a full-duplex communication line that allowed transmission in both directions at once.

6

The details and conventions vary between configurations.

When you type pwd at the keyboard, those three bytes get sent to the computer. The shell accepts them, and writes them back to the terminal. So pwd really gets sent back to the terminal; that's why you can see what you type. This scheme was common on some systems, especially from the 1970s and onwards.

Some very old systems had a different convention: Instead of the computer accepting the input and sending a copy back to the terminal, the terminal wrote the input onto the screen (or paper) and sent a copy to the computer. This was common on the PDP-8 and ASR-33, but is uncommon now.

5
  • 2
    This is generally referred to "local echo" in the terminal's configuration; whether you need to use it or not depends on the back-end system's configuration.
    – Joe
    May 15, 2017 at 13:36
  • 1
    @Wilson "The shell accepts them, and writes them back to the terminal" Is it the shell or the line discipline that writes them back to the terminal? May 15, 2017 at 13:53
  • 1
    @user7681202 It depends. Actually it might not be the shell, it could be an application or firmware or anything else. The point is, software of some description is responsible for doing it. May 15, 2017 at 14:05
  • @Joe I've seen where the back-end system would relay the typed character back and I've seen it where it doesn't. In fact, I've seen it where enabling local echo causes duplicates. Meaning it's being sent back from the remote AND copied locally.
    – cbmeeks
    May 15, 2017 at 15:02
  • 1
    @cbmeeks that was precisely my point. But it's up to you as the configurer of the terminal to set it so it matches the configuration of the back-end's expectations.
    – Joe
    May 15, 2017 at 15:32
4

If local echo is turned on in your terminal's configuration, then whatever you type will immediately appear onscreen. If it's turned off, then whether you see what you type depends on whether the server sends the characters back to your terminal.

So if local echo is turned on and the server also sends each character back, you will see two copies of each letter you press. Or if local echo is turned off and the server does not send each character back, you won't see what you typed at all.

2

VT100s were most commonly used with VAX/VMS systems. The following description is based upon VAX/VMS 4.4, details change as OSes evolve.

The “10,000 foot overview” is that a process (for instance a user process or LOGINOUT.EXE issued a $QIO read to the terminal and continued running. Whe the “pwd” was pressed the terminal sent this down the line to the computer and the device drivers (to be described later) delivered the character to the process via an Asyncronous System Trap (AST), a form of interrupt. The process reissued read $QIO.

The terminal drivers came in two parts: a port driver and TTDRIVER.EXE. The port driver was responsible for handling low-level characteristics and multiplexing. For instance a single DZ11 had 8 ports, each capable of full duplex communication. DZDRIVER controlled the duplex mode, parity and speed. It also controlled the XON/XOFF (aka DC1/DC3) handshaking. Each charater as received was passed up to TTDRIVER. This handled logical functions such as the write-ahead buffer and raised the necessary ASTs to the connected process. Normally TTDRIVER assembled a line in the type-ahead buffer and delivered it as a single AST to the controlling process. When writing TTDRIVER took an inbound $QIO from the process and sent it a character at a time to DZDRIVER.

Earlier versions of VMS did not split the driver, instead the port drivers included some of the TTDRIVER functionality and the calling process the rest. This resulted in many more $QIOs and ASTs which impacted performance.

Operations staff and engineers who needed to troubleshoot or install comms lines had an “answerback” plug. This could be a posh plastic moulded one or more commonly just a DB25 socket with pins 2 and 3 (Tx and Rx) shorted. If a male answerback was required then a straightened paperclip sufficed. With the answerback in anything typed at the VT100’s keyboard was immediately echoed to the screen.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .