NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Network Working Group Richard
Request for Comments 746 MIT-
NIC 43976 17 March 1978

The SUPDUP Graphics

... extends SUPDUP to permit the display of drawings on the screen
the terminal, as well as text. We refer constantly to
documentation of the SUPDUP protocol, described by Crispin in RFC 734
"SUPDUP Protocol".

Since this extension has never been implemented, it presumably
some problems. It is being published to ask for suggestions, and
encourage someone to try to bring it up

The major accomplishments are these

* It is easy to do simple things

* Any program on the server host can at any time begin
pictures. No special preparations are needed

* No additional network connections are needed. Graphics
go through the normal text output connection

* It has nothing really to do with the network. It is
for use with locally connected intelligent display terminals
a terminal-independent manner, by programs which need not
whether they are being used locally or remotely. It can be
as the universal means of expression of graphics output,
whatever destination. Programs can be written to use it
non-network terminals, with little loss of convenience,
automatically be usable over the ARPA network

* Loss of output (due, perhaps, to a "silence" command typed
the user) does not leave the user host confused

* The terminal does not need to be able to remember the
"semantic" structure of the picture being displayed, but
the lines and points, or even just bits in a bit matrix

* The server host need not be able to invoke
terminal-dependent software to convert a standard language
one that a terminal can use. Instead, a standard language
defined which all programmable terminals can interpret easily
Major differences between terminals are catered to
conventions for including enough redundant information in
output stream that all types of terminals will have
necessary information available when it is needed, even if



-1-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



are not able to remember it in usable form from one command
another

Those interested in network graphics should read about the
Graphics System, whose fundamental purpose is the same, but
particular assumptions are very different (although it did inspire a
of the features of this proposal).













































-2-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



SUPDUP Initial Negotiation

One new optional variable, the SMARTS variable, is defined.
should follow the other variables sent by the SUPDUP user process
the SUPDUP server process. Bits and fields in the left half-word
this variable are given names starting with "%TQ". Bits and
in the right half are given names starting with "%TR". Not all
the SMARTS variable has to do with the graphics protocol, but most
it does. The %TQGRF bit should be 1 if the terminal
graphics output at all

Invoking the Graphics Protocol

Graphics mode is entered by a %TDGRF (octal 231) code in the
stream. Following characters in the range 0 - 177 are
according to the graphics protocol. Any character 200 or larger (
%TD code) leaves graphics mode, and then has its
interpretation. Thus, if the server forgets that the terminal
graphics mode, the terminal will not long remain confused

Once in graphics mode, the output stream should contain a sequence
graphics protocol commands, each followed by its arguments. A
as a command is a no-op. To leave graphics mode deliberately, it
best to use a %TDNOP




























-3-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Co-ordinates

Graphics mode uses a cursor position which is remembered from
graphics command to the next while in graphics mode. The
mode cursor is not the same one used by normal type-out:
protocol commands have no effect on the normal type-out cursor,
normal type-out has no effect on the graphics mode cursor.
addition, the graphics cursor's position is measured in dots
than in characters. The relationship between the two units (dots
and characters) is recorded by the %TQHGT and %TQWID fields of
SMARTS variable of the terminal, which contain the height and
in dots of the box occupied by a character. The size of the
in either dimension is assumed to be the length of a character
times the number of characters in that direction on the screen.
the screen is actually bigger than that, the excess is may or may
be part of the visible area; the program will not know that
exists, in any case

Each co-ordinate of the cursor position is a 14-bit signed number
where zero is at the center of the screen (if the screen dimension
an even number of dots, then the visible negative points extend
unit farther that the positive ones, in proper two's
fashion). Excessively large values of the co-ordinates will be
the screen, but are still meaningful

