VT100

Preface

To begin with, all of the above call themselfes "ANSI" emulations, which makes this notion pretty vage. "ANSI" referes here to the American National Standards Institute's documents X3.41-1974 and X3.64-1977. DEC partially implemented this standart in their VT100 terminal, with some additions. The VT102 is a later extention of that. Both the Linux console and the XTerm emulation implement most of VT102, with some additions. MS stepped in later and produced another ANSI emulation, ansi.sys, for their OS, which became of some relevance in BBS style telecommunication programs. One can view this as a small subset of the VT100 emulation, with some additions, of cause. This situation is further confused by the fact, that often many versions of the above terminals and emulations are out, one able to do a little more or less then the other.

I'm working towards a close integration of the konsole's source code with this document, but it is still a long way to go.

Currently, the body of this document is mainly a concept data base, that referes to the VT100 component of the emulation. Though the codes accepted by konsole are now clearly indicated, a comparison to the xterm and Linux console emulation is missing.

The konsole emulation sources is not linked closely with it's documentation, and, also accurate at the time of writing, it can still fall slightly appart, though the codes accepted and produced by konsole should be properly listed. Work is currently in progress to fix this issue.

Notes & todos

• Include complete reference on keyboard material.
• Check for explaination of out-of-bound values.
• Include VT52, VT102, XTERM, LINUX-console codes
• Make the whole document more concept oriented
• See the section Method of description, below
• Derive some summarizing lists.

Introduction

In a traditional UNIX installation a single machine (host) served several users by means of terminals attached to this host by a serial cable. These terminals (end points) where specialized devices, either regular ttys (printer with keyboard) or later more sophisticated things with cathode ray tubes.

      +-----------+                      +------------+
      |           |                      |            |
      |           | -------------------> |            |--> Printer and/or Display
      |   UNIX    |    bi-directional    |  Terminal  |
      |   host    |    serial line       |   Device   |
      |           | <------------------- |            |<-- Keyboard and Mouse
      |           |                      |            |
      +-----------+                      +------------+
  

Today, hardware has become so cheap, that each single user could be provided with a complete host/display combination for the former price of a terminal.

Additional, and here we come to the X in the emulation, display devices have become graphical while the original terminal where only able to show characters but not graphics.

To allow programs designed for the original configuration to be used in the contemporary setup, "terminal emulations" where invented. In these emulations, the whole original setup is simulated.

The serial cable is folded into the operating system as a sort of loop back device, and a program, the terminal emulation, uses modern means of graphical user interfaces to behave like an earlier terminal. To complete the picture, the host in the diagram is replaced by the application that runs in the emulation (typically a shell or an old editor). So, terminal emulations are in fact interfaces to character oriented applications.

This document describes the implementations of a program named "konsole", which is such an X terminal emulation. Since konsole is distributed under the GPL, meaning that it's source code is available to whoever likes to hack on it, the program would be incomplete without a proper introduction into the code and it's concepts. Thus, this text is to complement the program and the source with the remaining informations to make a complete product.

A first refinement

Before we can come to the actual implementation, quite some notions have to be introduced. We have to get us an idea what a terminal emulation does in more detail.

To this end, a simple model of the terminal and it's operation is given, which is later extended and refined as we come deeper into matter and implementation.

At some level conception, a terminal can be described as a (abstract) data model. This means it has some type of state together with operations on that data type. These operations are somehow encoded to be passed over the serial line.

The concrete model is often loosely named the "emulation", the specific encoding chosen, the "protocol".

There are two principle models in use. The first, stream like one, which is related to a tty, consideres the terminal as an indefinit long and wide sheet of paper on which a printer head types the characters that come in over the line. Typical examples are shell scripts, make and other programs producing sequential protocols of their activity. Their basic data type is a list of list of characters.

The second principle model is used by applications written especially for crt devices, so called full screen applications. These treat the terminal as a matrix of characters where each position can be individually addressed and written to. Typical representatives are full screen editors like vi and emacs, file managers like mc and mail readers like mutt.

Though the second model is newer, it's age does not imply a preference. To the contrary, both models have a right for their own and are both to be supported. The first model is fully expressed within konsole in form of it's ref:history buffer.

Note, that although the second model definitely build on the first one in almost any respect, it cannot fully express it, since it introduces a finite line length, while the first model works with indefinite lines.

