LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAICN bi.0 .^4 'REPORT NO. 1+65 finks' f\\(utt C00-1U69-018T July 1971 GRASS: SYSTEM OVERVIEW by M. J. Michel REPORT NO. 1+65 GRASS: SYSTEM OVERVIEW* by M. J. Michel July 1971 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS URBANA, ILLINOIS 6l801 * This paper supported in part by the Atomic Energy Commission under grant U. S. AEC AT(ll-l)lU69. Digitized by the Internet Archive in 2013 http://archive.org/details/grasssystemoverv465mich ACKNOWLEDGMENT The help of the following individuals who worked on segments of the system is greatfully appreciated. The buffering control interface (PDP-8 to PDP-8/I link) and the satellite filing system were designed and implemented "by Mr. Harold Levin. The buffering control (PDP-8/I software) was provided by Mr. Roger Raskin. Mr. Charles Hyde provided the display terminal multiplexer and the disk interface, while the remote computer filing system was implemented by Mr. Alfred Whaley. The general advice of Professor C. W". Gear was also of great benefit. PREFACE A relatively low cost, stand-alone, timeshared, interactive graphics system implemented at the University of Illinois is described. The facility, using a mini -computer, storage CRT terminals and a disk, supports eight consoles with a two-dimensional drawing package, text editor, full subpicture capability, and individual user libraries. The software architecture allows other graphics applications to be added to the system by means of transient program segments. The complete system can be reconstructed with currently available, off-the-shelf, hardware. Communication is also provided to a large, remote computer. Several user written applications programs can execute concurrently under a timesharing monitor that runs within the remote computer's standard operating system. These user programs can communicate with programs in the mini -computer , with users at terminals directly, and with an archival filing package in the remote computer. TABLE OF CONTENTS Page ACKNOWLEDGMENT PREFACE 1. INTRODUCTION 1 2. CONFIGURATION: CHOICES AND CONSIDERATIONS 6 2.1 Satellite Section 6 2.2 Remote Section 9 3. SOFTWARE ARCHITECTURE: A USER'S VIEWPOINT 12 k. OPERATIONAL EXPERIENCE 18 5. EXTENSIONS 20 6. CONCLUSIONS 22 LIST OF REFERENCES 23 APPENDIX 25 1 . INTRODUCTION As 'part of a larger investigation into a general simulation and modeling system, a relatively low-cost, stand-along, timeshared, interactive graphics facility has "been developed at the Department of Computer Science, University of Illinois at Urbana-Champalgn. The purpose of this paper is to provide an overview of the facility. Detailed information can be found in the references cited. The utility and advantages of interactive online graphics terminals have been "well demonstrated over the past several years. Beginning with Sutherland's classic "SKETCHPAD" in 1963, graphics terminals and their applications as flexible man-machine interfaces have been steadily proliferating. However, the "graphics" terminal most often seen even today is merely a keyboard with an undersized alphanumeric display area. Even though some of these devices can perform a few elementary text operations on data in local character buffers, they hardly qualify as general graphics terminals. With the hare minimum price starting at three times the cost of a Teletype, the major benefits that these devices have to offer are silent operation and a slight speed increase. General graphics terminals for online use are few and far between; in fact, they are found in regular use only in a small number of large commercial companies, government agencies, and university research centers. The main reason is, of course, the high cost involved. Caveat emptor is the rule. No matter what the friendly terminal salesman might say, something (particularly terminal hardware) is definitely not delivered for nothing. With this in mind, state-of-the-art hardware for color displays, three-dimensional prespective rotations and translations, hidden line removal, windowing, and shading is priced quite beyond the reach of small, medium, and for that matter, even most large installations. Simulating these facilities in real time for productive (as opposed to demonstration) purposes with software is also well known to require a very large investment in processing power, even for just a single terminal. Technology cannot quite support interactive computer graphics that appears to the terminal user as three-dimensional, color motion pictures, all at a price comparable to that of seeing a John Wayne movie (e.g. $l/hr.). However, some graphics facilities are economically feasible, and their power is considerable, particularly in light of how much can be accomplished with the primitive capabilities of a card reader and impact printer. For ease of discussion, hardware /software systems that support the features mentioned previously (e.g., three -dimens ions , windowing, etc.) will be termed simply "3D." The term "2D" will apply to systems that support comprehensive two-dimensional graphics, capabilities. These capabilities include line drawing (with instancing and connection abilities), sophisticated text manipulation, maintenance of archival user libraries, and flexibility of application. Although a continuum of systems exists between 2D and 3D, the general assumption being made is that 3D systems tend to be too expensive to allow their wide use in the computing community. On the other hand, a carefully configured 2D system would be widely available, e.g., economically feasible. Another assumption functioning as a guideline is that using a less expensive, less intelligent terminal implies using more computer resources to support it; conversely, the more expensive, more intelligent terminals require less computer support. Dedicating a computer to a few unintelligent terminals is expensive, but using intelligent terminals is itself expensive. Even compromising is not effective: try moderately intelligent terminals connected to a computer capable of handling background batch stream or standard keyboard terminals. Such a configuration tends to reduce the superficial cost of the graphics support, but often results in an unpleasant degradation in system (both batch and terminal) performance. Discrete response time at the terminals may be long, and certain resources, such as computer main memory allocated to the graphics terminals, remain idle much of the time, so reducing batch or keyboard capabilities . A typical 3D system would include at most two or three terminals directly attached to a large computing facility containing extensive peripheral resources. These terminals cost anywhere from $50K to $200K each, depending on the nature of the hardware involved and the 3D features supported. Trade-offs involve such things as the method of display refresh (e.g., individual memories, shared memory, computer main memory, drum, or disk) and the "intelligence" of the terminal (e.g., what the terminal can do on its own: display only, data structure manipulation, or general stand-along processing).. Examples of terminals suitable for the above systems include the IBM 2250, the DEC 338, and various terminals made by ADAGE; the intelligence of these terminals runs from low to high, respectively. Typical 2D systems can look very similar to the above 3D systems. However, the peak intelligence of the terminal and the maximum computer support will be much lower. An example of a minimal terminal consists of a display with a very simple controller refreshing out of its own memory. This type of device would cost about $20K with half of that going for an adequate size memory. Of course, the terminal is completely dependent on support from the computer. If the computer dedicates enough support to the terminal , a system fairly close to a low level 3D could be reached. Such support would be expensive in terms of the cost of the dedicated resources. On the other hand, a lower level of support implies an increase in the number of terminals serviced or an increase in computer resources available for other uses. Upgrading the intelligence of a terminal in a 2D system, even by small increments, rapidly decreases the amount of computer support needed. An example of the extreme is provided by a configuration that has just recently appeared: a display serviced by its own (dedicated) mini-computer and a small disk. In this case, ALL 2D functions can be completely supported locally; support from the main computer is needed ONLY for (l) permanent library maintenance, and (2) analysis number-crunching. Hardware for such a 2D terminal would list at about $U0K. The cost is still far above a "drop in the bucket," but the difference between this very intelligent 2D terminal and an unintelligent 3D terminal in terms of both terminal hardware price and main computer support, is quite significant. Yet further reduction in cost without facility or performance loss is still possible. Note that the mini-computer and disk, at each terminal is obviously idle during user "think time," e.g., most of the time. The tempting improvement is to service several terminals with only one mini-computer and one disk. Carefully assessing the requirements of a 2D system and careful planning does indeed allow this to be accomplished. The result is a multi -terminal, flexible, and comprehensive 2D drawing system, entirely supported on a local mini-computer with access to a remote computer. only for occassional, very limited support. The average retail off-the-shelf per terminal cost for this system is only $20K; the cost of an eight terminal configuration would be about $l60K or less than twice the cost of a single unsupported 2250 Model 1! Three typical applications that this 2D system can support are graphical design, document preparation, and network analysis. The first application includes such things as architectural plans, mechanical drawings, and magazine page layouts. The second includes the obvious: reports, articles, manuscripts, etc. The last encompasses all phases of problem definition, from defining the primitive elements through specifying constraining network equations. The remote computer facility needs to be called only when finished items are ready for archival storage or for numerical analysis of a completely defined network. All other work, and the complete job in the case of the first two applications, is entirely supported on the satellite mini-computer complex. An example of such a configuration, the Graphical Remote Access Support System (e.g., GRASS), is described in the following sections (c.f. Figure l). Eh O H CO K O EH 3 O Ph W W Sh Ph O O o o s _ H J K O E EH EH fe S H P O g fqup o •H +3 ed U bO •H O O 0) ?h % U W O W •H F«H 2. CONFIGURATION: CHOICES AND CONSIDERATIONS The configuration outlined in Figure 1 has "been implemented in GRASS with the following items. The local (e.g., satellite), hardware includes eight direct view storage CRT terminals, each with keyboard and joystick, connected to a terminal controller, which is in turn linked to a PDP-8 mini-computer. This computer is responsible for the manipula- tion and temporary storage of all data structures and display files needed by the terminals. The terminal controller acts as a buffer and multiplexor for display files being shipped to the terminals and for keyboard lines and joystick (X, Y) input being shipped to the PDP-8. In addition, the PDP-8 has an interface for communication with a large remote computer, specifically, a 360/75- This remote computer is responsible for providing number-crunching and archival file storage. A graphics time- sharing monitor runs under the normal operating system of the 360/75 ; various user written applications programs can run concurrently under this monitor, communicating with programs in the PDP-8, with the terminal users directly, and with a 360/75 graphics filing system. 2.1 Satellite Section The desire to implement a 2D mult i -terminal graphics system using a single mini-computer immediately brings two problems to the fore. While "mini -computer" implies limited instruction repertoire, speed, and memory, "multi -terminal" implies a high interrupt -load environment. Hence, two critical features of the local portion of the configuration are its attempted -maximization of the PDP-8 's available library space, executable code, and buffering areas and minimization of its interrupt load. The aim of the first is to increase the capabilities available to the terminal user, while the intention of the second is to facilitate the concurrent support of several terminals. Inherent in both is that response time for the capabilities supplied be reasonable, and that total system cost be minimal . Although the PDP-8- used is a very small, standard mini- computer -with only seven instructions , two features were added to help make it uniquely powerful. First, extra memory was supplied for a total of l6K of twelve bit words. All of the memory used is standard speed core for this machine and, in fact, PDP-8* s were designed to accommodate as much as 32K of this type of core. Unfortunately, very few installations have ever taken advantage of this feature of the machine. Second, a very high speed, high density head-per-track disk was added as a local mass store. Average latency is only l6.5 ms, the transfer rate is approximately one word every 5ys, and total space available is about 300K words . Moreover , data can be read or written in variable length blocks of from 1 to 8192 words. These two additions help solve the first problem. The extra core ensures that there is adequate memory space for essential resident code (monitor, filing system, data structure manipulation services, display file output services), for fixed buffers (.console control blocks, buffering controller output and input, data structure manipulation area), and for transient code (terminal logon filter, drawing sequencer, library maintenance, text editor, etc.). On the other hand, the disk provides enough storage for a large local library of picture structures and transient code sections. The more transient code sections ("user programs") that are added, the more "intelligent" each terminal appears to the user. The second problem requires a slightly more complicated solution, involving the design of the terminals themselves and their connection to the PDP-8, rather than the PDP-8 itself. Operations such as real time three-dimensional rotation and clipping currently inflict a large cost penalty on terminal equipment and associated support computers particularly in a multi -terminal environment. These capabilities were thus considered as beyond the range of supportable facilities. The impact of this decision on the choice of terminals was significant. Once the need for a dynamically changing display is eliminated, storage tube CRT terminals become very attractive. No refresh mechanism or storage is required, making these devices the lowest cost, interactive, full graphics terminals now available. Moreover, there is no upper bound on the amount of data that can be presented on the screen. That is, if a terminal has a refresh memory, and that memory becomes, filled, no additional data can be displayed. With a storage tube, this cannot happen. Of course, there are drawbacks. The first is a 0.5 second nonselective erase time and the second is the lack of display file correspondence for joystick (X, Y) input. The first is really not too annoying since real time-, 3D, etc. , has been eliminated from the system. The second can be greatly minimized by careful software design. The use of storage terminals reduces terminal handling to a rather small task, namely just the initial transmission of the picture. However, the mini-computer must be able to service a multiple number of terminals. If one terminal required a complex data structure alteration while another requested a redisplay of a picture, CPU saturation would probably result. (A technical aside is necessary at this point: the picture must be transmitted to the storage terminal one character at a time. This is the result of the differences in display vs. transmission time, as well as the fact that the terminals have no data buffering capability. Thus, the interrupt load to send an initial display is quite high.) To counteract this, a simple timeshared buffering control unit?* for initial picture display is needed. This combination of storage terminals plus controller greatly reduces the interrupt load for the PDP-8. Input from a console is merely a few words of joystick (X, Y) coordinate information or a complete text line. Output to a display is usually just a line segment, text string, or subpicture instance, transmitted — as far as the PDP-8 is concerned — in a single block transfer. The controller can easily overlap transmission of characters to as many as eight terminals. With a relatively small number of interrupts to service, the PDP-8 has much more processing time available for use in satisfying data structure operation requests. Hence, the total number of terminals, and/or the quality of support, can be greatly increased. While a "simple" device is all that is needed, a PDP-8/I was available for this implementation. It allowed flexibility for testing different types of terminals and different buffering schemes. However, a small hard-wired device would be quite adequate for the buffering needed. Two other minor but highly useful additions were made to the PDP-8 complex. A sixty cycle clock is used to sequence certain system functions and to keep track of the time of day, while a teletype is used as an operator's console and system log. The operator can specify which terminals are considered operational and can request or reset certain system status flags. The fact that a user has signed on or signed off is printed automatically on the teletype, along vith the console number, the user's number, and the time of day. Any illegal sign-on attempts are also noted on the log in a similar manner. 2.2 Remote Section The remote 360/75 is a typical large scale computing facility. Its resources include 1 megbyte of fast core, 1 megbyte of slow core, 20 online disk drives, 2 drums, several remote entry stations, printers, and card readers. Serving several thousand student, staff, and research users, two to three thousand jobs are run through the facility's batch streams daily. Computational and filing support for the satellite graphics system are obviously within the range of this remote installation's capabilities. The problem, then, is tapping these resources without unduly degrading batch performance. If this can be done efficiently, the occassional need for extensive computational power can be fulfilled inexpensively . Note that this is a very typical situation. A small group of users with its own hardware sometimes needs the facilities of a large installation that can only be available economically when a large group of users is present. The small group effectively has no influence over the choice of hardware at the remote cite. Moreover, they cannot afford to pay a major share of that installation's costs, so they cannot expect a major share of the available resources. Whereas the satellite hardware was chosen and tailored with the multi-terminal graphics system in mind, in any practical sense, the remote computer must be viewed as a "given" quantity. It exists already; it can be tailored only in the sense that effective software and some careful administrative decisions can extract the needed resources at a reasonable cost to both sets of users. 10 Resources for archival storage are relatively easy to allocate. Although many variations exist, all remote installations of this size have some charging scheme for allotting online disk and drum space. The vehicle is usually a monthly fee related to th.e amount of space reserved. Typically, individual users do not acquire these resources on a reserved basis; only the larger subgroups among all users, such as student instructional classes and departmental research groups, actually "rent" online storage space. Hence, some amount of such storage (in the present case, less than half of one disk drive) can be paid for by the graphics system users in the same manner as. other subgroups. The cost is reasonable and the method judicial. Computational power is another matter. This really implies three questions. How long is the job in question in the machine? How much main memory does it tie up while there? What percent of the total available execution time does it use in the period? These items, clock (total) time, memory space, and execution time, have very distinct impacts on the remote system's normal performance. Intended remote support for the satellite system is to be (l) occasional short bursts of number- crunching and (2) occasional archival storage requests. The first will require a very high proportion of total execution time and probably a large amount of memory. The second requires very little execution time and a relatively small amount of memory. The ideal would be to have these remote services available at all times , noting that between infrequent requests of short duration, no resources at all should be in use. Unfortunately, operating systems generally available do not support this. Specifically, when a job (or job-step in the case of OS/360) enters the system, it immobilizes the maximum memory space that it might need at any one instant for its entire sojourn in the machine, even when idle! Even though only a thousand words or less of memory might be needed in the idle state to recognize a request and load the necessary service procedure, 100K words would be continuously unavailable to the installation if that was the job's maximum allocation. Of course, this would be unacceptable to the other users, and rightly so. 11 The design of the local system is of aid at this point. Significant stand-along operation including comprehensive data preparation for later use in conjunction with the remote facility is available. Hence, the services of the remote installation need not, in practical terms , be available at all times but only after sufficient material has been prepared locally. Arrangements can be made for the remote services to be available during certain limited time periods. This is, of course, the typical compromise administrative solution for this type of problem. But this compromise would be reached even if no stand-alone ability was present; the small graphics group cannot afford more. The usual graphics system, lacking stand-along capability, would be "restricted" by the compromise to operate only during the limited hours agreed upon. And part of that time, in turn, would be spend on activities that did not even require the remote facility in the first place. So the satellite system with stand-along ability has the very distinct advantage of always being available for some form of productive use. The first two questions, job length and memory requirement, have been skirted. With a reasonable operating system, they could be resolved adequately; in the present case, the problems they pose can only be compromised by administrative decision. The question of execution time is resolved easily: graphics tasks execute at the same priority as batch tasks. Quick operations will be handled rapidly, while long computations will be slowed down by the service requests of other users. However, since no task has abnormally high priority, batch performance is not unduly degraded; the graphics tasks are essentially the same as other normal batch users . 12 3. SOFTWARE ARCHITECTURE: A USER'S VIEWPOINT The us.er interacts with GRASS "by means of the joystick and keyboard at his terminal; the display screen of the terminal appears to the user as shown in Figure 2. All data being manipulated, whether simply a page of text or replete with lines and instances, is displayed in the Draw Area. This data Is refered to as a "picture" and is represented within the PDP-8 by a "data structure." The remaining nine areas of the screen are used by programs: running in the PDP-8 to communicate control information ("frame text") to the user. Information of this type includes: system status messages (System Line Area), option or mode lists (Menu Area), YES/N0 responses (Answer Area), mode termination (Return Area), instructional messages (Prompt Area), function lists (Light Button Area), and ERR0R responses (Panic Area). As. appropriate, the particular program being used will alter the messages and options shown on the screen; the terminal user will indicate desired choices with the joystick. In addition, lines entered by the user at the keyboard will appear at the bottom of the screen as they are typed; the line disappears' after being completed (e.g., when sent to the PDP-8 from the buffer control). To "regenerate" the display means that the screen is first erased, then the frame text is displayed followed by the picture as reconstructed from its data structure in the PDP-8. Note that the data structure for a picture represents two classes of information: generally visible and generally not visible. The first is always displayed by the system automatically during a regeneration; this includes lines, text, and instances of other pictures. The second class is displayed only by the explicit request of a program as initiated by a terminal user's function choice. For example, a picture of an electrical network would be constructed with such things as resistor, capacitor, and transistor instances in the visible class. On the other hand, such information as the node equations for the network and lists of the variables used in the equations would be constructed in the invisible class. Whenever a regeneration is performed, the network, with its resistors, capacitors, and transistors, would appear in the Draw Area. But when the user desired to look at the 13 network's equations or the list of global variables or the list of local variables, etc., he would use a function command in his program to cause display of the information. The Draw Area might contain, for example, the equations rather than the network image. SYSTEM LINE Program Segment Line Menu Area Draw Area Answer Area Prompt Area Return Area Light Button Area Panic Area Keyboard Input Line } 2 lines > 32 lines 3 lines 2 lines 10 characters 65 characters 10 characters Figure 2. GPASS Display Screen Sectioning Detail Ik After successfully logging-on to the PDP-8 system, the user may begin execution of any currently available interactive program by choosing it from a list that is displayed in the Menu Area. These programs, vhich execute entirely in the PDP-8 under a multi -terminal monitor, use system supplied service routines to manipulate the data structure, to access the local filing system, to regenerate the terminal's display, and to transmit data to the remote computer ( 3 6o/75>. Consult Figure 3. •s*r N « rn K >H In i-l rn ,h- 5 h R o !s g VO .c w rn L=— £ -^ CJ ^ H h-l « o 1=1 PH 1=4 R EH 1=4 ■^ H P o a pq o D « «* Ti fl CO U CI) P n (!) a > o cd CO 13 S cn fl o n H en •H « fi l> W -P u H E m (1) H •H • Tt rn i-i 5h p cd fl aj o cd T3 -p a) H fl fl o Ti p fl) b(] a i-l (i) TJ n bO EH 5 o CJ 5n Hi to o X EH O H P CD S 5-4 5-4 CD CD ft cn 5-4 -H bO tJ o 5-4 CD Pm fl ai cd p., Jh cn O O FC, •H d) CO bO CO a) >> fl fl fl H o cd fl o •H P cd 5-i bO •H