6

TL;DR:

In video terminals, like the VT100, can control characters and escape sequences only be sent by an application from the host computer to the terminal? Or can they also be sent directly by the user from the keyboard to the terminal? That is, the user controlling the terminal from the keyboard, rather than an application controlling the terminal from the host computer?

Long version:

I'm trying to understand how video terminals worked by the example of the VT100 family.

I found the following diagram of a VT102 in the VT102 user guide (Figure 1-1).

enter image description here

I assume that on the computer-side of the communication line, there is a driver for this type of terminal, and behind the driver there is an application that reads its input from the terminal and writes its output to the terminal (through the driver). This application might be a shell, or any other application that needs to get input from the user and/or show output to the user.

What I understood so far:

  • When a user of the terminal types a character on the keyboard, this character is immediately transmitted to the computer (i.e. the VT100 family uses character-at-a-time mode, there is no local processing of characters entered by the user).
  • The receiving application on the computer can then read this character from the terminal driver and do with it whatever it has to do with it.
  • Every character that the writes to its output (which is the terminal driver) is sent to the terminal where it is displayed on the screen (except control characters and escape sequences, see below).
  • If the application-specific purpose of a character sent from the terminal to the application is such that the user should see it on the screen, then the application must send this character back to the terminal so that it gets displayed on the terminal screen. That is, the VT100 family uses, in most cases, no local echo However, for the VT102, local echo is a setting that can be enabled, see here. This becomes obvious if the application on the computer is something like vi. There, not all characters that the user types must appear on the screen. In particular, characters typed in command mode must not be displayed, whereas characters typed in insert mode must be displayed. This modes are application-specific and neither the terminal nor the terminal driver could know if a given typed character should be displayed or not. So, in these cases, it must be the application that controls the display of user-typed characters.

First of all, are these assumptions correct?

Now to the question. The terminal understands and interprets certain control characters and escape sequences that can be sent from the computer to the terminal. Each of them has an associated control function (e.g. move the cursor on the terminal screen). When the terminal receives such a control character or escape sequence, it does not display it, but executes the associated control function. This stands in contrast to the display characters (non-control characters and not part of an escape sequence) which the terminal just displays on the screen when it receives them.

Control characters, escape sequences, and display characters can be intermixed in any way (there is only a single transmission line from the computer to the terminal anyway). All the control characters and escape sequences that the VT102 understands are explained in the Received Character Processing section of the VT102 user guide.

Control characters are ASCII control characters. The set of control characters understood by the VT10, including the associated control functions, is listed here.

Escape sequences are sequences of characters that start with a special "escape character". The escape sequences understood by the VT102 are the ANSI escape sequences, and they are described in the Escape and Control Sequences section of the VT102 user guide. They always start with the ESC character followed by some other characters.

Control functions associated with VT102 control characters and escape sequences include positioning the cursor on the screen, deleting text on the screen, and setting display attributes (like text colour or font style). This allows applications to control what the user sees on the terminal screen (for example, vi redraws the entire terminal screen when it is started).

Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?

The Transmitted Characters section of the VT102 user guide describes all the characters that can be generated with the keyboard. They include control characters and some escape sequences. Are all these characters always sent to the computer without interpretation by the terminal?