An alternate mode is defined, which some terminals may support,
which virtual co-ordinates are used. The specified co-ordinates
still 14-bit signed numbers, but instead of being in units
physical dots on the terminal, it is assumed that +4000 octal is
top of the screen or the right edge, while -4000 octal is the
of the screen or the left edge. The terminal is responsible
scaling these virtual co-ordinates into units of screen dots.
all terminals need have this capability; the %TQVIR bit in the
variable indicates that it exists. To use virtual co-ordinates,
server should send a %GOVIR; to use physical co-ordinates again,
should send a %GOPHY. These should be repeated at intervals, such
when graphics mode is entered, even though the terminal must
to remember the state of the switch anyway. This repetition is
that a loss of some output will not cause unbounded confusion

The virtual co-ordinates are based on a square. If the visible
on the terminal is not a square, then the standard virtual
should correspond to a square around the center of the screen,
the rest of the visible area should correspond to
co-ordinates just beyond the normally visible range

Graphics protocol commands take two types of cursor
arguments, absolute ones and relative ones. Commands that
address arguments generally have two forms, one for each type



-4-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



address. A relative address consists of two offsets, delta-X
delta-Y, from the old cursor position. Each offset is a 7-bit two'
complement number occupying one character. An absolute
consists of two co-ordinates, each 14 bits long, occupying
characters, each of which conveys 7 bits. The X co-ordinate
offset precedes the Y. Both types of address set the running
position which will be used by the next address, if it is relative
It is perfectly legitimate for parts of objects to go off the screen
What happens to them is not terribly important, as long as it is
disastrous, does not interfere with the reckoning of the
position, and does not cause later objects, drawn after the
moves back onto the screen, to be misdrawn

Whether a particular spot on the screen is specified with an
or a relative address is of no consequence. The sequence in
they are drawn is of no consequence. Each object is independent
all others, and exists at the place which was specified, in one
or other, by the command that created it. Relative addresses
provided for the sake of data compression. They are not an
to spare programs the need for the meagre intelligence required
convert between absolute and relative addresses; more
than that will surely be required for other aspects of the
protocol. Nor are relative addresses intended to cause
objects to relocate together if one is "moved" or erased.
are not expected to remember any relation between objects once
are drawn. Most will not be able to

Although the cursor position on entry to graphics mode remains
from the last exit, it is wise to reinitialize it with a %
command before any long transfer, to limit the effects of
output





















-5-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Commands

Commands to draw an object always have counterparts which erase
same object. On a bit matrix terminal, erasure and drawing
almost identical operations. On a display list terminal,
involves searching the display list for an object with the
characteristics and deleting it from the list. It is assumed
any terminal whose %TOERS bit is set can erase graphic objects

The commands to draw objects run from 100 to 137, while those
erase run in a parallel sequence from 140 to 177. Other sorts
operations have command codes below 100. Meanwhile, the 20 bit
the command code says which type of addresses are used as arguments
if the 20 bit is set, absolute addresses are used. Graphics
are given names starting with "%GO".

Graphics often uses characters. The %GODCH command is followed by
string of characters to be output, terminated by a zero.
characters must be single-position printing characters. On
terminals, this limits them to ASCII graphic characters.
with %TOSAI set in the TTYOPT variable allow all characters 0-177.
The characters are output at the current graphics cursor
(the lower left hand corner of the first character's rectangle
placed there), which is moved as the characters are drawn.
normal type-out cursor is not relevant and its position is
changed. The cursor position at which the characters are drawn
be in between the lines and columns used for normal type-out.
%GOECH command is similar to %GODCH but erases the
specified in it. To clear out a row of character positions on a
matrix terminal without having to respecify the text, a
command may be used

Example

The way to send a simple line drawing is this

%TDRST ;Reset all graphics modes
%TDGRF ;Enter graphics
%GOCLR ;Clear the screen
%GOMVA xx yy ;Set cursor
%GODLA xx yy ;Draw line from there
<< repeat last two commands for each line >>
%TDNOP ;Exit graphics









-6-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Graphics Input

