\documentstyle[a4,12pt]{article}
\begin{document}
\author{Hamish Dewar}
\title{Video Terminal Interface}
\maketitle
\parskip .1 in
\setcounter{secnumdepth}{10}
\parindent 0in

\section{Preamble}
Standard Video Terminal Interface - Hamish Dewar. Jan 1983 Revised Feb 84
HELP file derived from printed document - still in preparation.

\section{Scope}

The Video Terminal Interface is a software interface designed
to make it possible to handle video terminals in a
high-level and general-purpose fashion.
The objective is to simplify the task of writing programs
which make some use of the special capabilities of such terminals.
The main aims the approach tries to achieve are:

\hspace*{0.8 in} providing a high-level interface;
\\ \hspace*{0.8 in} masking differences among video terminals;
\\ \hspace*{0.8 in} adapting to differences in types of communication connection;
\\ \hspace*{0.8 in} providing the same interface on a number of operating systems;
\\ \hspace*{0.8 in} keeping the number of individual functions manageable.

The extent to which these advantages are realised in practice depends
quite heavily on the way in which the interface is implemented, and, in
particular, the facilities which are available from different
operating systems and communication networks. At present, implementations
have been produced for 2900 EMAS using ERCC TCPs,
and for VAX/VMS and the EUCSD APM.
In some cases, implementation may be facilitated by making use of a lower-level general-purpose
video handling package such as the Unix TERMCAP or VMS SCRIFTY.

The scope of the specification has been deliberately restricted
to a small set of primitives which match the hardware capability of a
reasonable variety of conventional video terminals and which can be implemented
fairly efficiently in terms of network and host resources.
It is not intended as a basis for the kind of approach required
on more advanced machines with general graphical facilities,
where the user may assign
arbitrary parts of the screen of a video device to inspect arbitrary data
structures within processes in flexible and selectable ways, without
requiring the programs being executed
by these processes to make any special provision to enable such inspection.


\section{Frames}

The package interprets all video related operations in the context
of a particular selected region of the screen termed a frame.
The inclusion of multiple frames in the specification does not pre-suppose a
full capability for window management
in the implementation, but reflects the desirability in writing programs of
avoiding the assumption that the whole screen is available,
or that its dimensions are known.

The package allows for the \%definition of a number of frames,
in terms of position and size, and for the \%selection of one among
those which have been defined as the current frame, that is, the one
to be used in subsequent video operations until another is selected.
Frame selection applies to both input and output.

Each frame has an associated set of attributes and a current status.


\section{Basic Operations}

The package defines procedures to effect the following five basic
video operations:


\hspace*{0.7 in} Set the cursor to a particular row and column within the frame
\\ \hspace*{0.7 in} Clear the whole of the current frame
\\ \hspace*{0.7 in} Clear from the current cursor position to the end of the current row
\\ \hspace*{0.7 in} Scroll (up or down) a group of rows within the frame
\\ \hspace*{0.7 in} Select video attributes (reverse, dimmed, etc) for subsequent operations using this frame

The implementation of the package has the task of giving effect to these
operations on the particular terminal used, by means of the appropriate control
sequences. User programs do not require to take account of the differences
in these control sequences from terminal to terminal.

The implementation is expected to optimise a number of the operations
in appropriate circumstances.
For example, it will be noted that there is no primitive
to clear the whole screen, just to clear a frame. However, a frame may be
co-extensive with the full screen, in which case clearing it is tantamount
to clearing the screen, and the implementation may well use a hardware
capability to achieve this.

All implementations are expected to adopt delayed and optimised
cursor movement strategies.

However, it is recognised that it may be impossible or unsatisfactory
to implement all of the operations in full generality in cases where
the physical terminal lacks the necessary capability, and a soft
emulation cannot reasonably be provided.
For example, the scroll function is not guaranteed to be
implemented in the case of terminals which do not support part-screen scrolling,
or if the current frame does not extend across the whole screen.
Full soft emulation requires that a complete screen image (at least) be
maintained by software, and this may be too costly in space or time.
Apart from the resource required,
the effect achieved may not be a satisfactory substitute for the one
desired, and it may be more sensible for application programs to take different
courses of action in the light of the capability available.