For example, if the user hits the ← cursor key, the VT102 user guide says here that this generates the ESC [ D escape sequence. This is the ANSI escape sequence to move the cursor one position back (see here). So, is this escape sequence still sent to the application rather than being interpreted by the terminal? And then the application interprets it and has to send something back to take an appropriate action on the terminal (probably the ESC [ D again)?

Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?

EDIT

This is a diagram of the VT102 in off-line mode (i.e. when not connected to a computer), see here:

enter image description here

This makes it obvious that in off-line mode anything typed on the keyboard is directly re-routed to the receiver, and thus probably treated as if it would come from the computer.

My question was if in on-line mode (see diagram above) any control characters pressed on the keyboard are directly interpreted by the terminal rather than being sent to the computer?

Improve this question
6
  • 3
    Does anyone else remember when CSI was Control Sequence Introducer ( <esc>[ ), not Crime Scene Investigation? ... {sigh} I was a nerd too soon.
    – RichF
    Jan 20, 2019 at 20:25
  • 2
    Indeed. And all my VMS screen-updatey code used the 8-bit CSI (0x9B) rather than ESC [ when the terminal would support it. When you're optimizing for minimal character output on a slow async line, every octet counts.
    – another-dave
    Jan 20, 2019 at 21:55
  • It's worth noting in passing that a large number of intermediaries such as modems could be put into a loopback mode that would produce the same effect as local mode.
    – Walter Mitty
    Jan 21, 2019 at 1:22
  • There was also the paper-clip method of terminal testing: Bend a paper clip and put one end in pin 2 and the other in pin 3 to effectively create a local echo. Depending on the terminal & serial port configuration, additional paper clips may be required for hardware handshaking.
    – manassehkatz-Moving 2 Codidact
    Jan 21, 2019 at 1:35
  • 4
    Clippy: "I see you're trying to improvise a loopback connector. Can I .... wait, wait, what are you doing? Put me down! Ow, that hurts!"
    – another-dave
    Jan 21, 2019 at 2:30

4 Answers 4

Reset to default
6

Well, as usual with complex matter the answer is a mixture of Yes/If.

First of all, are these assumptions correct?

Yes, the assumptions stated are perfect good and correct. In general. In detail there can be diversions, most depending on line characteristics (like blocking and error correcting modems), and ways the computer/its OS is designed.

Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?

Yes, there is. And you presented already all parts necessary.

In

  • Off-Line mode (SETUP-4-SETUP), as well as
  • Local mode

every key press is right away handed to the receive function and interpreted. THat way one can try out whatever function combination needed without much software tools. Well, at least that's the way we did it to check functions and parameters when debugging :))

Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?

No. None at all. Wouldn't make much sense anyway. Either output displayed (characters and operations) is controlled by the host, or the host just interpretes the input, assuming everything the user does is legal anyway - or doesn't care what's displayed anyway.

Especially the later may seem strange, but it was quite handy back then to keep programs simple. Why care for stuff a sane user wouldn't do anyway.

Improve this answer
11
  • Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
    – weibeld
    Jan 20, 2019 at 20:22
  • Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
    – grahamj42
    Jan 20, 2019 at 21:36
  • @weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
    – Raffzahn
    Jan 20, 2019 at 22:42
  • 1
    @Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
    – weibeld
    Jan 20, 2019 at 23:20
  • 1
    @Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can type ESC on the keyboard and, for example, only one minute later [, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.
    – weibeld
    Jan 22, 2019 at 21:14
2

Short answer is yes.

https://www.pcjs.org/devices/pc8080/machine/vt100/ has a vt100 emulator. Once you've selected the "emulator" screen press:

F9 - Enter setup

4 - Toggle local/online to local (check the "LED" at the top)

F9 - Leave setup to change into local echo mode, then type away....

Improve this answer
3
  • Great simulation. Is there already a way to simulate connecting to a computer?
    – weibeld
    Jan 24, 2019 at 13:15
  • pcjs.org/devices/pdp11/machine/1170/vt100 is a pdp11 with vt100 and there is also a version where it's connected to an IBM AT. For the AT you can try booting "PC DOS 7.00 (1.44M boot)" then type "mode com2 baud=9000 parity=n" followed by "ctty com2" which will attach the vt100 to the console in/out.
    – PeterI
    Jan 24, 2019 at 14:35
  • For the official doco, see §2.3.1 of EK-VT520-RM-A01.
    – JdeBP
    Jan 25, 2019 at 18:42
2

Originally, the escape character was used to initiate multi-character sequences when it was necessary to support more functions than could be accommodated in 31 active control characters (codes 0x00 and 0x7F were reserved as padding characters that would be ignored). Because some usages would require transmitting that character a lot, a key for transmitting that character was placed at a reasonably convenient spot on the keyboard.

Somewhat later, it was discovered that it was useful to have a reasonably-convenient key that would allow a user to "escape" from an operation, and when using interactive applications that didn't need to use the escape character for those other purposes, the escape key was handy for that.

Unfortunately, these two usages sometimes collide, with terminals sending a sequence like esc-leftbracket-A when a cursor-up key is pressed, but with some applications wanting to use escape as a directly-functional key. There are two ways this can be handled:

  1. Some terminals can be configured so that they key marked Esc will actually send a unique sequence of characters, so an application that detects that can know that escape was pushed. On some such terminals, control-leftbracket can be used to send "just" an escape character should the need arise.

  2. Some applications will wait briefly after they receive an escape character to see if it is followed immediately by something else. This approach is quite common and is used by editors like "vi", but is unfortunately unreliable. If a user happens to hit escape to exit insert mode and then starts typing other commands but the application gets momentarily waylaid before it can process the escape, vi might attempt to process some portion of the following commands as an escape sequence (which might in turn disastrously affect the meaning of the succeeding keystrokes). If the user is communicating over a TCP connection which manages to send the escape character from a cursor-right command before a momentary communications hiccup, the application might receive the escape, decide it was "just" the escape key, receive the left bracket, and then receive a "D", potentially leading to major confusion.

For applications that interface to a keyboard without having to go through an octet stream, there may be superior ways of handling keyboard input. Under MS-DOS, for example, the "get keystroke" function reports both the ASCII character and the identity of the physical button that was pushed to produce it. This allows for a much wider and more useful range of keystrokes than would be possible using a mere octet stream, but not all operating systems support such things.

Improve this answer
4
  • Interesting, indeed, many ASCII control characters have a double meaning. One is interpreted by the terminal when it receives it from the host as a terminal control code (the original meaning from teletype times). And the other is interpreted by the TTY driver or application on the host when it receives it from the keyboard. For example ETX (0x03) is a terminal control code meaning "end of text", but when it is pressed on the keyboard (Ctrl-C), the TTY driver on the host interprets it as "interrupt the foreground process". These two meanings usually have nothing to do with each other.
    – weibeld
    Jan 24, 2019 at 21:20
  • Could you manage to manually produce this behaviour in vi, for example typing ESC very quickly followed by [?
    – weibeld
    Jan 24, 2019 at 21:22
  • 1
    @weibeld: Control-D is an even more interesting example. It doesn't actually mean "eof" even in Unix, but instead it forces a blocking input request to proceed with whatever input has been typed up to that point. A blocking input request normally wouldn't fail to yield any bytes except when it has reached the end of file, so typing control-D with no bytes pending is treated as an EOF, but the control-D isn't seen as part of the input stream.
    – supercat
    Jan 24, 2019 at 22:29
  • 1
    Exactly, it's also described like this in "The Linux Programming Interface": "EOF is the canonical mode end-of-file character (usually Control-D). Entering this character at the beginning of a line causes an end-of-file condition to be detected by a process reading from the terminal (i.e., read() returns 0). If typed anywhere other than the initial character of a line, then this character simply causes read() to complete immediately, returning the characters so far input in the line. In both cases, the EOF character itself is not passed to the reading process." (Section 62.4)
    – weibeld
    Jan 24, 2019 at 23:15
0

An ESC character can be represented by the Ctrl-[ key combination. Thus to move one position right you press Ctrl+[, then [ and then C.

Further behavior will depend on where characters go. If they go to remote computer, then that computer will process characters and reply back (e.g. echo) with respective command back to your terminal screen.

And I am sure there's a loopback mode when you type characters and terminal shows them on your terminal's screen.

Improve this answer

You must log in to answer this question.

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