The %TRGIN bit in the right half of the SMARTS variable
that the terminal can supply a graphic input in the form of a
position on request. Sending a %GOGIN command to the terminal
to read the cursor position. It should be followed by an
character that will be included in the reply, and serve to
the reply with the particular request for input that elicited it
The reply should have the form of a Top-Y character (code 4131),
followed by the reply code character as just described, followed
an absolute cursor position. Since Top-Y is not normally
as input, %GOGIN replies can be distinguished reliably from
input. Unsolicited graphic input should be sent using a Top-X
of a Top-Y, so that the program can distinguish them. Instead of
reply code, for which there is no need, the terminal should send
encoding of the buttons pressed by the user on his input device,
it has more than one

Sets

Terminals may define the concept of a "set" of objects. There are
to 200 different sets, each of which can contain arbitrarily
objects. At any time, one set is selected; objects drawn become
of that set, and objects erased are removed from it. Objects in
set other than the selected one cannot be erased without switching
the sets that contain them. A set can be made temporarily invisible
as a whole, without being erased or its contents forgotten; and
can then be made instantly visible again. Also, a whole set can
moved. A set has at all times a point identified as its "center",
and all objects in it are actually remembered relative to
center, which can be moved arbitrarily, thus moving all the
in the set at once. Before beginning to use a set, therefore,
should "move" its center to some absolute location. Set
motion can easily cause objects in the set to move off screen.
this happens, it does not matter what happens temporarily to
objects, but their "positions" must not be forgotten, so that
the set center motion will restore them to visibility in
previous positions. Sets are not easily implemented on bit
terminals, which should therefore ignore all set operations (except
for a degenerate interpretation in connection with blinking, if
is implemented). The %TQSET bit in the SMARTS variable of
terminal indicates that the terminal implements multiple sets
objects

On a terminal which supports multiple sets, the %GOCLR command
empty all sets and mark all sets "visible" (perform a %GOVIS on
one). So should a %TDCLR SUPDUP command. Thus, any program
starts by clearing the screen will not have to worry
initializing the states of all sets



-7-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Blinking

Some terminals have the ability to blink objects on the screen.
command %GOBNK meaning make the current set blink. All objects in
already begin blinking, and any new objects also blink. %GOVIS
%TOINV cancels the effect of a %GOBNK, making the objects of the
permanently visible or invisible. %TQBNK indicates that the
supports blinking on the screen

However, there is a problem: some intelligent bit matrix
may be able to implement blinking a few objects, if they are told
advance, before the objects are drawn. They will be unable
support arbitrary use of %GOBNK, however

The solution to the problem is a convention for the use of %
which, together with degenerate definitions for set operations,
it possible to give commands which reliably work on any
which supports blinking

On a terminal which sets %TQBNK but not %TQSET, %GOBNK is defined
cause objects which are drawn after it to be drawn blinking. %
cancels this, so following objects will be drawn unblinking. This
regardless of the argument to the %GOSET

Thus, the way for a program to work on all terminals with %TQBNK
whether they know about sets or not, is: to write a
picture, select some set other than your normal one (set 1 will do),
do %GOBNK, output the picture, and reselect set 0. The picture
blink, while you draw things in set 0. To draw more
objects, you must reselect set 1 and do another %GOBNK.
reselecting set 1 will not work on terminals which don't
support sets, since they don't remember that the blinking objects
"in set 1" and not "in set 0".

Erasing a blinking object should make it disappear, on any
which implements blinking. On bit matrix terminals, blinking
always be done by XORing, so that the non-blinking background is
destroyed

%GOCLS, on a terminal which supports blinking but not sets,
delete all blinking objects. Then, the convention for deleting
blinking objects is to select set 1, do a %GOCLS, and reselect set 0.
This has the desired effect on all terminals. This definition
%GOCLS causes no trouble on non-set terminals, since %GOCLS
otherwise be meaningless to them

To make blinking objects stop blinking but remain visible is
with a %GOVIS on a terminal which supports sets. But in general
only way to do it is to delete them and redraw them as permanent



-8-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Rectangles and