Accordingly, the interface defines a number of capability attributes
for each frame,
such as the ability to scroll,
and programs may enquire about these on a dynamic basis.


\section{Integration with General Input/Output}

In addition to the explicit video handling procedures,
the interface pre-supposes that ordinary input/output
operations, carried out by means of standard language statements,
are treated appropriately when they involve the video terminal.
This avoids the need to define a complete set of additional transput
statements (covering characters, integers, reals, strings, and so on)
for this one device type, contrary to the general principle of
device-independent I/O procedures.

In a few cases, where it is impossible to integrate the video handling
into the standard input/output, or to intercept the standard procedures,
it may be necessary to introduce separate input/output routines, but
this is distinctly second-rate.


\section{Components of the Package}

The package is most conveniently presented in terms
of an external library of variables and procedures, so that the
detailed definition is a set of data and procedural declarations.
In the following sections, the system implementation language IMP is used for
these declarations.
When implemented for languages which lack the capability to have external
references to data, it will be
necessary to add further procedures instead.

\%recordformat FRAMEINFO(\%byte TOP, ROWS, LEFT, COLS, ROW, COL, FUN, MODE)


This is used to characterise individual frames.
The components TOP, ROWS, LEFT, and COLS define the size and
position of the frame on the screen.

TOP is the absolute row number of the topmost row in the frame counting
from zero at the top of the physical screen.

ROWS is the number of lines in the frame.
LEFT is the absolute column number of the leftmost column in the frame
counting from zero at the left of the screen.
COLS is the number of columns across the frame.

ROW and COL identify the current position in the frame, with (0,0)
corresponding to the top left corner of the frame. (Thus the absolute
screen position is given by TOP+ROW and LEFT+COL).

FUN is a set of indicator flags specifying the functionality
of the frame in terms of the pre-defined values REVERSE, INTENSE,
BLINK, UNDERLINE, FULLSCROLL and ANYSCROLL. The first four of these
indicate whether arbitrary characters in the frame may be written
with the attribute indicated.
The last two are concerned with the ability of the frame to perform
(a) a full scroll upwards and (b) a scroll of an arbitrary group of
adjacent rows within the frame either up or down.
Scrolling is understood to imply a 'shift' operation with rows
dropping irretrievably off one end and blank rows introduced at
the other. In the absence of data storage associated with the frames,
these flags simply reflect hardware capability.

MODE represents the currently active attribute selection, in terms
of the pre-defined values REVERSE, INTENSE, BLINK,
UNDERLINE, AUTOSCROLL and FREEZE.
These apply to data transferred through the frame. The first four
select the 'shade' to be used to write data to the screen;
some 'best endeavour' action is taken for an attribute not specified
in FUN. The flag AUTOSCROLL selects whether automatic scrolling of
the frame is to take place when a newline is performed on the bottom
line; this pre-supposes FULLSCROLL in FUN. The flag FREEZE determines
whether output to the frame is to be suspended after reaching the bottom
of the frame until the user un-freezes it by hitting a key on the keyboard.

\%routine SET VIDEO MODE(\%integer attributes)

The procedure SET VIDEO MODE is used to establish the mode of
operation which will apply to subsequent terminal input.
The attributes are specified as the sum of the desired individual
attribute mnemonics (since IMP lacks sets and enumerated types).
The significance of the individual attributes is as follows:
\small\tt \begin{verbatim}        SINGLE          single character input mode (no line buffering)
        CONTROLTERM     treat any control character as terminator for input
        NOECHO          disable automatic echoing of all input
        NODELECHO       disable automatic treatment of DEL
        PASSDEL         pass DEL through
        NOTERMECHO      disable automatic echoing of input terminating character
        LEAVECONTROLS   do not map all controls to NL (LF)
        LEAVERETURN     do not map RETURN to NL (LF)
        LEAVELF         do not map LF to RETURN
        SPECIALPAD      put terminal in special pad mode
\end{verbatim}\rm  \normalsize 
In general, a call will be required to SET VIDEO MODE to initialise
the video handling package and other facilities will not operate
unless this is done.

