LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 5 1 o.e>4 no. 343-346 coip. 2 The person charging '^l\^XrtryVom Tatest Date stamped below. ^^^ ^^^^^^^ ,he«, n,uti.a.ion. and -f'^-"^J„,. •.„ disn-Uso. .ron, for dUciplinory oct.on and may the University. r»n»er 333-8400 TO renew .ai. Telephone Cen^e- ,,,^,^^^HAMPA1GN^ Li61_O-1096 Report No. 3^+6 '/y?cu:ii C00-1U69-01UU GRAPHICAL REMOTE-ACCESS SIMULATION SYSTEM (GRASS) The Communication and Monitor Components (GASP/GLASP) by Martin Joel Michel August 1969 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS Sf? 2* Digitized by the Internet Archive in 2013 http://archive.org/details/graphicalremotea346nnich Report No. 3^+6 GRAPHICAL REMOTE-ACCESS SIMULATION SYSTEM (GRASS) The Communication and Monitor Components (GASP/GLASP)* by Martin Joel Michel August 1969 Department of Computer Science University of Illinois Urbana, Illinois 618OI This work was supported in part by Contract U. S. AEC AT(ll-l)lU69 and was submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science, January 19T0. Ill ACKNOWLEDGMENT The author is indebted to Dr. C. W. Gear whose suggestions and comments helped greatly during the development and writing of this thesis. IV PREFACE This paper describes a communications component for an online, graphical, simulation system operating in a multiterminal environment. The desired features, hardware /software tradeoffs, and other design considerations of the overall system are "briefly discussed followed by a description of the communications package. The current implementation level, problems, and possible develop- mental trends are also described. TABLE OF CONTENTS Page I. THE CURRENT ENVIRONMENT 1 II. A DESIRED ENVIRONMENT 6 III. PROPOSED SYSTEM—AN OVERVIEW 13 A. Hardware 13 B. Software l6 IV. GASP/GLASP 2k A. Current In^lementation 2k B. 360 Section 26 1. General Description 26 2. Macros 27 C. PDP8 Section 28 1. General Description 28 2. Routines 29 V. CONCLUSIONS 3k BIBLIOGRAPHY ..... 35 APPENDIX A. 360 Macros 36 B. UIM0N8 Routines k6 C. Features of 36O/5O-PDPT-PDP8 Communications . 56 D. PDP8 Data Formats 60 E. UIM0N8 Interrupt Tables 63 F. UIM0N8 System Locations 65 VI Page G. Character Code Equivalences 67 H. JCL Examples TO I. GRASS Acronyms 73 vil LIST OF FIGURES Figure Page 1. Hardware Configuration 8 2. Software Configuration 11 3. Current Hardware Configuration 2k I. THE CURRENT ENVIRONMENT The utility and advantages of interactive online graphics terminals have been well demonstrated over the past several years. 2 The effectiveness of simiilation studies is obvious . A marriage of 3 the two is also clear and has already been performed many times. However, powerf\il graphical simxolation systems are not at all common, and are in fact only in regular use at a small number of large commercial conipanies and government agencies. Two primary reasons for this resiolt are high cost and low flexibility. Typically, a large CPU with extensive peripherals is used to service at most two or three directly attached graphics terminals. Often the same CPU is doing some batch processing in background while also running a timesharing service at standard keyboard terminals. Such a configuration tends to reduce the superficial cost of the graphics support, but results in an unpleasant degradation in system performance. Discrete response time at the graphics terminals is long. Certain resources, such as CPU core aJLlocated to the graphics terminals, remain idle much of the time and so reduce batch and timesharing capabilities; and certain often trivial graphics operations, such as pentracking, can completely saturate the CPU. On the other hand, to dedicate the CPU to graphics support quickly increases the cost. Recently, a compromise of sorts has come into increasing prominence. A small, or relatively small, general purpose CPU (8 to 32 k of core, $15,000 to $100,000 price range) is used to perform the local functions (such as display manipulation, data structure creation, parameter assignment, prompting, etc.) needed to effectively interact with a user at a display console ($30,000 to $90,000 price range) in a relatively fast response environment. This smaJ-l CPU is attached in satellite mode to a large central CPU which provides library, doc\imentation, and particiilarly nuniber-cr\anching analysis facilities. Hence, after specifying his problem, the console-user theoretically has to endure a long response time only when analysis is being performed in the central CPU. However, "long" in this case is only the analysis time, not analysis time, plus card punching time, plus turn-in time, plus backlog time, plus print time, plus return time . Yet many problems still persist. l) The satellite CPU is typically capable of only supporting one display console, so per-terminal investment is still not small. 2) The satellite CPU is incapable of some forms of desirable operations (such as picture rotations). 3) The satellite CPU has very limited data storage capabilities, thus limiting picture coii5)lexity and, more important, severely limiting the amo\ant of necessary library information that can be stored locally. Hence, access to the central CPU library becomes very frequent as the number of users and the library grow. This lengthens, in turn, response time for fimctions (such as picture- sub-pictxire generation) that are considered "local functions." h) The speed of the data linkage between the satellite and central CPU's is a critical factor in the amount and type of data that can be passed back and forth. This affects the division of labor between the CPU's and the consequent response time at the display console. 5) Resources in the central CPU are still wasted, since allocation of resources must be made at the beginning of a session, even though actual analysis and maximum utilization may not occur until the end. The purpose of a graphical simulation system is to aid a user in defining, analyzing, and solving his particular problem. Certain terms just mentioned mxost be stressed: "aid" and "his particular problem." First, the system must strive to avoid hindering the user or complicating his problem solving attempts "with system- dependent details and restrictions. This is, of course, an ideal in a world where most users are people not intimately familiar with computers, but who want to use them in pxirsuing their other work. By necessity, any system miost have certain formalisms and conventions, but these should, and must, be implemented such that they are natural arid convenient to the neophyte, as well as the experienced, user. Presently, most systems are bvirdensome and lack adequate prompting and self teaching facilities. Second, the system should attempt to solve as wide a range of problems as possible. This is easy to say — it is what most people usually try to accomplish — but it is a goal quite difficult to attain. Generality usually means obtaining resiolts for a specific problem in more time than would be needed by a special purpose approach. Hence, in designing a system, the class of problems to be solved is often chosen so that the differences from one problem to another will ca\ase a relatively insignificant change in approach, and thus, in system performance. Unfortunately, when the system is implemented, certain system characteristics (core space, data structure, etc.) usually decrease the acceptable problem class. In addition, implementation of the analysis proceedures usually makes use of many element dependent characteristics, such as in electrical network analysis programs. That is, an electrical network analyzer cannot do much with a chemical cracking plant piping network, althougti both are topologically similar. Naturally, the class of acceptable problems is further reduced; the user's "particular problem" becomes very particular indeed. Presently, most systems support special purpose graphics interfaces to at most a few special purpose analysis packages. 2 FOOTNOTES Be firming with Sutherland's classic "SKETCHPAD" in 1963, graphics terminals and their applications as flexible man-machine interfaces have been speedily proliferating. Interested readers shotild scan such publications as Datamation, Computers and Automation, Informa- tion Display, and IEEE Spectrum to get an idea of the hardware/ software commercially available. For a state-of-the-art view, a good starting point would be AFIPS, and ACM Conference Proceedings as well as proceedings from special interest conferences, such as the recent "Pertinent Concepts in Computer Graphics," University of Illinois, March 19^9 . A historical perspective of graphics in the computer field can be obtained from articles such as the one by Hobbs . The adage "everybody's doing it" applies directly; almost every technical journal in any field contains articles about simulation of phenomena peculiar to that field. Areas of application range from the obvioiJS (aircraft design and circmt analysis), to the more obvious (business management and stock market trends). Places to look besides specific professional Journals include the communications of the ACM, Simulation, and IEEE Proceedings. GeneraJ. articles include those by Harmon, Blake, and Shigley. Typical systems include aircraft design (Lockheed), automotive design (General Motors), NASA space simulation (General Electric), electrical circuit analysis (ECAP variations), IC design (MIT), ship building design (CDC), chemical cracking networks (Brown), ad infinitum. Simply look for simvilation studies; a graphical implementation is often included. The DEC 338 and IBM 1130-MOD IV are typical examples of the low and high ranges, respectively, of such systems. II. A DESIRED ENVIRONMENT The goal in designing a graphical sim\ilation system, as indicated in the previous section is l) to use a hardware configuration that reduces the cost per terminal while maintaining the capabilities and response of a dedicated system, and 2) to enlarge the class of acceptable problems that the system can deal with. This is Just the universal "more product for less investment" goal; the question is the usual~HOW? Until the time that a small CPU and display console can be built economically as a single \init to be attached directly in time- sharing mode to a central CPU, the use of an intermediate satellite CPU will be necessary. However, as previously discussed, several deficiencies exist in present graphical console, satellite CPU, central CPU configurations. To alleviate these, the following provisions should be made : 1. The satellite drives a multiple number of consoles. 2. The satellite has a local mass storage facility. 3. A high speed data link exists between the two CPU's. Supporting many terminals with one satellite will drive down the average cost. Local mass storage reduces the need to access the central library. A high speed data link makes central library accessing and other necessary data transfers low in cost with respect to time. Two main problems in supporting a multi console environment are initial picture generation and picture refreshing for each individual console. During picture generation, a large amoiint of data manipulation is necessary, along with a high frequency of library accessing. Hence, T if the satellite is "busy generating a picture for one console and a second console requests service, the response time at the second console will be greatly delayed. Moreover, all the data structures associated with the current pict\ares on the consoles will not fit in the satellite's core simultaneously. For picture refreshing, a display file must "be continuously available to drive the console CRT. With multiple terminals, there will not be room in the satellite's core for all of these necessary files either. These considerations lead to the conclusion that the display data structures and at least a sub-library reside on a local mass storage device so that particular items needed at any time can be obtained relatively quickly. In addition, the display files for picture generation and refreshing must reside on some mass storage device, preferably, one that can automatically refresh the pictures on all consoles without use of the satellite .CPU. This last notion, in turn, necessitates a controller to interface the satellite CPU with a mass storage device and the individual tenninals , performing such functions as regenerating the displays, changing appropriate display files when requested, and queuing all terminal interrupts. If possible, one mass storage device for all the functions mentioned (library storage, data structure storage, display file storage) would be preferred. The resulting hardware configuration desired is presented in Figure 1. Terminal Ibntrollerj Mass Storage Figure 1. Hardware Configuration , Graphics Terminals Since graphics consoles are being \ised, the acceptable class of problems should be anything that can be represented on the display surface for which the user can describe the various elements and their inter- connections. Thus, for example, the system should handle an electrical network, or a piping network, or a bridge, or two levers, or a horse race, or a glop of cytoplasm, assuming that the respective users can supply the appropriate equations, parameters, and constants. A somewhat detailed description of one way of providing this information is presented in a paper by C. W. Gear cited in the Bibliography. In general, the system should allow a user to create any kind of a pictorial element, define its action with any combination of equations, constraints, connection points, constants, parameters, etc., and then use these elements to represent his particular problem. Of course, if a set of elements such as resistors, capacitors, etc., for a particular type of problem has been previously defined, this set will be available in the library system for other users, who simply connect them as appropriate and supply new parameters. The data structure representing the completed problem state- ment is then sent to the central CPU for analysis. In order to provide analytic flexibility in the centraJ. CPU for such a problem class, two approaches can be taJcen. First, many analysis prograjns for certain restricted types of problems currently exist. These programs usually assume some type of symbolic input and range from non-interactive to highly interactive. A table-driven or compiler- compiler designed symbolic manipulation interface program could scan the problem data structure, and create symbolic input for whichever analysis package the user may have specified. This would make a fast special purpose package, rather than a slower general package, available for the problem — assuming such a package for the problem exists at all. The output from these programs, whether interactive or not, could then be sent to an applications drawing program which would produce a data structure suitable for creating a display on the terminal. So the input, analyze, and output cycle is complete. On the other hand, packages do not exist for many problem types. In this case, a general purpose package (differential equation solver) must be ijsed. But here the symbolic manipiilation interface need only produce one type of output, although the type of syntax and other checking performed by it may be considerably more complex than in the case described above. The output from this type of analysis package would also be passed to an application drawing program to comm\micate results to the terminals. Actually, there is no reason why both approaches cannot be used in the system, leaving the choice to the individual user as best s\aits his needs. 10 The software environment in which the three essential analysis coniponents (namely, symbolic manipulation interface, analysis packages, and applications drawing package) must operate has been stated and in^jlied in this and the previous section. To review and restate briefly, l) communications and control executives must be in operation in both the central and satellite CPU's, 2) an information retrieval facility must be available to both CPU systems with a permanent main library in the central computer and an optimized temporary sub-library in the satellite, and 3) a data structure management and display file generation facility with drawing, picture/subpicture , tex±, and prompting facilities must be available in the satellite for direct communication with each terminal user. In addition, the executive system of the central CPU must utilize temporarily uniised resources allocated to support of the satellite in order to improve the efficiency of the central CPU. One way of accomplishing this last requirement is to provide for the rxmning of background utility packages whenever space is not being entirely taken up by symbolic manipiilation, analysis, or drawing packages. Explicitly, terminal users could send commands to a sub-monitor to operate on some previously constructed symbolic file. This file contains control and source information similar to a batch input stream, and the sub-monitor schedules translators and processors for execution accordingly. If communication were established between the graphics support executive and the time-sharing executive, this facility would be opened to all non- graphics terminals in the system, and the files used could be conveniently located in the time-sharing filing system. Furthermore, certain types of problems can be stated on an ordinary keyboard type time-sharing terminal, such as algebraic analysis, language translation, etc. This input co\ild 11 be interfaced to other analysis prograrns in the simiilatlon system. Hence, the system could support the maximum facilities that any particular terminal can handle, while increasing the availability of the system from a limited number of graphics users to all terminal lasers. The desired software configuration is presented in Figure 2. Central CPU Operating System Batch Hme-Sharing XGraphics Satellite CPU ' \ 1 \ 1 I 1 1 I 1 Graphics Communication and Control T-S Drawing Utilities lommuni cation and Control r^ Data Structure Management I Display File Generation ■^ Mass Storage Figure 2. Software Configuration Graphics Terminals Mass Storage 12 FOOTNOTES An alternative is to use storage tubes, but these add the problems of resolution, decay, inability to partially update a picture, erase time, higher cost (typically), etc. However, some systems using this technique have been built, particularly the one by Engelbart, Stanford University. 2 A good example of a state-of-the-art general differential equation package is the ODESSY system under development at the University of Illinois, Department of Con^uter Science (c.f. Dill, C. et al.). 13 III. PROPOSED SYSTEM—AN OVERVIEW A. Hardware The GRAS System, cvirrently imder development to meet the previously mentioned requirements, utilizes the following hardware in a configuration identical to that in Figvire 1: PDP8 as the satellite CPU Display Processing Unit (DPU) as the terminal controller Eight Graphics Terminals with Joystick, keyboard, and function keys Head per track disk as the local mass storage device 2701 Parallel Data Adapter for data transmission 360/75 as the central CPU In particular, the PDP8, 2701, and 360/75 are only being used in the prototype system because they are available; the disk, DPU, and terminals are inhoiise pieces of equipment whose designs have been geared to the requirements of the project. The PDP8 is a general purpose computer with four Uk banks of 12-bit per word core memory and I/O interrupt facilities. It interfaces with the DPU, disk, and 2701 as well as with a teletype console and a low speed printer. The DPU takes a standard display file (in this case, 338 code) from PDP8 core and executes it, thus producing a 3-bit incremental code to drive a terminal CRT. Decoding logic at the terminal interprets this 3-bit code, moves the CRT beam accordingly, and thus produces a visible image. The display file is "executed" by the DPU only once; the resulting incremental code is stored on a track of the disk (each terminal lU is associated with one particular disk track). Subsequent refreshing is done directly from the disk by feeding the contents of the appropriate track to each terminal's decoding hardware, all simultaneously and without interrupting the CPU or using CPU core. The DPU also queues interrupts from the various terminals and passes this information to the PDP8 on demand. Hence, different displays can be continuously serviced, changed, and refreshed at a multiple number of terminals without overloading the PDPS's interrvipt struct\ire or available core. Each terminal has a CRT, joystick, keyboard, and fxmction keys. The joystick, which replaces the use of a light pen for inputting XY coordinate information, has a locally produced (i.e. local to the terminal) cursor indicating its position on the screen. However, an interrupt occurs, making XY information available, only when a button is pressed. So the user can move his cursor all over the screen without bothering the CPU until he really wants to. Unlike a light pen, the joystick can be used to input XY information from blank areas of the screen; hence, the pen tracking problem, and the associated high density of interrupts is eliminated. A "dxunnQr generation" (i.e. comparator) mode is available in the DPU, enabling access to display file status and addresses in the manner xisually available with standard display devices. (The joystick could be directly replaced by a data tablet using a discrete interrupt type pen.) Keyboard input is buffered and displayed locally, one line at a time. That is, the user can view the current line being typed and will interrupt the CPU only when the line is completed. As previously mentioned, all terminal interrupts are filtered through the DPU before reaching the PDP8."^ 15 The disk is a high capacity, high rate device with head-per- track hardware. Each of its 32 tracks contains about 100,000 bits — the equivalent of l6k PDP8 words (i.e. all four banks). The transfer rate is 2 usee, per word, so an entire bank (U096 words) can be brought into the PDP8 in an average time of about 25 mlsec. (at I8OO rpm yielding an average rotational delay of IT mlsec). Due to the head- per-track feature, all displays can be simultaneously refreshed, as mentioned in the DPU section. With hardware and software sectioning, this one disk performs all three mass storage fimctions mentioned in Section II. The assumption of eight graphics terminals is made for the following discussion, and it should be noted that each disk track is hardware divided into 12 sections. Eight of the 32 disk tracks are hardware allocated to the DPU for the refreshing of the eight graphics terminals. Each of the tracks appears to the respective terminal as a continuous streajn of 100,000 bits (33,000 incremental codes). Eight other tracks are software allocated for full-bank task switching. This space is used to save the current picture data structure, display file, and program status for each terminal as swapping in and out of core becomes necessary to service the various terminals. One track is software allocated for loadable systems programs needed in the PDPB. Each program is located at a specific track position for rapid read-in. The remaining 15 tracks are software allocated for library space. On these tracks, each sector is viewed as containing ten blocks of 128 PDP8 words each, or I8OO total blocks for the 15 tracks. Since reading and writing on the disk is possible by sector only, an additional "selective read" hardware facility has been 16 added. This allows any pattern, and particularly, as fev as any one, of the ten blocks in a sector to "be read sequentially into the PDP8. For exaniple, blocks 0, 1, 5, and 8 in sector k of track 10 could be specified, and blocks 0, 1, 5, and 8 would appear contiguovisly in PDPB core. Hence, since reading is the dominant operation involved in creating a display file, selective access to particularly small blocks in a relatively large local data base offers a distinct saving in computer time. The 2701 is a standard high speed transmission device with a data rate of about 0.5M cps . At this rate, an entire PDP8 bank can be read-in or written-out in about 50 mlsec, making significant data exchanges between the two CPU's relatively comfortable. The 360/75 (under MVT) , while supporting standard batch and time-sharing facilities, provides a permanent region for supporting the satellite CPU. In this region, coniputational power as well as access to extensive 231^ disk storage is available. Effective utilization of these resources while not in use for PDP8 requests is discussed later in this section. B. Software The GRASS software configuration is similar to that in Figure 2. A description of each component is presented after the following summary of a typical user's session. Support for the satellite in the central CPU and the satellite operating system have been previously initialized, and several users at other graphics terminals are variously creating elements, stating IT problems, requesting analysis, and viewing resiilts . The new laser activates his terminal and "signs-on" with valid identification information. After requesting that certain subsets of his personal library and of the general library be transferred to the local system, he constructs some new elements (personal), changes some old elements (personal) , and then begins defining a problem situation with both old and new, personal and general, elements. Later, he directs the system to update the central library with the new and altered items, to save the problem situation (really just an element in the library), and to purge the local system of the library items he requested (courteously leaving more local space for users still defining problems). Since he asks and finds that space exists in the background-utility job queue, the user passes the system the name of a batch-type file to be executed (he created this file at a standard time-sharing keyboard console that morning) . The user then specifies the interface and analysis packages that are required for the problem he has just defined and requests analysis of that problem to begin. While awaiting the resiilts, he is notified that his background job bombed due to incorrect control cards at statement 137. Requesting service as a tenrporary time-sharing console, the user corrects his file; he exits from time- sharing mode and finding the background job queue again low, re-enters his job. The results of the requested analysis have become ready, so he examines them, decides to change some parameters, and analyzes them again. This process continues until a satisfactory resiilt is obtained, after which the user requests hardcopy output (which is produced at some later time, offline). The viser requests that his new problem be added as an element in the general library and "signs-off". 18 When an interrupt occurs at a terminal, indicating that servicing of the terminal is reqviired, that interrupt is processed on several levels. First, the DPU tests to see if the interrupt type has been enabled, and if it was not, the interrupt is ignored (joystick inhibit, pushbutton disable, keyboard disable, etc.). Otherwise, the interrupt is queued by the DPU for processing by PDP8 software whenever the PDP8 is free. At the next level, when the PDP8 begins processing the interrupt, the PDP8 executive program first tests a software' status mask for the terminal. This mask, set by some program operating under the executive and currently handling communications with the terminal, can specify whether the interrtrpt is a Class I or Class II interrupt. Class I interrupts merely reset certain bits in the mask or raise various software indicators for the terminal. Processing of these interrupts (such as keyboard characters, or perhaps certain p\ishbuttons , etc.) only requires the executive, which clears the interrupt condition when finished. Class II interrupts (such as Joystick, end-of-line character, some other pushbuttons, etc.) require task switching. In this case, the required program (if not already present) and associated data structures for the terminal must be bro\ight into PDP8 core from the program (l track) and swapping (8 tracks) areas of the disk. At the final interrupt level, when the swap is completed, control is passed to the lower level communications program which examines the interrupt information in detail and performs the necessEiry operations (usually changing the picture at the terminal). This program then exits to the executive and processing of the next Class II interrvrpt begins. Note 1 that while the Class II interr\:^t was being processed, the executive could j still process all Class I interrupts that migjit have occurred. Vflien the _ { 19 lower program retiirned to the executive, it specified which banks of core were to "be saved for the terminal and any changes desired in the ici-minal mask. The above chain of events for interrupt processing in the satellite implies the activities of the major software con^jonents of GRA.SS at that end of the system. The executive (GLASP) is responsible for all interrupt scheduling in the PDP8. GLASP maintains the terminal masks and other terminal status information ( current program, bailks saved, etc.), initiates task switching, and provides software linkages between lower level programs and system utilities (remote data trans- mission, library requests, print requests, etc.). The lower level program (FLOG) manipulates picture data structures, creates display files, initiates action in the central CPU, and prompts the user at the terminal. Whether the data structiore was created by user interaction with FLOG on the PDP8 or by a program in the central CPU and then transmitted to the PDP8 is irrelevant. Hence, FLOG is the two-way link between the terminal user and remote analysis or utility packages in the central CPU. When FLOG needs data from the library — usually during generation of a display file — a call is created to the satellite portion of the information retrieval facility (GIRLS). Since the storage capacity of the disk at the PDP8 is relatively limited, the complete permanent system library must be located at the central CPU. Normally, requests to this permanent library are made by interface or application programs in the central CPU or by the portion of GIRLS resident in the PDP8. Use-count, protection, and hierarchy information in the central library is combined with space and contents information about the local disk whenever the PDP8 20 makes a library request. As mentioned, a user typically will request his own sub-library plus other subsets of the system library at the beginning of a session. The most often used items — consistent with protection, space availability, and items already on the local disk — will then be transferred to the PDP8. Thereafter, most items needed by the user will be readily available locally, and only occasional references to the permanent library will be made. Hence, GIRLS attempts to optimize retrieval in a double ended, unbalanced system. Swapping and program requests from GLASP and specific library requests for GIRLS are handled by a disk access software package (DOOFIS). DOOFIS provides routines for controlling the program, swapping, and library sections of the disk by sequential -block or track-sector-block numbering schemes. Inline coding is losed to move entire swap banks or program code at high speed on single disk transfers into the PDP8. Other routines handle selective-read (single transfer) or blocked- read (buffered transfer) and blocked-write (buffered transfer) requests to the library section of the disk. The flow of control in the support region of the central CPU is similar to that in the satellite. All input from and output to the PDP8 passes through an executive (GASP). Each input line from the PDP8 has a terminal identification character in it, and each graphics (or other) terminal has a control block associated with it. When an input line is received, GASP checks the respective control block (as indicated by the ID character) to see if a user has successfully "signed-on" yet. If one has not, the line is passed to a "sign-on" monitor for inspection; if one has, the block is checked for the presence of an attached subtask. If a subtask is not present , the line is sent to a control monitor. This 21 monitor performs functions for the terminal, such as passing commands to the background job queue, creating subtasks (any interface, analysis, applications, etc., programs), passing requests to the central CPU portion of GIRLS, and passing lines to the time-sharing executive. If a subtask is_ present, the line is enqueued for later passage to it (a special control character, however, can be used to cause the input line to be sent to the control monitor even when in "subtask mode"). Depending on the amount of central CPU core available, any number of systems terminals can be in any combination of control or subtask mode, with the backgroimd job processor running as well. Hence, if all terminals were "signed-on", but in control mode, the backgrovmd job processor woiold be making use of practically all of the resources allocated to graphics support — resources that ordinarily would be idle. The central CPU section of GIRLS is a permanent subtask of GASP, thus making it continually available for PDP8 requests or central CPU program requests. It contains all routines for updating, extracting, and monitoring (use-count protection, etc.) information in the permanent library. Although any program can be attached by GASP as a subtask for a terminal, the usual package contains an interface, analysis, and applications group; or a sequence of attaches will bring such a grouping into execution consecutively. This allows complete flexibility for the user to determine what interface and analysis routines he wishes to apply to his particular problem. An interface (SYMP) takes a data structure as input, converts it to symbolic strings or another data structure as necessary (depending on the type of analysis program that will be used) , and checks the result for 22 syntactic correctness. In converting the input data structure, SYMP may make calls to GIRLS to evaluate items used as sub elements. The finished information is passed directly for analysis or stored in a data set for the next attach (i.e. the analysis program is not yet in core). The analysis program (GEAR) can be of any type, accepting data in structured or symbolic form, interactive or non-interactive, etc. As output is produced it is sent to an applications program to be recon- verted to a data structure suitable for input to FLOG in the PDP8. Applications progrsums (GADS) used in the system can have picture-subpicture facilities and access to GIRLS, thus making them more powerful than most packages of this type. Optimally, there would be only one GAD used by all GEARs . To summarize briefly — by using generalized FLOG, SYMP, and GADS packages to link users with GEAR or the utility package, GRASS atten5)ts to enlarge the applicable problem class and eliminate much of the inflexibility prevalent in most current systems. By utilizing some special hardware (disk, terminal controller, and graphics terminals) in conjunction with a satellite-central CPU configiiration operating \inder suitably designed executives, GRASS attempts to mak.e a powerful graphics system available at a reasonable cost per terminal, while maintaining a high degree of dedicated service at the terminal and a high efficiency rate at the central CPU. 23 FOOTNOTE For a coniplete description of the functioning of the DPU and for additional information about the disk, consiolt the Masters Thesis by R. Hostovsky, Department of Computer Science, University of Illinois, Urbana, Illinois. 2k IV. GASP/GLASP A. Current Implementation The desired prototype configioration will not be available until sometime after January 1970. The DPU and terminals are in the design stage, and the disk hardware is being debugged and the software for it implemented. Access to a large CPU is restricted to a 360/50 via a low speed link through a PDP7 until the arrival of another 2701 PDA. 338 Graphics Terminal Standard Terminals Mass Storage Figure 3. Current Hardware Configuration Interim versions of GASP and GLASP (hereafter referred to as GRAFMON and UIM0N8, respectively) using the available configuration of Figure 3 have been implemented. Items to note are: 1. Only a single graphics terminal is attached to the PDP8. 2. Only a restrictive, low speed data link to the large CPU is available. 3. The large CPU is operating imder MET with a resident ASP system. 25 This interim conmimi cations system enables graphics programs in the PDP8 to interact with support packages in the 360/50, although the effectiveness and flexitility allowed is not comparable to that which will be typical in the completed system. After initiating GRAFMON support in the /50 CPU, the user brings UIMGNS into PDP8 core. He can then communicate directly with GRAFMON over the PDP8 teletype console, directing it to bring a specific module into the /50, to pass a data set to time-sharing, or to load a data set into PDPB core to run under UIMONB. Typically, the user would load a drawing program into the PDPB and a library module into the /50. He would then proceed to construct a problem situation on the 33B; the completed data structure wovild be trans- mitted to and stored by the library module. Control would be returned to UIMONB and GRAFMON, respectively. The user then requests an interface, analysis, and applications module (or requests, in order, each one separately) to perform the desired analysis whose results are stored in the /50 library. The process then continues in this fashion until satisfactory results are obtained. 26 B. 360 Section 1. General Description GRAFMON support for the 360/50 graphics area consists of a non-terminating monitor em,d a comprehensive set of communications, translation, and data definition macros for programs running under the monitor. The monitor consists of three segments: initiator modules, a permanently resident SVC, and a comm-unications module. The initiator modiile uses the SVC to save information about the graphics partition on a disk data set. Then the initiator overlays itself with a very small bootstrap module, which in turn brings in the commimi cations module. Data transmission between the 360/50 and the PDP8 is now possible, and the PDP8 can request certain functions, such as data set transmission, linkage to the Time-Sharing partition, and load module execution. To execute a load module (e.g., analysis, interactive, or utility programs), the commvuai cat ions module overlays itself with the desired module. Upon normal termination of the called module, control is retxamed to the bootstrap, which loads in a fresh copy of the comm\mi cations module, and the process continues. If, however, the called module abnormally terminates, control is passed to the MFT ABEND module. Due to the SVC, and some changes in ABEND, the graphics partition is rebuilt using the information stored by the initiator on the disk. Control is passed back to the bootstrap, and processing can still continue as if the ABEND had not occurred. 27 2. Macros The following macros are available to 360/50 programs for commtini cation with the PDP8 via the PDPT: PDP7IN —call PDP7EXCP to input data PDP70UT — call PDP7EXCP to output data PDP7TR —call PDP7EXCP subroutine for data translation PDP7EXCP —perform I/O operations nDC — assembly time macro for defining data and character strings A complete description of each macro is contained in Appendix A; a brief description follows here. A detailed siommary of 360-PDP7-PDP8 communication characteristics is cQ'Htained in Appendix C. PDP7IN creates a calling sequence to an I/O routine in PDP7EXCP. This sequence specifies the data input location, the amount of data expected, and the addresses of error routines. Similarly, PDP70UT creates a corresponding sequence for data output. As mentioned, PDP7EXCP contains the actual I/O routines needed for commijnication. These routines start the I/O operation, wait for completion, check for errors, and move data as appropriate between user areas and their own buffers. PDP7TR provides the data translation facilities necessary for converting 360 formatted data into PDP7-PDP8 formatted data (c.f. Appendices C and D). The user specifies one of eight translation types, the location of the data, and the length of the data. Translation is performed in_ place . 28 nDC defines character and numeric data at aaseinbly time in PDPT-PDP8 format. Hence, data known to "be needed in advance does not have to be translated during execution. This is particularly usefiil for specifying error messages, display files, etc. The macro has default input and output character sets, but these may be overridden by the user. C. PDP8 Section 1. General Description The UIM0N8 monitor system provides routines for communication among PDPB programs , 360 programs , and users at the PDP8 teletype console, as well as facilities for the general convenience of all users. UIM0N8 resides entirely in bank 3 of the PDP8. Also, all of bank 1 is used as a buffer area when the text editor is being used, and the first three words of bank are used to link to the interrupt handler. Locations through i+TTT of bank 3 contain the UIM0N8 program. The area from 5000 through 5TTT is reserved for user routines (page zero of bank 3 is completely filled with constants and save areas for the UIM0N8 system; users may use the constants and pointers , but may not use any of the storage areas) and the area from 6000 through 6tTT contains the character generator (part of the remaining area is "FREE" space to be used by a larger character generator with the last couple of pages in core being reserved for the resident routines of the future disk facilities). Programs running under UIM0N8 operate in banks 0, 1, or 2; use the UIM0N8 interrupt handler for interrupt processing; and uses the UIM0N8 transmission routines for sending and receiving data. 29 After UIM0N8 is in PDP8 core, it can be directed to enter one of several modes. The first allows direct teletype communication with GRAFMON. In this mode, the user specifies modules to be loaded into the /50, into PDP8 core, or sent to time-sharing. Another provides a local graphics text-editing facility for bviilding sym- bolic files. These files can be printed on the teletype, stored on magnetic tape locally, or sent to the time-sharing filing system. A third mode stores specified PDPB core images in time-sharing files. These "programs" can then be reloaded into the PDP8 at a later time and executed. Finally, the 338 can be used as a high speed graphics time-sharing console. When UIM0N8 "exits" back to the PDP8 operating system, only control has been lost; the program itself is still in bank 3. Hence, the user can specify another PDP8 program to be loaded into banks 0, 1, or 2. This new program, in turn, simply restores words 1, 2, and 3 of bank (for the interrupt handler) and turns the PDP8 interrupt hardware on. The user program is now running "under" UIM0N8 and may use any of its communication and interrupt facilities. 2. Routines The following routines are available to programs running mder UIM0N8 in the PDP8: For processing all individual device interrupts INTHND For sending data to the 360 system ASYSMSG PSYSMSG 30 For receiving data from the 36O system MSGES LOAD For communicating with the user via the teletype SYSMSG SYSERR The system interrupt handler is table driven, utilizing two tables: one with clear-flag or test-flag lOT's and the other with corresponding device routine addresses. Hence, to ignore interrupts from a particular device, it is merely necessary to change a test- flag lOT in the first table to a clear- flag lOT. Then, if an interrupt occurs from that device, the flag will automatically be cleared and a branch to the device routine will not be initiated. The converse procedure is used to accept interrupts from vario\is devices. Clearly, if a user desired to handle interrupts from a particular device (such as the light pen) himself, all that is necessary is for him to save the system routine address in the second table and substitute the address of his own routine. This is one of the main reasons for reserving part of bank 3 for user routines, i.e. for use by user's interrupt routines. Hence, each Mser who wishes to use any of the peripheral devices of the PDP8 need not construct his very own interriipt handler, but need only write routines to handle interrupts from devices for which system routines do not meet his speciaJ. needs (c.f. descrip- tion of interrupt tables. Appendix E). 31 For commToni eating with the 360 system two buffers for input and output, named respectively SBUFF and UBUFF, are main- tained along with several flag words. A special "FILTER" routine (GM0N8) looks at every input line from the 36O to see if it begins with a valid control character. These control characters cause the input line to be passed to a particular routine associated with each character. Hence, a form of message switching is obtained; that is, information can be sent intermittently to varioios routines in the PDP8. As an example, assume an interactive graphics program is running in the PDP8 with an analysis or interpreter program in the 360. If the 36O sent a line to the PDP8 with an invalid control character, the line (assumed to be a system message) woiold be automatically printed on the teletype and the user could type a coded response (c.f. description of SYSERR routine. Appendix B). The 360 program could have specified the control to call "LOAD", in which case the input line is assiomed to be data in core load format. This type of input (being data directed in nature) coiold have replaced part or all of the current display file, set switches for the execu- ting program, or could have consisted merely of input data to go into a user's own input buffer, or do anything else that a clever user might desire. Or, the 36O might have sent the control for entering the debugging package; or the 36O might have sent the control indicating that the input line was to go to the current input routine which might have been some other system routine or a particular routine 32 of the user. All of the above input operations are performed with no effect on the currently executing program in the PDP8. In addition, since the control characters are associated with routines via a table, the user can add new ones or redefine old destinations, etc. It is hopefully obvious at this point that input from the 360 to the PDP8 is handled practically on an automatic basis with the main constraint being that the input data is of the proper format. Hence, the major programming of input formatting winds up being done in the 36O , where clearly programming is much easier for the average user. (in addition, when FORTRAN and PL/I interfaces are provided at the 360 end — work in progress — easy communication will exist for just about anyone.) For transmitting data to the 36O, things are a bit more complex, but equally as flexible for the PDP8 user. To send core image data, i.e. data that may represent any bit pattern, the routine PSYSMSG can be used. This routine can be called from any bank and will send a core block to the 36O as specified by the length, bank, and starting address information supplied in the calling parameters. Each PDPB word is converted to two 8-bit characters to insure that no PDPT control characters are accidentally transmitted (c.f. descrip- tion of PDP8 data formats. Appendix D, and PSYSMSG routine. Appendix. B). To send ASCII character data to the 36O, the routine ASYSMSG is provided. This routine assumes that UBUFF contains a control chajracter of the user's choice followed by the ASCII message (one 33 character per word), followed by a carriage-retiim. The utility of this routine is made much clearer by the descriptions of the SYSMSG and MOVEDT routines. 3ii V . CONCLUSIONS Although the system outlined in this paper and the sections implemented so far indicate to the author that this will prove a viable solution to the problems discussed, it is, ion fortunately, still too early in the implementation stage to state conclusively that the final system will indeed prove successfiiL. 35 BIBLIOGRAPHY Blake, K. and Gordon, G. "Systems Simulation with Digital Computers," IBM Systems Journal, Vol. 3, No. 1, I96U. Dill, C, Ellis, C, Gear, C, and Ratliff, K. "The Automatic Integration Package for Ordinary Differential Equations," Department of Coraputer Science File No. 779, University of Illinois, Urbana, Illinois, I968. Gear, C. W. "An Interactive Graphic Modeling System," Department of Conrputer Science File No. 3l8, University of Illinois, Urhana, Illinois, I969. Harmon, H. H. "Simulation as a Tool for Research," Systems Development Corporation, Santa Monica, California, SP-565, I961. Hobbs, L. C. , ed. "Progress in the Computer Field," Computer Group News of the IEEE, Vol. 1, No. 7, July 196 7. Hostovsky, R. "Design of a Display Processing Unit in a Mult i- Terminal Environment," Masters Thesis, Department of Computer Science, University of Illinois, Urbana, Illinois, I969. Shigley, J. E. "SimTilation of Mechanical Systems," McGraw-Hill, New York, New York, I967. 36 APPENDIX A 360 Macros For all macros, 0S/36O linkage conventions apply. A detailed a-uimnary of 36O-PDPT-PDP8 I/O conventions, formats and restrictions appear in Appendix C. 37 MACRO CALL: latel PDPTIN AREA=label,LEN=m,MSG=label,ERR=la'bel,SOP=label,EXT=Y Description: This macro causes the next input record from the PDPT to "be put into core at the location specified by the AREA operand. The amovint of data passed to the user is equal to the (HEX) niomber of bytes specified by the LEN parameter plus one , the last character being a carriage -ret urn (X'8D"). If 80 column card images were expected, LEN=80 should be coded and 8l characters would be transferred. (When scanning an input string, the user need only scan for the carriage- retiim rather than keep a character coxmt. Also if the string were shorter than expected, a carriage -ret urn from the PDP8.will appear earlier in the record indicating the end of the line. Of coiirse , if the record length is \jnknown, a request for a maxim\im length record is best.) LEN must be <_ 125. Both AREA and LEN may be specified as residing in registers, e.g. AREA=(5) means the address of the input area is in register 5. LEN=(6) means the length of the input request is in register 6. The input operation can have three possible results: success with data received, success with a system code received, or EXCP channel-error (very rare). Three corresponding parameters may be coded. For any not coded control passes to the next sequential statement after the calling sequence. SOP=lab — control passes to "lab" if data successfxilly received . 38 MSG=lab — control passes to "lab" if a system message is received. In this case, bytes and 1 (A and B) instead of data bytes are placed in the first two bytes of the loser's input area for examination. ERR=lab — control passes to "lab" if channel- error occurs. Best action is to assume line lost and indicate same to user with sysmessage facility. Hence, effect retry. If EXT=Y is coded, the appropriate linkage for an externally defined PDPTEXCP CSECT will be generated (c.f. PDPTEXCP macro). 39 MACRO CALL: label PDPTOUT AREA=label,LEN=in,ERR=label,SOP=label,EXT=Y, SYS=nn, MON=nn Description: This macro caioses the output record at the core location specified by the AREA operand to be sent to the PDPT. The amount of data passed to the PDP7 is equal to the (HEX) n\imber of bytes specified by the LEN parameter. LEN must be <_ 12U. Both AREA and LEN may be specified as residing in registers (e.g. PDP7IN). The output operation can have two possible results analogous to the read operation: success with data sent, or EXCP channel-error (very rare). (c.f. PDP7IN for a description of ERR and SOP.) The action of EXT=Y is identical to the PDPTIN case. The data line sent to the PDPT is formatted: AB[NX. ..X CR— Junk— ]CR 01 23 k k+1 k+2 126 127 where A and B are PDPT- 360/50 system coxmauni cation bytes, N is the PDP8 graphics monitor byte, bytes 3 through k are the data bytes, byte k+1 is a carriage -return (X'8D') inserted by PDPTOUT, bytes k+2 throiigh 126 are junk from previous operations (these are ignored by the PDPT) , and byte 12T is a mandatory carriage -re turn (X'8D') inserted by PDPTOUT. If 12i| data bytes had been specified, there would be no "junk" bytes, and the carriage -re turn at bytes k+1 and 12T woiold coincide at byte 12T. The SYS and MON operands are used to specify bytes B and N. kd For SYS: 00 = Time Sharing OFF 01 = Time Sharing ON 02 = Log In 03 = Log Out OU = Data Line For MON: 8U = Input Data A3 = System Message 80-83, 85-86 = System Options NOTE: User default options are SYS = OU, MON = 8i+. The user may specify MON = A3 for transmitting lines to the system message device. All other codes are for systems maintenance and are password protected at this time. MACRO CALL: PDPTEXCP EXT=Y,DDNAME=PDPTDD Description: This macro actually perforins input/output operations with the PDPT when called via PDPJIN and PDPTOUT. PDPTEXCP must be present if either PDPTIN or PDPTOUT is used, unless EXT=Y is coded for PDPTIN and PDPTOUT. Then PDPTEXCP with EXT=Y must appear in another CSECT in the same load module. The DDNAME operand specifies the name of the DD card that indicates UNIT=PDPT to the operating system, with the default DDNAME being PDPTDD. PDPTEXCP should be the last statement in an assembly or if it is not, any statements that come after must be named as a new CSECT. 1*2 MACRO CALL: label PDPTTR n ,LAB=latel ,LEN=m,EXT={X,Y} Description: Depending on the first operand, n, this macro translates blocks of data (<_ 256 characters) at run time from one format into another. The LAB operand specifies the location of the block to be translated, and LEN specifies its length in (HEX) bytes. Both LAB and LEN may be specified as registers (c.f. PDP7IN). On the first occurrence of a call for each type of translation where the EXT operand is not coded, the translation table and/or routine is generated in addition to the calling sequence. Each subsequent call for a particular translation type results in only the calling sequence being generated. If EXT=Y is coded, only the calling sequence is generated and the translation table and/or routine is assiomed to be externally defined. If EXT=X is coded, only the translation table and/or routine is generated and calls are assumed to be externally defined. (NOTE: PDP7EXCP and all the translation tables and/or routines could be put in one central "input/output" CSECT. Other CSECTS would only need to use the calling sequences, PDPTIN, PDPTOUT, and PDPTTR. There are eight translation types defined at present: n = 1 — translates from EBCDIC to ASCII. 2 — translates from EBCDIC to coded (6 bit) ASCII. 3 — translates from EBCDIC to coded (6 bit) BCD 1^3 k^ — translates from /360 half words (right 12 hits) to pairs of coded (6 hit) hinary. 5 —ASCII to EBCDIC. 6 —coded ASCII to EBCDIC. 7 —coded BCD to EBCDIC. 8* — coded hinary pairs to /360 half words . For n=l, 2, 3, 5,6, orT carriage-return (X'8D') and line feed (X'BA') are preserved hy the translation. For example, if X'8A' is the last hyte in an EBCDIC string heing converted to 6 hit coded ASCII (n = 2), the corresponding hyte in the resultant string is still X'BA'. * LEN is the number of half words to he transmitted. kk MACRO CALL: label nDC 'message ' ,{OWN=} Description: This macro allows data definition at assembly time of ASCII, coded ASCII, coded BCD and octal data, depending on the character n. Forms : *n = A — define the EBCDIC characters enclosed in apostrophes as ASCII character data (i.e. lab ADC 'IJK' becomes lab DC X'C9CACB'). *n = B — define the EBCDIC character enclosed in apostrophes as coded ASCII character data (i.e. lab BDC 'ABC becomes lab DC X'8281|86'). % = C — define the EBCDIC characters enclosed in apostrophes as coded BCD character data (i.e. lab CDC 'ABC becomes lab DC X'E2EUe6'). n = — define the octal nijmerals as four digit octal nximbers in 6 bit coded binary (i.e. lab 0DC 173 becomes lab DC X'82F6' ). n = D0 — define the decimal number as one four digit octal number in 6 bit coded binary (i.e. lab DODC 123 becomes lab DC X'82F6'). * " or 8e& used to define ' or & may not be split into two card images. k3 The OWN operand is valid with n = A, B, C, only and can be used to redefine the output character set of an nDC definition. The OWN operand specifies: l) that an internal redefinition is being performed (and not a data definition), and 2) the number of characters in the message that replace each character in the output character set. For example, ADC ' C10102C3' ,0WN=2 would cause the output equivalent of B, C, and D for subsequent ADC definitions to be changed from C2 , C3, and Ck to 01, 02, and 03, while keeping CI for A and all the other character definitions as previously defined as well, i.e. before ADC 'ABCD' became DC X'C1C2C3C5'; now, ADC 'ABCD' becomes DC X' C1010203' ) . Also, the user may change the standard character set if he desires by use of the STAWTAB L, message macro. For example, STANTAB 1, '3^+5' would change A, B, and C to 3, 1+, and 5, i.e. formerly ADC 'ABCD' became DC X'ClC2C3Cl|' now ADC '3U5D' becomes DC X' C1C2C3CU' ) . Hence, the user may completely alter the character definition facilities if so desired. (NOTE: l) any character set may not exceed 150 items, 2) replacement by use of OWN is character by character beginning with the first character group in the OWN "message" replacing the first character result in the output set and continiiing sequentially only until the "message" is exhausted. Hence, resultant groups in the output set not affected by the OWN "message" remain as previously defined. Users must exercise care in changing the character sets to insure that mixed length definitions within a set are not created, 3) error checking is difficult and expensive for this macro and is not extensive: xisers are urged to be very careful and follow procedures for its \ise closely ) . 1+6 APPENDIX B UIM0N8 Routines hi All user-oriented routines in the UIM0N8 system assume a JMS type call with the "IF" field set to 30 and the "DF" field set to the calling bank, i.e. the called routine will return to the user's program with the "IF" and "DF" fields set to the value of the "DF" field at the time of the caJLl. ROUTINE : ASYSMSG FUNCTION: Send a line of ASCII characters to the 360 CALLING SEQUENCE: ACC = Nximber of characters to be sent (including a trailing carriage-return) DESCRIPTION : The routine assumes that a line of ASCII characters with one character per word is already in UBUFF. This line is sent to the 360. If an error in transmission occurs, or if at sometime during the transmission the 36O sends a message to the PDP8, this message will be printed on the teletype followed by the sequence "CODE:". If the user types a zero, the transmission operation will be terminated. However, any other character will cause the operation to be retried. UBUFF may be filled by the user with the aid of the "MOVEDT" routine or the SYSMSG facility (c.f. the descriptions of these routines). NOTE: No output line may exceed 125 (DEC) characters, including the carriage-ret\am. k6 ROUTINE: PSYSMSG FUNCTION: Send a line of core image data to the 36O CALLING SEQUENCE: ACC = Number of PDP8 words to be sent PARAMl = LOG-1 of the data PARAM2 = CDF NN specifying the hank of the data DESCRIPTION: The routine ass\xmes that a user control character of some sort is in the first word of UBUFF. Each PDP8 word in the block to be sent is converted to two characters in the coded data format (c.f. description of data formats) and is placed into UBUFF following the control character. Then a carriage -ret Tim is added, and the line is sent to the 36O in the same manner — and with. the same error control — as with ASYSMSG. NOTE: Since no output line may exceed 125 (DEC) characters, the macim-um number of words in the block is 61 (DEC). h9 ROUTINE: MSGES (not iiser callable) FUNCTION: Receive system messages and put into SBUFF CALLING SEQUENCE: ACC = Last input character DESCRIPTION : The routine sets the "GOl" UIM0N8 system flag immediately (thus inhibiting system routines from sending data to the 630), and sets the "SYSFLG" when the entire message has been received. The input message will be printed on the current SBUFF printer when "UPRIN" (the system buffer controller — not user callable) or SYSERR (user callable) are called. 50 ROUTINE : LOAD FUNCTION: Insert loader - formatted data from the 360 into PDP8 core CALLING SEQUENCE: ACC = Starting address for data PAJRAM = CDF NN specifying the bank DESCRIPTION: The routine assumes that the input data is in loader format (c.f. data formats); hence, each input character is 6 bits of data or 6 bits of location information. The routine continues loading data until it receives an end-of-data character (211 octal). Since the input data can be of any amount and req_\aire more than one input line, carriage-returns and line feeds are ignored \antil the EOD character is received. The routine can be called explicitly by a user's program in anticipation of a data transmission from the 360. However, if the input is properly formatted, this routine will be automatically called by GM0N8 (the remote-input filter routine). With the automatic call feature, and with location information capabilities in the input stream, this routine provides an easy method for automatic data input, display file updating, switch setting, remote program loading, etc. NOTE: This routine is really a load-and-go routine with a few special switches and options. When the EOD character is received, the routine checks the contents of its core address pointer. If the pointer is not zero, the routine uses that information plus the current bank information as the starting address of a program and branches to it. If the pointer were zero, the routine simply exists to the program that called it. Hence, all blocks of data that are sent through the loader must have the final three characters before 51 the EOD character specifying new location information. This new location must either be the starting address of the program in the case of a program load, or must be zero in the case of a simple data load. 52 ROUTINE: SYSMSG FUNCTION: Communicate fixed messages to the user via the teletype and format output lines from the user's responses. CALLING SEQUENCE: ACC = N where N is a number > = specifying a particular message residing in a message table defined by the \iser at system initialization. DESCRIPTION: The routine assumes that a message table exists beginning at location 5000 in bank 3, i.e. at the beginning of the user's area. This table is placed into core by the viser, either by a call to move the table from the user's program in another bank, by a call to dectape, or by a call to the disk routine. If a response is expected, the routine places the resxilting teletype characters into UBUFF beginning at a location specified by the message table. Hence, by carefully constructing his table, the user can automatically format composite output lines from a particular sequence of related inqiiiries. The table is formatted as follows: SYSTBL -N Expected return count. UBUFF+M ADDR of retvim characters in UBUFF. MESS0-1 ADDR-1 of message. MESS0 MESSl (Characters in packed format) MESSK 53 The expected retiom coimt includes a carriage-retxim that the user will type to end his response. So, if a response of nine characters is expected, -12 would be specified. If the response that the user gave was only six characters instead of nine, the remaining character spaces in the UBUFF buffer would be blanked, and then the carriage- return woxold be inserted into UBUFF at the end of the nine character field. If the user tried to type more than nine characters, the message would be retyped. If the user typed a percent sign, the message would also be retyped. If the expected return covint is specified in the table as -1, no response is assiomed, and the result is that only a message is sent to the teletype with no effect on UBUFF. UBUFF+M (M> = $)) specifies where in UBUFF the response of the user is to be put. NOTE: UBUFF can hold a maximum of 125 (DEC) characters including carriage-retiim. MESS0-1 specifies the starting location of the message to be printed on the teletype. -L specifies the length in characters of the message. If the expected return covmt were -1, the system adds a line feed and carriage-return to the line printed. The table (K entries of four words each) is followed by the K variable length messages. NOTE: The user could specify some other buffer area in bank 3 as the recipient of the teletype responses; however, if the user does this , it is his responsibility to insure that no part of the UIM0N8 system is damaged. 5h ROUTINE : SYSERR FUNCTION: Test the system buffers and return a code to the caller CALLING SEQUDNCE: None (ACC assumed = 0) DESCRIPTION: It is possible that the 360 or the PDPT will at sometime send a message to the PDP8 which is unrelated to the user's program, i.e. time sharing off, et. al. If UIM0N8 is in time sharing or text editor mode at the time, these messages would automatically be printed on the teletype. However, in other modes (either system or user defined), immediate print-out would not necessarily occur, since printing is only done when a call to the system print routine is initiated. The con5)lete arrival of a system message is indicated when UIM0N8 sets its "SYSFLG" to nonzero. When called, this routine prints the system buffers, and then tests "SYSFLG"; if the flag were up (nonzero), the routine prints "CODE:" and waits for a teletype reply. This reply (a number zero through seven) is returned to the calling program in the accumulator, and the "SYSFLG" is reset to zero. Hence, the calling program has the option of taking various courses of action for any particular system message. 55 ROUTINE : MOVEDT FUNCTION: Move a block of PDP8 core to anywhere in the machine CALLING SEQUENCE: ACC = F0T0 (F=BANK FROM, T=BANK TO) PARAMl = ADDR FROM PARAM2 = ADDR TO PARAM3 = -COUNT (in words) DESCRIPTION: The data at the specified "FROM" address in the "F" bank is moved sequentially starting at the lowest core address, and is moved to the "TO" address in the "T" bank. The user is cautioned about overlapping fields and should note that the action of this routine is identical to a 360 MVC instruction. This is merely a utility type routine and is included as a convenience for all users . 56 APPENDIX C Features of 36O/5O-PDPT-PDP8 Communications 57 1. PDP8 to PDPT to 360/50 The PDP8 transmits or receives one character at a time to or from the PDPT at a maximum rate of 100 characters per second. As soon as the PDPT senses a carriage -re turn character from the PDP8 or when it has received a total of 125 characters without getting a carriage- return character, the PDPT considers the "line" of characters from the PDP8 to be conipleted. At this time the PDPT transmits a carriage- return followed by a line feed to the PDP8. The PDPT then tries to send the line to the 360/5O. When the 360/5O reads the line, and not before, the PDPT sends a bell-character to the PDP8 signifying that the PDP8 may send another line. If the PDP8 should try to send characters to the PDPT before receiving the bell-character, the PDPT immediately sends a carriage-return line feed, "#WAIT", carriage-return, line feed sequence to the PDP8. The format of the line sent to the 36O/5O from the PDPT is as follows: A,B[125 data bytes ]CR 1 2 126 127 Where A and B (bytes and l) are PDPT- 360/50 control characters, byte 12T is always a carriage-return, and bytes 2 through 126 are data bytes. If the PDP8 had sent 50 characters followed by a carriage -re turn, the line would look like: A,B[ CR Junk ]CR 12 51 52 126 127 58 2. 360/50 to PDPT to PDP8 When the 360/50 sends data for the PDP8 to the PDPT, the data format is: AB[N 124 data bytes ]C R 01 23 126 127 where A and B are PDPT- 360/50 control characters , N is a control character for the PDPB monitor system, and byte 12T is always a carri age-ret iim. If 50 characters were to be sent to the PDPB, the line would be: AB[N CR Junk ]CR 01 23 52 53 5k 126 127 The PDPT would send only bytes 2 through 53 to the PDP8, followed by an additional line feed (NOTE: When the PDP8 initiated a send, a line feed and a bell were returned; when the /50 initiates a send, only a line feed is additionally sent to the PDP8.). After sending one line, the /50 cannot send another line until the first has been completely sent (character by character) to the PDP8. Note that the PDPT assumes the PDP8 is a synchronous device; hence, the PDPT sends characters to the PDP8 at a fixed rate and the PDP8 must accept them at that rate. In order to know when this has been accomplished, the program in the /50 must issue a READ operation. In this case, byte 1 ('B') of the input indicates the disposition of the last line. (On ordinary input, B = 0, meaning the line is a data line.) The rest of the line is junk. If B is 1, then the output has all been transmitted to the PDP8. or 2, then the PDP8 has requested the PDPT to stop transmission before the entire line was sent, i.e. the remainder of the line has been volxontarily lost; or 3, then the PDP8 has "signed off." 59 Hence, to send several lines to the PDP8, the progrsan in the /50 must issue a read before every output operation (except the first) and check B for the proper setting. 3. Data Format Since certain characters, such as carriage-return and line feed cause the PDPT to take some action, data — particularly object code — cannot be sent 8 bits at a time from the PDPB; nor is 8 bits really convenient considering the 12 bit word of the PDP8. In addition, the 360/50 cannot send data in its original form to the PDPT either, since an inadvertant carriage return in the middle of the line would cause the PDPT to stop transmitting to the PDP8. Hence, all data (except pure character data sent only to the time-sharing system) is sent in a coded format, six data bits (half of a PDP8 word) per 8 bit character at a time. Since internal PDP8 characters are 6 bits and the transmitted form takes up 8 bits (l byte), conversion in the 360/6O to EBCDIC is very neat and clean. Numeric data is reformed into 360/50 half words, i.e. one PDP8 word of 12 bits becomes 2 bytes. In the PDP8 each incoming data byte is stripped of the excess 2 bits and every 2 characters are packed into one PDP8 word. 60 APPENDIX D PDP8 Data Formats 61 The UIM0N8 system works with three types of data — ASCII, packed ASCII, and Loader formatted. ASCII characters are stored one character per word in the right-most 8 bits. This data is always of a temporary nature, residing only in buffers just prior to being sent to the teletype or to the 36O , or just after having been received from those devices. Packed ASCII (really 6 bit trimmed ASCII corresponding identically to the right-most 6 bits of regular 8 bit ASCII characters) is used in the text editor display buffer, in all stored system messages, and is assumed to be the format of user messages stored in the user's area for the SYSMSG facility. When one of these messages is to be sent to the teletype, a system routine unpacks this data into UBUFF. Since the code is 6 bits, there are 6k valid print characters available in stored messages or for display in the text editor, except that three of these are control characters for the text editor. These three are line feed (33), carriage-return (3^), and escape data state (35), all of which should not be used by the user. Loader formatted data is used to pass arbitrary bit patterns into and out of the PDP8. Since certain characters are control characters for the PDPT/360 system (such as carriage-return), UIM0N8 must insure that such characters are not sent accidentally during the transmission of a data block. Hence, each PDP8 word of data is converted into two characters before being sent to the 360. Each character is of the form 1(6DATA BITS)0, with the top six bits of the PDP8 word going into the first character, and the right-most six going into the second 62 character. Naturally, data coining into the system by way of the load routine is of the same form. The only other characters in this type are carriage-returns (215 octal), line feeds (212), EOD (211), and origin characters (20X, where X is 1, 3, 5, or T specifying banks to 3, respectively). The only ambiguity in this setup is with line feed which could be mistaken for a data character. However, line feeds are only sent by the PDPT after a carriage-return at the end of each line, so by definition, 212 is only a line feed if it occurs after a carriage- return. Whenever an origin character occurs, the bank information is extracted and used as the current load bank for the input data, and the next two data characters are assumed to contain a new starting address in that bank instead of being data. 63 APPENDIX E UIM0H8 Interrupt Tables 6k As explained in Section IV. B. 2, PDP8 routines, the first table contains test lOT's for interrupts to be investigated and clear lOT's for interrupts to be ignored. The second table contains the address of the routine to be entered if the corresponding test lOT in the first table is successful. Both TORCL and INTLST appear as follows at UIM0N8 initial- ization, and the system assumes that the devices are in this order. TORCL 6031 60U1 6631 6132 7000 7000 7000 7000 631U 676U SZA INTLST KEYTS TPRTR GM0N8 LPEN IRTRN IRTRN IRTRN IRTRK IRTRN IRTRN PBHIT? PBHITS Ti:ST KEYBOARD FLAG TEST TELEPRINTER FLAG TEST 630 REMOTE FLAG TEST LIGHT PEN HIT FLAG CLEAR MMUAL INTERRUPT FLAG CLEAR EDGE FLAG CLEAR EXTERNAL FLAG CLEAR INTERNAL INTERRUPT CLEAR CLOCK INTERRUPT CLEAR DECTAPE FLAG TEST FOR PUSH BUTTON HIT KEYBOARD TELEPRINTER REMOTE FILTER LIGHT PEN NO-OP NO-OP NO-OP NO-OP NO-OP NO-OP PUSH BUTTON HIT IF PUSH BUTTON HIT, NO-OP NOTE: If none of the other devices caused an interrupt, PBHIT? is entered to clear the flag; then PBHIT? calls PBHITS if the flag was on. Hence, user's should change PBHITS and not PBHIT?. 65 APPENDIX F UIM0N8 System Locations 66 (All locations in iDajik 3) SYSTEM START ( "UTIL" ) 1000 ASYSMSG 1600 PSYSMSG l6li+ LOAD li;6i+ SYSMSG 1656 SYSERR 1731 MOVEDT 361k UBUFF 30 30 SBUFF 3230 SYSFLG OOOT The following routines may only be called by programs in bank 3, in the iiser's area, for example. SCSET 1211 (TS CONSOLE) LD36O 1235 (LOAD 360 PARTITION) LDPDP8 1261 (LOAD FROM 36O INTO PDP8) TEXTED 1306 (TEXT EDITOR) TERMS 1327 (UIM0N8 EXIT TO DECTAPE) SYSTEM INTERRUPT TABLES: TORCL li+OO (TEST OR CLEAR lOT TABLE) INTLST II4I3 (INTERRUPT ROUTINE LIST) 61 APPENDIX G Character Code Eq.uivalences 68 STANDARD TYPE A TYPE B TYPE C (EBCDIC) (ASCII) (CODED ASCII) (CODED BCD) A CI 82 E2 B C2 8U Ek C C3 86 E6 D Ck 88 E8 £ C5 8a EA F C6 8C EC G C7 8E EF H 08 90 FO I C9 92 F2 J CA 9k C2 K CB 96 Ck L CO 98 C6 M CD 9A C8 N CE 90 CA OF 9E CC P DO AO CE Q Dl A2 DO R D2 kk D2 S D3 A6 Ak T DU A8 A6 U D5 AA A8 V D6 AC AA w D7 AE AC X D8 BO AE Y D9 B2 BO Z DA Bk B2 BO EO 9k 1 Bl E2 82 2 B2 EU Qk 3 B3 E6 86 k BU E8 88 5 B5 EA 8a 6 b6 EC 80 T B7 EE 8E 8 B8 FO 90 9 B9 F2 92 NOT 87 BELL 87 BELL FA BELL UNDERSCORE 8A LF UNUSED FC LF CENTS 89 EOD 89 EOD 89 EOD PERCENT A5 CA FE ^ AE DC f6 < BC F8 BC ( AS DO B8 + AB D6 EO UPARROW DE BC AO AMPERSAND a6 CC 80 1 Al C2 9A $ au 08 D6 « AA .du d8 69 ) A9 D2 t > BB f6 AD DA / AF DE 1 AC D8 > BE FC 7 BF FE J BA fU NUMSN A3 C6 EACH CO 80 1 A7 CE a BD FA II A2 ■ Ck BLANK AO CO f8 BA CO A2 B6 BE Dl+ 9E Bk DA 98 96 9C 80 ALL TYPES A. B, AND C AKE IN HEX (I.E. A = 1010 BINARY) TO APPENDIX H JCL Examples 71 1. Basic JCL for assembling 360 programs with communications macros: /*ID // EXEC ASM //ASM.SYSLIB DD DSN=SySl.MACLIB,DISP=OLD // DD DSN=SYS3.MACLIB,DISP=0LD // DD DSN=USER.GRAPHICS,MACLIB,DISP=0LD,UNIT=23li+, X // V0LUME=SER=UIRUR1 //ASM. SYS IN DD * SOURCE DECK 2. To add the object code of properly assembled programs to the system, change the BXEC ASMLKED card and, after the /*, add: //LKED.SYSLMOD DD DSN=USER.GRAPHICS .LINKLIB(YOURNAME) , X // UNIT=23lU ,DISP=OLD ,V0LUME=SER=UIRUR1 3. Basic 360 JCL for assembling PDP8 programs with PDP8ASM: /*ID //JOBLIB DD UNIT=23li+,V0LUME=SER=UIRURl, X // EXEC PGM=PDP8ASM //SYSUTl DD UNIT=DRUM,SPACE=(TRK,(10,10)),DISP=NEW //SYSUT8 DD DUMMY //SYSUDUMP DD SYSOUT=A //SYSPRINT DD SYSOUT=A //SYSIN DD * SOURCE DECK /* 72 k. To put the object code into the monitor system, change the SYSUT8 card to read: //SYSUT8 DD DSN=USER.GRAPHICS.LINKLIB(YOUMAME), X // DISP=0LD,UWIT=23lU,V0LUME=SER=UIRURl 5. To pionch the object code on a paper tape on the PDPT in loader format, change the SYSUT8 card to: //SYSUTB DD UNIT=(CTC,, DEFER) and add the following ASP control cards before the JOBLIB card: /^PROCESS MAIN /♦PROCESS FILE /*FORMAL FI ,DD=SYSUT8,DEST=PUWCHT,C0NTR0L=SINGLE /♦PROCESS PRINT /♦ENDPROCESS 73 APPENDIX I GRASS Acronyms Ih Components of GRASS software support are: DOOFIS: Disk Oriented Operating and Filing System — for the satellite PDP8. FLOG: Facility for Local Online Graphics — individual graphics terminal support running under DOOFIS and GLASP on the PDP8. GADS: GraphicaJL Applications Drawing System — for 360/75 programs to create displays for the graphics terminals of the PDP8. GASP: Graphics Attached Support Processor — communications and monitor system for the graphics region of the 360/75. GEAR: Graphically Extended Analysis Routine — any analysis package running xinder GASP. GIRLS: Graphical-Information Retrieval and Library System — an IR facility with sections resident and active in both CPU's. GLASP: Graphics Locally Attached Support Processor — PDPS complement of GASP. SYMP: symbolic Manipulation Programs — interface and pre-processor fol: GEARs. m AEC-427 (6/68) ,ECM 3201 U.S. ATOMIC ENERGY COMMISSION UW!VERSITY-TYPE CONTRACTOR'S RECOMMENDATJON FOR DISPOSITION OF SCIENTIFIC AND TECHNICAL DOCUMENT ( See Instructions on Revene Side i AEC REPORT NO. COO-li+69-Ol44 2. TITLE GRAPHICAL REMOTE-ACCESS SIMULATION SYSTEM (GRASS) The Coimniani cation and Monitor Components (GASP/GLASP) TYPE OF DOCUMENT (Check one): rH a. Scientific and technical report [~1 b. Conference paper not to be published in a journal: Title of conference Date of conference Exact location of conference. Sponsoring organization □ c. Other (Specify) RECOMMENDED ANNOUNCEMENT AND DISTRIBUTION (Check one): nn a. AEC's normal announcement and distribution procedures may be followed. I I b. Make available only within AEC and to AEC contractors and other U.S. Government agencies and their contractors. I I c. Make no announcement or distrubution. REASON FOR RECOMMENDED RESTRICTIONS: 5 SUBMITTED BY: NAME AND POSITION (Please print or type) C. W. Gear, Professor and Principle Investigator Organization Department of Computer Science University of Illinois Urbana, Illinois 618OI Signature y(2*J". Date August 1969 FOR AEC USE ONLY 'AEC CONTRACT ADMINISTRATOR'S COMMENTS, IF ANY, ON ABOVE ANNOUNCEMENT AND DISTRIBUTION RECOMMENDATION: I. PATENT CLEARANCE: Q a. AEC patent clearance has been granted by responsible AEC patent group. LJ b. Repwrt has been sent to responsible AEC patent group for clearance. O c. Patent clearance not required. UNIVERSITY OF ILLINOIS-URBANA 510 84 IL6R no C002 no 343 348(1969 Internal rgport/ 3 0112 088398653 • f