Graphical extenstions to TRAC
for TRAC Display
Graphical extensions to TRAC to permit display of results.
Graphic systems can be broken into three logical groups: the display programming language, the user'system, and the analysis program. The programming language is usually a higher-level language with special commands added to communicate with the display. The language used varies depending on the computer system. The Graphic I console at Bell Laboratories uses a language called GRIN whose basic structure looks like FORTRAN. The ESL Display at Project Mac uses the B-ccre system which is written in AED.
The user'system is a program written in the display programming language. It is the program that listens to the user requests, creates the picture data base, and maintains the display. The user'system may be either designed for a specific application such as Sketchpad. The former has the advantage of being problem specific and, therefore, being more simple to design and program. The data base can also be tailored to the problem at hand. The latter has the advantage of being available for the user who does not want to bother with programming the display. The generalized system, however, tends to be a very large program. For example, the Digigraphic System requires 25,000 words of storage for the user'system program. The designers used a memory overlay technique with a disk as the mass storage element in order to conserve the amount of core memory required. The analysis program computes the data base created by the user'system. It may output the solution on the display through the user'system, or on another external device. The analysis program can be written in the display programming language or another language. The choice of language will be dictated by the capabilities of the display language and the hardware configuration. Extract: Specifications For A Display Language
Specifications For A Display Language
The following nine specifications were decided on as design criteria for a graphic language. The first six are criteria for the host language, and the last three are for the graphic primitives:
1. The language must be able to communicate to the user in real time. It must have the facility to accept input from the user through a typewriter in any format and output necessary information to him.
2. The implementation of the language must be compact. Due to the limited amount of memory space in the PDP-8, most languages had to be discarded. The FORTRAN system provided with the machine, for instance, did not lend itself to expansion and did not allow room for enough statements to do meaningful graphics.
3. The language must be suited to tasks such as storing block data. naming items, searching and calling back the data. The graphic elements would be stored as data base within the language as blocks of information pertaining to element. This data would have to be stored dynamically as the user developed the picture. The data must be labeled so that it could be called back by the user for modification or deletion.
4. The language must have elementary arithmetic and Boolean capabilities. In graphics the value of sophisticated arithmetic functions, such as floating-point operations, is not great for most applications envisioned. The ability to add such capabilities, should the need arise, is important.
5. The language need not be capable of analyzing the data except where it is necessary for the organization and manipulation of the data base. The more powerful the language, the less reliance it will have on the large computer. The problem of memory space for the SCD programs is again the limiting factor. If the language is more powerful, it will also undoubtedly take up more room in the SCD leaving less room for programs.
6. The language must be capable of communicating with other processors to send the data base and to accept new programs.
7. The language must be capable of interpreting the data base into a display file in real time. The display file is the list of instructions that the display device executes to produce the picture on the CRT- The display file must be updated each time the data base is changed so that the picture corresponds to the data. This job could most efficiently be done by making the data base executable functions within the language that produced the proper display-file code. The data base need only be re-executed when the data is changed.
8. The language must handle display-oriented inputs from the light pen, push buttons, Rand Tablet, etc. Both light-pen functions, pointing (at an element) and positioning (using a tracking mechanism) must be implemented in the language.
9. Finally, the language should be machine independent. The language should be simple enough to be implemented on any general-purpose computer. The graphic primitives should also be kept simple and general so that they can produce a display file for any reasonable display device. The language should be externally similar independent of the implementation,
Extract: Choice of Language
Choice of Language
The first three specifications suggested that a type of text editing language be used. The idea of a picture being equivalent to a string of text is not new although some researchers have argued that a two-dimensional representation is preferred. Editors are usually compact and well suited to tasks as storing and re-calling the data. They are usually lacking, however, in logical and arithmetic capabilities.
A more general text handling language was sought and two were found, SNOBOL and TRAC. The former, though logically more powerful than the latter, did not meet the second criteria of being compact. The latter, on the other hand, was already partially implemented on the PDP-8 in two thousand (octal) locations. TRAC was originally designed for communication to the user through the typewriter, so that the input-output problem was already solved.
The language also lent itself well to the graphic extensions as primitive functions.
TRAC stores both its programs and data in a textual representation, The programs are therefore, machine independent because they are stored in the same format independent of the machine. The programs are executed interpretively and can create new textual forms which can be either data or new programs.
The TRAC language, meeting all the necessary specifications, was extended to include the graphic primitives and renamed TracD. This document describes the work and the thought involved in that project.
Extract: Display-Oriented TRAC Primitives
Display-Oriented TRAC Primitives
The intent was to use the TRAC language as the basis for a display programming language. Therefore, the set of TRAC primitives was extended to include the facility to communicate with the display device. The display primitives were designed to be simple enough so that they could be implemented on a simple display system. This was done in order to maintain the concept of device independence stated above. There are occasional references to the particular hardware used in order to clarify a specific function.
The display is both an input and an output device. The output is the information presented on the cathode ray tube (CRT). In order to present the information, a file of display instructions are interpreted by the display logic to draw lines, points, and characters, to do control functions like skips, transfers, subroutines (push, jump, and pop), and to modify registers. Display inputs are accepted through the light pen and the push-button box.
The new primitives added to the system are broken into three major categories:
1. Display Elements - Four primitives that create the display instructions to put information on the CRT.
2. Display-File Control - Four primitives that control the naming, skeletal production, and maintenance of the display files,
3. Display Input - Three primitives that provide information about the status of the light pen and push-button box.
Extract: Display Elements
There are four display-element primitives in the present implementation of TracD. Three of these are "Basic Elements" which produce the appropriate display code for its element. The elements are points (PT), line (LI), and text (TX). These elements may be combined to form a symbol that can be called later with the symbol (SY) primitive. A symbol may be composed of all four types of elements and may call any defined symbol except itself.
The set of elements chosen can be extended at a later date. Circles and arcs, which are simple to generate, may be added in the near future. Generalized second-order functions, ellipses, parabolas, etc., could also be added. The line, point, and circle elements could then be removed since they are special cases of the second order curve.
Within the argument string of all the present elements, there is an argument reserved for naming that element. This argument is the last argument and is optional. The argument will be represented as NAME* in the function calls given below. NAME* is the value left when the light pen pointing primitive function is given and, therefore, may be a simple text string or another function.
Another entity common to all display elements is the x and y coordinate pair. It is used to indicate the starting point, origin, or end point of that element. The x coordinate precedes the y and is separated by a comma; i.e., they are two separate arguments. The range of the coordinates are from 0 to 7777 octal, with (0 0) normally being the lower left corner. Only 2000 octal points are visible on the CRT at one time, but picture translation is possible.
(PT, X, y, TEXT, NAME*)
The PT element does not intensify a single point at the coordinate pair but rather puts up the string TEXT (the fourth argument, whatever the string happens to be). PT is, therefore, not designed for curve generation or the like but rather as a means of spotting a particular coordinate pair. This type of function is necessary for making logical connections in a topological structure.
:(LI, x1, y1, x2, y2, NAME*)
Straight-line drawing capabilities are called by the LI primitive. The two coordinate pairs specify the starting point (x1, y1 ) and the end point (x2, y2) of the line. The display hardware automatically generates lines, given the incremental movements delta x and delta y in the display list. The routine that executes the LI primitive must therefore generate the display code to move the beam to the starting point (x1, y1) and then calculate the incremental vector:
d x = x2-x
d y = y2-y
and place it in the display list.
The above method of representing lines was chosen over the more natural (for the present hardware) incremental representation.
:(LI, dX, dY, NAME*)
The incremental representation was felt to be too sequence dependent. Deleting a single function could change the entire orientation of the picture. It was felt that the form required to compensate for line deletion in the incremental representation would be excessively complicated. The major advantage of the latter representation, the ability to relocate parts of the picture by changing a set point, is offered in the symbol function.
:(TX, X, Y, STRING, NAME*)
This function provides the facility for displaying strings of alphanumeric characters. The (x,y) coordinate pair is the starting point of the original x, in order to format the text properly. There are 55 printing characters in the present display character generator, but the full 96 printing ASCII set could be implemented with no difficulty.
:(sy, x, y, NAME, NAME*)
The SYMBOL primitive causes the display to execute previously defined display code. The code was generated by calls to the elements PT, LI, TX, and SY, and defined with the name NAME. The details of the procedure for defining code as a symbol is given in the Display File Control section. The symbol is relocatable on the screen with its starting point being the x-y coordinate pair.
A symbol is considered local rather than global in nature. The internal composition is maintained only in the display file, not in the data base used by the TRAC forms.
There is no way of distinguishing different pieces of a single symbol. The light pen function will yield NAME* only, independent of which part of the symbol was pointed at and to what depth the sub-routining has gone,
The justification for this approach lies in the original reasons for having symbols. Symbols were designed to be collectors of unwanted data base information. Providing such a garbage collecting technique was considered a necessity because of the limited space available within the TRAC form storage area. It is also an asset because of the increase in system response time due to the removal of unnecessary information. If global symbols are required, it is possible to create such a structure within the TRAC framework.
Extract: Display File Control
Display File Control
The functions of the Display File Control primitives are to name, store, and delete symbols and to store and execute a picture. There are four primitives in this group: the first names and indicates the beginning of a symbol or a picture (PN); the second and third indicate the end of a symbol (FS or picture FW); and the fourth removes all symbols from storage (CE).
This function has two arguments and null values. It creates the skeleton structure needed to start a display file. It enters NAME, in the appropriate place and sets the first pointer to the first location available for the display file. It also stops the display, if it is presently running, while the new display code is being generated. The function also checks all the symbols names presently in core. If the same name is found, TRAC will respond with an error code "S!" typed on the printer.
FINISH WORK AREA
The (FW) function indicates the end of element functions for the picture desired. It adds push jumps to two permanent sub-routines for cross-tracking and translation. It also adds a display jump to the beginning of work area. The display, which was turned off with the (PN) function, is reinitialized at the beginning of the work area.
This function calculates and inserts in the display file a vector to return the x-y coordinates back to their original value. This makes the symbol closed; i.e., it has the same start and end point. A pop (return from sub-routine) command is also put into the display file. The work area pointers are changed, so that the work area begins after the new symbol.
The Clear Core function removes all the symbols that have been defined. Initially, a selective symbol delete function was anticipated. Problems arose because of the interdependence of one symbol on another. It was felt that this function should be handled by a TRAC form. Therefore, to delete a single symbol all symbols desired should be redefined.
Extract: Display Input
The third class of primitives is concerned with introducing input data into TRAC. The two devices presently handled by TracD are the push buttons and the light pen. The light pen input is separated into two distinct functions; that of indicating a particular coordinate position on the screen (DC), and that of pointing at an element on the display (LP).
READ PUSH BUTTONS
In the present hardware, there are twelve push buttons with lights behind each indicating the present state of the button. Pressing the button complements its state. The function (RB) has the value of the state of the buttons represented as four octal digits.
The value of the (DC) function is two four-digit octal numbers separated by a comma. The two numbers represent the present x and y coordinate position of the tracking cross. The cross is displayed whenever the display is running. If push button zero is on, the cross will stay under the center of the light pen. By moving the cross to the desired position and giving the (DC) function, the coordinate pair for that point can be got and placed directly in an element function.
The light pen function has one argument and its value is the contents of the light pen name buffer (LPKB). The LPNB is always cleared after being read, so that its contents can only be read once. If the buffer is empty when the (LP) function is given, the function will have null value. The purpose of the LPNB is to hold the light pen name, NAME*, of the last element seen by the light pen.
The advantages of TracD are dependent on the type of system the display is in. In the batched processing computer, the TracD system allows the user to develop the problem formulation . Only when the LC is needed will it be requested? most real-time operations will be handled by the SCD-TracD system. In the time-shared environment, the TracD system aids in reducing the amount of expensive computing time and improves response time to most real-time requests.
In a single computer system, it is possible to have more than one type of display system. For instance, at Project Mac, there are three different SCD systems; namely, the PDP-7 Kludge, the PDP-7-340 system at the Science Teaching Center, and the 338 system. Unfortunately, it is not possible to take programs written for one system and run them on another without re-programming. The concept of display compatibility is, therefore, very important if the art of computer graphics is to advance rapidly. Since display manufacturers are not likely to agree on a single, compatible instruction repertoire for their displays, it is desirable to develop a common representation or meta structure, for compatibility. One of the important design criteria is that it satisfies the compatibility constraint.
The TracD system satisfies the compatibility criteria by creating a textual representation of the picture. The text is stored as seven-bit ASCII characters whether the SCD has twelve, sixteen, or eighteen-bit word length. The graphic elements, although similar externally, must produce the display code in the format for the particular display device. The element functions were kept simple to make the code generation a simple task in order to maintain the concept of device independence.
Functions in TracD are also stored in a textual representation. Functions or a system, of functions written for one SCD can be run on any other that has TracD implemented. Thus, the dataphone communications in both directions; i.e., the functions from the LC and the data to the LC are compatible independent of the type of SCD used as a terminal. The LC, therefore, need not know which terminal it was talking to since they all look identical.
The concept of compatibility can be extrapolated one step further to include terminals not belonging to the original LC complex. Suppose a user at a display terminal at MIT's Lincoln Laboratories, normally connected to their IBM 360 model 67, wished to process graphic data with a program written for Project Mac's Multics System. He would have three alternatives: 1) He could take the program from Mac and re-program it for his machine; 2) He could come down to Mac and use a terminal here; or 3) If he had a TracD system for his terminal, he could call Multics and use the program at his own terminal. If the latter alternative were permitted to everyone, a user would not have to spend valuable time reconstructing an existing system.