Bit matrix terminals have their own operations that display
terminals cannot duplicate. First of all, they have XOR mode,
which objects drawn cancel existing objects when they overlap.
this mode, drawing an object and erasing it are identical operations
All %GOD.. commands act IDENTICALLY to the corresponding %GOE..'s
XOR mode is entered with a %GOXOR and left with a %GOIOR.
list terminals will ignore both commands. For that reason,
program should continue to distinguish draw commands from
commands even in XOR mode. %TQXOR indicates a terminal
implements XOR mode. XOR mode, when set, remains set even
graphics mode is left and re-entered. However, it is wise
re-specify it from time to time, in case output is lost

Bit matrix terminals can also draw solid rectangles. They can
implement the commands %GODRR, %GODRA, %GOERR, and %GOERA.
rectangle is specified by taking the current cursor position to
one corner, and providing the address of the opposite corner.
can be done with either a relative address or an absolute one.
%TQREC bit indicates that the terminal implements rectangle commands

Of course, a sufficiently intelligent bit matrix terminal can
all the features of a display list terminal by remembering
lists which are redundant with the bit matrix, and using them
update the matrix when a %GOMSR or %GOVIS is done. However, most
matrix terminals are not expected to go to such lengths

























-9-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



How Several Process Can Draw On One Terminal Without Interfering
Each Other

If we define "input-stream state" information to be
information which can affect the action of any command, other
what is contained in the command, then each of the several
must have its own set of input-stream state variables

This is accomplished by providing the %GOPSH command. The %
command saves all such input-stream information, to be restored
graphics mode is exited. If the processes can arrange to
blocks of characters uninterruptibly, they can begin each block
a %GOPSH followed by commands to initialize the input-stream
information as they desire. Each block of graphics output should
ended by a %TDNOP, leaving the terminal in its "normal" state for
the other processes, and at the same time popping the what the %
pushed

The input-stream state information consists of