\hspace*{0.3 in} \%record VDU
\\ \hspace*{0.3 in} \%record WIN

These pre-defined frame records identify the full screen (VDU) and the
currently selected frame (WIN) respectively.

VDU\_TOP is zero and VDU\_ROWS gives the number of rows on the physical screen;
VDU\_LEFT is zero and VDU\_COLS gives the number of columns on the physical screen;

VDU\_FUN defines the functionality of the actual terminal.

For a typical terminal,
\\ \hspace*{0.3 in} VDU\_ROWS would be 24 and VDU\_COLS would be 80;
\\ \hspace*{0.3 in} VDU\_FUN would surely include FULLSCROLL and might or might not include AUTOSCROLL.

\%routine AT(\%integer row, col)

Sets the active position of the currently selected frame according
to the parameters ROW and COL.
This is not acted upon until data transfer (or CLEAR LINE)
requires it; that is, this is simply an assignment to the ROW
and COL components of the relevant record.

\%routine GOTOXY(\%integer col, row)

This is a variant of AT for those who prefer to present the column
(x co-ordinate) first.

\%routine CLEAR FRAME

Causes the whole of the current frame to be cleared. The current
position is not relevant and does not change.

\%routine CLEAR LINE

Causes the part of the row to the right of the current position
to be cleared to blanks.
The current position does not change.

\%routine SCROLL(\%integer first, last, n)

Performs a scroll of the group of rows within the current frame
identified by FIRST and LAST. N specifies the number
of scrolls; a negative value of N implies reverse scrolling.
The current position is not relevant and does not change.

\%routine SET MODE(\%integer m)

Sets current frame scrolling mode (subset of NOSCROLL, FREEZE)

\%routine SET SHADE(\%integer s)

Sets current frame 'shade' attributes
(subset of INTENSE, REVERSE, UNDERLINE, BLINK)


The following four procedures represent one approach to the management
of multiple frames, in which the basic dimensions of a frame are
established by imposing them on the currently selected frame, and
non-current frames are held on a stack. This is not sufficiently general,
and a more satisfactory approach would integrate frames with the
standard mechanism for stream selection.


\%routine SET FRAME(\%integer top, rows, left, cols)

Imposes the position and dimensions specified on the currently selected frame
in place of its existing properties.

\%routine PUSH FRAME

\%routine POP FRAME

\%routine SWOP FRAME

These procedures allow the current frame to be saved on, restored from,
and swopped to,
a push-down stack. Current status is preserved along with the persistent
attributes.

\%routine DEFINE VIDEO(\%integer CODE)

This is an ad hoc procedure used in Edinburgh University implementations
to define the terminal type being used.
The procedure interprets the parameter CODE as a value in the ERCC
enumeration of terminal types and uses it to set up information
used by the package for driving the terminal.


\section{Data output}

In all cases in which output actually takes place,
the cursor is first positioned at the corresponding screen
position if it is not already there, and the appropriate shade
is selected if it is not already selected.

\small\tt \begin{verbatim}1.    For a printing character (including space) not following ESC (Escape):

1.1   If the current position determined by ROW and COL lies within the
frame, the character is output and COL is incremented by one.

1.2   If ROW is greater than or equal to ROWS, or COL is greater than
or equal to COLS, the character is not output but COL is incremented (max 255).

2.    For ESC and any single character immediately following ESC,
the character is output but COL is not altered.

3.    For any control character other than NL, RT and BS, the character
is output but COL is not altered.

4.    For RT, COL is set to zero.

5.    For BS, COL is decremented by one unless it is zero.

6.    For NL (newline):

6.1   If ROW lies within the current frame, the remainder of the
row to the right of the current position is cleared. Then:

6.1.1 If not at the bottom of the frame (ROW not equal to ROWS-1),
ROW is incremented by one and COL is set to zero

6.1.2 If at the bottom of the frame, a pause is induced if FREEZE
is selected and a scroll is performed if AUTOSCROLL is selected
(and scrolling is possible); ROW is not changed and COL is set
to zero.

6.2   If ROW lies outside the current frame, no action is taken except
that ROW is incremented by one (max 255) and COL is set to zero.