Since application with both view of things are typically run within the same session, some effort has been made within konsole to maintain both ideas simultaniously, but only with limited success so far.

In both models, the notion of a current position (historically a printer's head, nowadays visualized by a cursor) is present. "Printing" a charater at the current position and advancing the head together with the starting a new line are the most fundamental operations of the emulation.

The full screen model basically adds the possibility to position the cursor and to overwrite and clear the screen.

A plethora of additional (more or less usefull) commands are then added on this by every specific emulation, see below for the awful details.

Parts of the model

All the following in this section is an outline.

Parts of the terminal description

• State
  This is mainly the screen, the cursor (including it's graphical state) and some hidden mode variables. Note that the state cannot be investigated by the attached host.
• Interface
  That's what goes over the wire. Beside being related to objects, this appears so closely related to contemporal process communication, that it might be discussed in likely terms.
  We have information flowing in both directions. On could destinguist between:
• Commands
  These are "calls" of the terminals interface by the host which cause some change of the terminals state, but do not end in a response.
• Requests
  These are "calls" of the terminals interface by the host which do not cause any change of the terminals state, but end in a response of the terminal. Clearly, requests are somehow used to investigate the state of the terminal.
• Events
  These are signals from the terminal caused by the user affecting the mouse or keyboard to the host.
• Replys
  These are send by the terminal as a result of a Request from the hosts.
• Encoding/Decoding

Control Sequences

Refering both to their origin and form, one can group the overall encoding schemes as follows:

Name	Pattern	Scope	Comment
Printable Ascii Characters	32..126	ASCII ECMA	This is the most original pattern of all. The characters to be displayed are passed over the chanel and are interpreted by the terminal (emulation) as instructions to display the corresponding glyph of the ascii character set. Contempory emulations include the upper half (128..255) of the extentions to the national ascii character sets, also.
Ascii Control Characters	0..26,28..31,127	ASCII ECMA	Ascii defines some non-printable, but format effecting characters, too. Depending on the emulation, at least some of them are given a meaning. The typically implemented ones are those that are handled by a teletype like device.
Simple Escape Sequence	ESC C	ECMA	These sequences are made up from an ESC character followed by exactly one other character in the range ???..???.
CSI Sequence	ESC [ Parameters {I} C	ECMA
The remaining codes are nonstandard but traditionalized hacks.
DEC hacks	ESC C D	VT100
XTERM hacks	ESC ] Pn ; text BEL	XTERM
VT52 uses a different (incompatible) set of escape codes. VT100 includes the VT52 emulation as a mode.
Simple Escape Sequence	ESC C	VT52
Complex Escape Sequence	ESC Y X Y	VT52

More on Control Sequences

Control Characters

Control characters (codes 0x00 - 0x1f inclusive) are specifically excluded from the control sequence syntax, but may be embedded within a control sequence. Embedded control characters are executed as soon as they are encountered by a VT100. The processing of the control sequence then continues with the next character recieved. The exceptions are: if the ESC character occurs, the current control sequence is aborted, and a new one commences beginning with the ESC just recieved. If the character CAN (0x0c) or the character SUB (0x0e) occurs, the current control sequence is aborted. The ability to embed control characters allows the synchronization characters XON and XOFF to be interpreted properly without affecting the control sequence.

CSI Sequences

Control Sequence Introducer (CSI):

An escape sequence that provides supplementary controls and is itself a prefix affecting the interpretation of a limited number of contiguous characters. In the VT100, the CSI is: <ESC>[

Parameter:

1. A string of zero or more decimal characters which represent a single value. Leading zeros are ignored. The decimal characters have a range of 0 (060) to 9 (071).
2. The value so represented.

Numeric Parameter:

A parameter that represents a number, designated by Pn.

Selective Parameter:

A parameter that selects a subfunction from a specified set of subfunctions, designated by Ps. In general, a control sequence with more than one selective parameter causes the same effect as several control sequences, each with one selective parameter, e.g., CSI Psa; Psb; Psc F is identical to CSI Psa F CSI Psb F CSI Psc F.

Parameter String:

A string of parameters separated by a semicolon.

Default:

A function-dependent value that is assumed when no explicit value, or a value of 0, is specified.

Final character:

A character whose bit combination terminates an escape or control sequence.

EXAMPLE: Control sequence to turn off all character attributes, then turn on underscore and blink attributes (SGR).

                      Delimiters
                            / \       
                           /   \       
                           |   |
                          \ / \ /
  Sequence:       <ESC>[ 0 ; 4 ; 5 m
                  ^^^^^^ ^   ^   ^ ^
                  |||||| |   |   | |
                  \||||/  \  |  /  +------Final character
                   \||/    \ | /
                   CSI   Selective
                         Parameters
  

     033 0133 060 073 064 073 065 0155
    <ESC>   [   0   ;   4   ;   5    m
  

Alternate sequences which will accomplish the same thing:

• <ESC>[;4;m
• <ESC>[m
<ESC>[4m
<ESC>[5m
• <ESC>[0;04;005m

DEC hacks

These form two groups of commands.

In one first the first character is a hash (#) and the following a digit. This command group is used to denote VT100 specific instructions and can safely be sonsidered to be obsolete. See DECALN, DECDHLB, DECDHLT, DECDWL and DECSWL.

The second one is used to specify character set mappings (see SCS). A CSI instruction to do this is specified in ECMA, and this should be used as a replacement.

XTERM hacks

Host to Terminal (Instructions by Code)

Host to Terminal (Instructions by Group)

• Host to Terminal (Commands,Requests)
  • Commands
    • Character Display Operation
    • Rendition related status
    • Cursor
    • Cursor related status
    • Edit
    • Miscellaneous
    • General mode setting
    • Miscellaneous status
    • VT52
    • Not implemented
    • Ignored
  • Requests
• Terminal to Host (Replies, Events)
  • Replies
  • Events
• Modes
  • Modes

Terminal to Host

Modes

Appendix A - Notion Details

All of the following control sequences are transmitted from the Host to VT100 unless otherwise noted. All of the control sequences are a subset of those defined in ANSI X 3.64 1977 and ANSI X 3.41 1974.

The following text conforms to these formatting conventions:

• Individual character literals are set in bold face. Ascii representation is used throughout, so ESC means the binary value of 27 and [ a value of 91.

• Parameters are indicated by italic type faces.
• Parameter types usually are indicated as one of:

  Pn	A string of digits representing a numerical value.
  Ps	A character that selects an item from a list.
  a-z	Any lowercase sequence of one or more characters represent a value to be entered (as in Pn), and the name in the will be referred to in explanatory text.

• Spaces are used only to improve readability, they do not occure in the control sequences unless otherwise indicated.

The following attributes below have the following meaning:

• VT100 - This code is known to VT100.
• ANSI - This code is defined by ANSI.
• DEC - This code is DEC private.
• Command - Sent from host to the terminal. FIXME:add Inquiery.
• Reply - Sent from terminal to the host (as response to an Inquiery).
• Event - Sent from terminal to the host (caused by a user activity).
• Mode - The entry is a mode.

On VT100

The VT100 is compatible with both the previous Digital standard and ANSI standards. Customers may use existing Digital software designed around the VT52 or new VT100 software. The VT100 has a "VT52 compatible" mode in which the VT100 responds to control sequences like a VT52. In this mode, most of the new VT100 features cannot be used.

Throughout this document references will be made to "VT52 mode" or "ANSI mode". These two terms are used to indicate the VT100's software compatibility.

NOTE: The ANSI standards allow the manufacturer flexibility in implementing each function. This document describes how the VT100 will respond to the implemented ANSI central function.

Modes

ANSI Specified Modes

DEC Private Modes

The following modes, which are specified in the ANSI standard, may be considered to be permanently set, permanently reset, or not applicable, as noted.

Mnemonic	Function	State
CRM	Control Representation	Reset
EBM	Editing Boundary	Reset
ERM	Erasure	Set
FEAM	Format Effector Action	Reset
FETM	Format Effector Transfer	Reset
GATM	Guarded Area Transfer	NA
HEM	Horizontal Editing	NA
IRM	Insertion-replacement	Reset
KAM	Keyboard Action	Reset
MATM	Multiple area transfer	NA
PUM	Positioning Unit	Reset
SATM	Selected Area Transfer	NA
SRTM	Status Reporting Transfer	Reset
TSM	Tabulation Stop	Reset
TTM	Transfer Termination	NA
VEM	Vertical Editing	NA

Keyboard Codes

Special Graphics Characters