The cursor
the state of XOR mode (default is OFF
the selected set (default is 0)
the co-ordinate unit in use (physical dots, or virtual
(default is physical
whether output is going to the display screen or to a
device (default is to the screen
what portion of the screen is in
(see "Using Only Part of the Screen")
(default is all

Each unit of input-stream status has a default value for the sake
programs that do not know that the information exists; the
is the cursor position, since all programs must know that it exists
A %TDINI or %TDRST command should set all of the variables to
default values

The state of the current set (whether it is visible, and where
center is) is not part of the input-stream state information,
it would be hard to say what it would mean if it were. Besides,
current set number is part of the input-stream state information,
different processes can use different sets. The allocation of
to processes is the server host's own business









-10-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Using Only Part of the Screen

It is sometimes desirable to use part of the screen for picture
part for text. Then one may wish to clear the picture
clearing the text. On display list terminals, %GOCLR should do this
On bit matrix terminals, however, %GOCLR can't tell which bits
set by graphics and which by text display. For their sake,
%GOLMT command is provided. This command takes two cursor
as arguments, specifying a rectangle. It declares that graphics
be limited to that rectangle, so %GOCLR should clear only that
of the screen. %GOLMT need not do anything on a terminal which
remember graphics output as distinct from text output and clear
former selectively, although it would be a desirable feature
process it even on those terminals

%GOLMT can be used to enable one of several processes which divide
the screen among themselves to clear only the picture that it
drawn, on a bit matrix terminal. By using both %GOLMT and
sets, it is possible to deal successfully with almost any terminal
since bit matrix terminals will implement %GOLMT and display
terminals almost always implement sets

The %TDCLR command should clear the whole screen, including
output, ignoring %GOLMT

Errors

In general, errors in graphics commands should be ignored

Since the output and input streams are not synchronized
trouble is taken, there is no simple way to report an error
enough for the program that caused it to identify just which
was invalid. So it is better not to try

Errors which are not the fault of any individual command, such
running out of memory for display lists, should also be ignored
much as possible. This does NOT mean completely ignoring
commands that cannot be followed; it means following them as much
possible: moving the cursor, selecting sets, etc. as they specify,
that any subsequent commands which can be executed are executed
intended











-11-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Extensions

This protocol does not attempt to specify commands for dealing
every imaginable feature which a picture-drawing device can have
Additional features should be left until they are needed and
understood, so that they can be done right

Storage of Graphics Commands in Files

This can certainly be done. Since graphics commands are
exclusively of the ASCII characters 0 - 177, any file that can
ASCII text can hold the commands to draw a picture. This is
useful than you might think, however. Any program for editing,
whatever loose sense, a picture, will have its own internal
which determine the relationships between the objects depicted,
control the interpretation of the programs commands, and this
will all be lost in the SUPDUP graphics commands for displaying
picture. Thus, each such program will need to have its own format
storing pictures in files, suitable for that program's internal
structure. Inclusion of actual graphics commands in a file will
useful only when the sole purpose of the file is to be displayed































-12-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Note: the values of these commands are represented as 8.-bit
bytes. Arguments to the commands are in lower case inside
brackets

The Draw commands are

Value Name

101 %GODLR Draw line relative, from the cursor to

.
102 %GODPR Draw point relative, at

.
103 %GODRR Draw rectangle relative, corners at

and at
current cursor position
104 %GODCH <0>
Display the chars of starting at the
graphics cursor position
121 %GODLA Draw line absolute, from the cursor to

. The
effect as %GODLR, but the arg is an absolute address
122 %GODPA Draw point absolute, at

.
123 %GODRA Draw rectangle absolute, corners at

and at
current cursor position

The Erase commands are

Value Name

141 %GOELR Erase line relative, from the cursor to

.
142 %GOEPR Erase point relative, at

.
143 %GOERR Erase rectangle relative, corners at

and at
current cursor position
144 %GOECH <0>
Erase the chars of starting at the
graphics cursor position
161 %GOELA Erase line absolute, from the cursor to

.
162 %GOEPA Erase point absolute, at

.
163 %GOERA Erase rectangle absolute, corners at

and at
current cursor position




-13-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



The miscellaneous commands are

Value Name

001 %GOMVR Move cursor to point 021 %GOMVA Move cursor to point

, absolute address
002 %
Turn on XOR mode. Bit matrix terminals only
022 %
Turn off XOR mode
003 %GOSET Select set. is a 1-character set number, 0 - 177.
004 %GOMSR Move set origin to

. Display list terminals only
024 %GOMSA Move set origin to

, absolute address
006 %
Make current set invisible
026 %
Make current set visible
007 %
Make current set blink. Canceled by %GOINV or %GOVIS
010 %
Erase whole screen
030 %
Erase entire current set (display list terminals).
011 %
Push all input-stream status information, to be
when graphics mode is exited
012 %
Start using virtual co-
032 %
Resume giving co-ordinates in units of dots
013 %GOHRD Divert output to output subdevice . =0
the main display screen
014 %GOGIN Request graphics input (mouse, tablet, etc). is
reply code to include in the answer
015 %GOLMT
Limits graphics to a subrectangle of the screen. %
will clear only that area. This is for those who
use the rest for text







-14-

NWG/RFC# 746 RMS 17-MAR-78 43976
The SUPDUP Graphics



Bits in the SMARTS Variable Related to Graphics

Note: the values of these bits are represented as octal 36.-bit words
with the left and right 18.-bit halfword separated by two commas as
the normal PDP-10 convention

Name Value

%TQGRF 000001,,0 terminal understands graphics protocol

%TQSET 000002,,0 terminal supports multiple sets

%TQREC 000004,,0 terminal implements rectangle commands

%TQXOR 000010,,0 terminal implements XOR mode

%TQBNK 000020,,0 terminal implements blinking

%TQVIR 000040,,0 terminal implements virtual co-ordinates

%TQWID 001700,,0 character width, in dots

%TQHGT 076000,,0 character height, in dots

%TRGIN 0,,400000 terminal can provide graphics input

%TRGHC 0,,200000 terminal has a hard-copy device to which output
be diverted