7.    A character code in the range 128-255 designates
a printing character from a special graphical set. It is recommended that the
encoding of
the low order 7 bits should be interpreted according to the systematic
conventions for line-drawing and block-drawing characters found
on the ICL KDS7632 terminal among others. Where possible, it should be
mapped to the nearest equivalent on other terminals.
The update action of paragraph 1 applies.
\end{verbatim}\rm  \normalsize 

Note that the treatment of RT and BS is included largely for pre-video
programs; their effect should properly be achieved by a call on
the routine AT.

The treatment of ESC + one character is included to provide a
defined effect in the case that video operations not supported
by the package are achieved by explicit output
of control sequences.


\section{Data input}

The SET VIDEO MODE procedure allows a number of different modes
to be established for data input as a combination of individual
attributes. Not all combinations are mutually compatible, and not
all implementations will support all those that are.
In principle, the effect on the screen and the current frame status
of each input character should be nil if the character is not echoed
and otherwise the same as the effect of outputting the same
character through the output routines.
There are certain difficulties even in the principle of this definition
-- there is an argument that a significant character should update
frame status even if it is not echoed, for example.
Implementation considerations also introduce compromises in practice.
These arise from the fact that, particularly in a network environment,
the total effect is achieved by operations which are distributed
over a number of different processes and devices, and there may be
compelling reasons for utilising the capabilities that are available
from these even if they do not exactly match the defined functions.

For these reasons, the description of treatment of input given below
must be regarded as partial and indicative, rather than definitive.

Three modes can be
isolated as significant levels, likely to be available on most implementations:

TT mode: printing characters echoed and line-buffered up to
RETURN as (only sensible) terminator -- terminator also
echoed as newline;

Screen mode: printing characters echoed and line-buffered
up to any ASCII control character or control sequence as
terminator -- terminator not echoed;

Raw mode: single character non-echoed operation.


In terms of the package, the treatment of a request for character input is as
follows:

\small\tt \begin{verbatim}1.    If no data is available, the cursor is positioned and shade
selected as for output and a unit of input is obtained from the terminal
(see above). Then (and otherwise)
the next character from the available unit of input is extracted:

1.1   If the character is a printing character it is returned and
COL is incremented by one (max 255).

1.2   If the character is a control character other than ESC, it
is returned and COL is unchanged

1.3   If the character is ESC, a two or three character
control sequence is assembled and
encoded as a single character value in the range 128-255. These values
have no meaning to the package and are not standardised.
For a 2-character control sequence ESC K1, the value is K1+128;
for a 3-character sequence ESC K1 K2 (K1='?' or 'O'), the value
is (K2!!64)+128 ('!!' standing for exclusive or). This encoding distinguishes
(a) all 2-character sequences and (b) all ANSII-standard 2- and 3-character
sequences.
\end{verbatim}\rm  \normalsize 

\section{Prompts}

It may be desirable to provide a mechanism which allows prompting for
input, in the interests of compatibility with conventional sequential
input. This is a standing order for output of a string, conditional
upon input being derived interactively. It should not be conditional
on whether the user has typed ahead or not, it being axiomatic for
proper operation of screen-oriented transput that the correct
(and deterministic) sequencing of input and output should be
preserved.

When the full potential of screen-oriented operation is being
exploited, the concept of the iterated prompt becomes somewhat
irrelevant. The 'memory' of visual cues is on the screen itself,
to be selected by cursor positioning.


\section{Cost}

The code which requires to be added to the basic input/output
run-time support system to provide the main features of the interface
is of the order of one or two kilobytes,
and, with care, it should be possible to make it acceptably (ie very) efficient.
It is important to bear in mind that video output involves much higher
data rates than does hard-copy terminal output, though input volume remains
low.
The \%own data requirement for the virtual video aspect is about 40 bytes
for defining cursor addressing and the like, 64 bytes for driving
shade selection, and 128 bytes for mapping graphical characters.
The virtual screen aspect requires about 20 bytes for scalars
and n*8 bytes for frame records.


\vspace{.75in} view:vti printed on 16/02/89 at 20.45

\newpage
\tableofcontents
\end{document}