LIBRARY OF THE 
 
 UNIVERSITY OF ILLINOIS 
 
 AT URBANA-CHAMPAIGN 
 
 dop. & 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/grasssystemsoftw468mich 
 
REPORT NO. U68 
 
 4^ 
 
 
 fYl^ti 
 
 
 GRASS: 
 
 System Software Description 
 by 
 M. J. Michel 
 
 August 1971 
 
 
 
 COO-1U69-0190 
 
 3RARY OF THE 
 
 SEP U |; 
 
 &IUP A-CHAMPAIGN 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 
 
REPORT NO. 1+68 
 
 GRASS: System Software Description* 
 M. J. Michel 
 
 August 1971 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 UNIVERSITY OF ILLINOIS 
 URBANA, ILLINOIS 6l801 
 
 * Supported in part by the Atomic Energy Commission under contract 
 US AEC AT(ll-l)lU69. 
 
TABLE. OF CONTENTS 
 
 Page 
 PREFACE 
 LIST OF FIGURES 
 
 1. LOCAL SUBSYSTEMS 1 
 
 1.1 General GLASP-Segment-GUTS Linkage 3 
 
 1.2 General Data Structuring h 
 
 1 . 3 Console Vector Detail 6 
 
 l.U Picture Control Block Detail 10 
 
 1.5 GLASP Routines 12 
 
 1.6 GUTS Service Routines lU 
 
 1.7 Program Segment Descriptions 26 
 
 2. REMOTE SUBSYSTEMS 36 
 
 2.1 G80PERAT 38 
 
 2.2 SPACT kk 
 
 FIGURES U6 
 
 LIST OF REFERENCES jk 
 
 APPENDIX 
 
 A. Buffering Control Program (ACID) 76 
 
 B. System Generation and IPL . 82 
 
 C. GLASP Routines— Detail 89 
 
 D. GUTS Service Routines —Detail 101 
 
 E. Program Segments 119 
 
 CALR (CALR1):0 120 
 
 GSAM (GSAMV1):1 123 
 
 GUT1 (TEXTHN):30 125 
 
 GUT2:31 129 
 
 GUT3 (REACT): 32 133 
 
 DEX1 (DEXCHK):33 138 
 
 PSIR (IRINIT):37 139 
 
PREFACE 
 
 An overview of the Graphical Remote Access Support System 
 (GRASS) is given in [l]. Reference [7] describes the operation of the 
 system from a terminal user's viewpoint. Reference [8] presents 
 facilities available to programs, executing under the remote portion 
 of the system, that communicate with the local terminals. All remaining 
 references provide additional background information concerning the 
 design and implementation of the system. Familiarity with the above 
 three references and with PDP-8 and 360 programming is assumed in the 
 document. The system's software (and this discussion) is divided 
 roughly into two sections: local (satellite) and remote subsystems. 
 
 The help of the following individuals who aided in the 
 development of portions of the system is great fully acknowledged: 
 Mr. R. Haskin (PDP-8/I terminal handler), Mr. H. Levin (PDP-8 filing 
 system), and Mr. A. Whaley (360/75 filing system). 
 
LIST. OF FIGURES 
 
 Figure Page 
 
 1. System Hardware to Software Relationships hj 
 
 2. Allocation of System Control and Work Areas U8 
 
 3. Console Vector Detail ^9 
 
 k. Picture Control Block (PGB) 50 
 
 5a. File Control Block 51 
 
 5b. Data Block Control Entry Detail 51 
 
 6. PCB Control and Data Structure Relationships 
 
 7. Line Block (No. 0) 53 
 
 8. Text Block (No. l) 53 
 
 9. Instance Block (No. 2) 
 
 10. Terminal Block (No. k) 55 
 
 11. Mnemonic Storage Block (M.S.B.) 56-57 
 
 12. Menu Block 57 
 
 13. Display Screen Composition Detail 
 
 Ik. Program Segment Allocation 
 
 15. G80PERAT Flow of Control (Part 1 of 2) 60 
 
 16. G80PERAT/Subtask Linkage (Part 1 of 3) 62 
 
 17- SPACT Flow of Control (Part 1 of 7) 
 
 18. SPACT/User-Program Linkage After S8EN TRY 72 
 
 19. SPACT Terminal Control Area Detail 73 
 
1. LOCAL SUBSYSTEMS 
 
 As shown in Figure 1, four subsystems plus "user level programs" 
 (hereafter termed "program segments" or "segments") comprise the local 
 section of GRASS. 
 
 The multi terminal monitor (GLASP) is responsible for all 
 device interrupts, storage allocation, and scheduling. Certain minor 
 functions such as operator console support and real-time clock display 
 are also performed by GLASP. 
 
 The Information Retrieval package (.IR) is used to maintain 
 data on the local mass storage medium, currently a disk. This data 
 includes: library file space, segment storage, and transient buffer areas. 
 In addition, a directory and sorted/unsorted block lists are held on the 
 disk. GLASP, GUTS, and the segments can all invoke execution of IR. 
 
 GUTS is a large collection of utility routines for handling all 
 device input/output and for manipulating data structure blocks. Routines 
 in GUTS may be invoked by program segments, either directly or via a 
 scheduler in GLASP. 
 
 Since the buffering controller (DPU) is currently a PDP-8/I 
 computer, a program to perform terminal handling (ACID) is needed. ACID 
 controls and interleaves display files being sent to the terminals, and 
 regulates the flow of keyboard/X-Y input coming from the terminals. In 
 addition, a dynamic buffer is maintained for each terminal to aid in 
 keyboard text-line preparation. 
 
 System response to user input is controlled by the segments. 
 The segments are, in fact, the driving force within GRASS. For example, 
 keyboard or X-Y (joystick) input from a terminal is handled as follows. 
 ACID notifies GLASP that DPU input from a particular terminal is ready. 
 GLASP examines the execution status of the terminal and of the segment 
 associated with that terminal. When the status indicates "accept input" 
 and "not busy," then execution of the associated segment will begin at 
 an entry point corresponding to "DPU input received." Other entry points 
 exist in this segment (and in all segments) for "timer interrupt received," 
 
"remote (2701) data record received," and "operator console input 
 received." The executing segment now examines the input and makes 
 an appropriate response. This might involve calling GUTS for data 
 structure manipulation or device input /output , invoking IR, or any 
 combination of such activities . The segment may also change its status , 
 such as -what input will be acceptable or what entry points may be 
 subsequently used. As soon as the response is completed, the terminal's 
 status returns to "not busy" and new input, if appropriate according 
 to the new status, will cause segment execution to begin again. Hence, 
 for a particular application, all that is needed is an appropriate 
 segment. Change the segment and obtain a text editor, a library inquiry 
 station, an algebraic manipulator, a graphical compiler, a drawing 
 program, etc. The operation of segments currently available is described 
 in [7]. 
 
 Figure 2 presents the allocation of GLASP, IR, GUTS, and 
 segments with the associated control/work areas in the satellite computer. 
 Each terminal is related to a console vector (Figure 3) and to a picture 
 control block (Figures k and 5). The console vector controls the status 
 of the terminal at any time and is the communication medium between GLASP 
 and the segments. The PCB, on the otherhand, controls the status of the 
 data related to the terminal and is manipulated exclusively by the Data 
 Structure Management (DSMN) routines in GUTS. The general format of 
 terminal data and the relationship of PCB pointers to that- data is 
 described in Figure 6. Certain standard data blocks are recognized (and 
 expected) by various GUTS routines ; these blocks are presented in Figure 7 
 through Figure 10. Two additional blocks defined for use by the system 
 are shown in Figure 11 (Mnemonic Storage Block) and Figure 12 (Menu Block), 
 
 IR is described in [6]. A functional description of ACID is 
 presented in Appendix A. Programs and procedures for generating and 
 loading the system are described in Appendix B, part 1. Critical areas 
 of the system itself are discussed in the following sections. 
 
1.1 General GLASP-Segment-GUTS Linkage 
 
 All code is permanently resident except for the segments — 
 only one segment can be in core at any time. All code is executed with 
 the CPU interrupt facility 0FF; the only time that a device interrupt 
 can occur is when GLASP is looping in an idle state with interrupt 0N. 
 
 Two types of GUTS routines are provided: indirectly and 
 directly callable. The first requires use of a device (disk, DPU, 2701, 
 etc.) for performing its service. Since the device might be busy servicing 
 another request, the segment must call the desired routine indirectly 
 through a scheduler (R0UTX) in GLASP. Once the request is made, execution 
 will not be resumed in the segment until the service is completed. The 
 second group performs immediate functions; since execution returns 
 directly to the segment, no contention can arise, so the segment may call 
 these routines directly. 
 
 The above provides for and requires that all segments be 
 "semi-re-entrant." That is, all temporary storage locations, pointers, 
 subroutine returns, intermediate results, etc., must be in areas 
 associated with a particular terminal when a R0UTX call is made. Entry 
 to R0UTX causes control to be lost, as far as the segment is concerned, 
 for an indefinite amount of time. While awaiting completion of the 
 particular service, other terminals and/or devices may present input 
 for inspection by other segments. These requests will of course be 
 resolved, resulting in changes to temporary areas and to the segment swap 
 area. In fact, when the original service is completed, a fresh copy of 
 the requesting segment may be brought into the segment swap area, thus 
 wiping out all temporaries, subroutine returns, etc., done within the 
 segment itself. On the otherhand, no such precaution is needed for direct 
 calls, since control returns immediately to the segment, and execution 
 cannot be interrupted by a device (interrupt is 0FF). 
 
 Naturally, due to the "semi -re -entrant" nature of segments, any 
 segment can service any number of terminals. For example, if segment 7 
 was a text editor, and terminals 2, h> and 5 all wanted to use it, segment 
 7 would be the "associated" segment for those terminals (loc+U in the 
 
console vector of each would = 7)- Unless segment 7 was replaced in 
 the swap area "by another segment due to a request from some other terminal, 
 all three terminals (.2, k t and 5) would be serviced continuously, without 
 segment 7 ever being reloaded. 
 
 Areas associated with the particular terminal are: console 
 vector and PCB (and, of course, the data blocks). The workspace save 
 area (console vector) and program segment scratch area (PCB) are in 
 general available to arbitrary segments as intermediate storage. Almost 
 all GUTS service routines require some parameters as input. For direct 
 calls, the segment puts the appropriate parameters into the service 
 parameter area of UTBANK and makes the call. For indirect calls, the 
 parameters must be placed in the service parameter area of GLBANK; the 
 segment then calls R0UTX. These GLBANK parameters are automatically 
 stored by R0UTX in the service parameter save area of the console vector 
 (loc+Uo). In addition, the needed return information is stored (loc+0,+l) 
 as well as the number of the requested service (loc+2). When the desired 
 service is available, R0UTX copies the stored parameters to the service 
 parameter area in UTBANK, then calls the service as indicated (loc+2). 
 The service routine, when finished, returns to GLASP (at 0PD0NE); the 
 service is marked as available and return is made to the segment. However, 
 prior to the return to the segment, the service parameters in the console 
 vector are copied into the GLBANK service parameter area. 
 
 1.2 General Data Structuring 
 
 All data related to a terminal (other than flags, pointers, 
 counters, etc., in the console vector or PCB) is located in blocks 
 residing in DSBANK. Each block contains one or more "entries," and 
 pointers are kept in the PCB for accessing data within an entry within 
 each block (c.f. Figure 6). In addition, the address, allocated length, 
 and status ( in-use/not-in-use, in -core /not -in- core , fixed/not-fixed) of 
 each block is contained in the PCB (c.f. Figure 5). Each terminal can 
 have fourteen blocks associated with it: five system defined (Figures 7-10), 
 five user defined and four "work." Of the work blocks, only block 10 is 
 
generally available to arbitrary segments . Block 11 is used by GLASP 
 during redisplay of the instance block, block 12 is reserved for GLASP, 
 and block 13 is used for maintaining a menu of the user's pictures and 
 mnemonics (Figure 12). 
 
 A "picture" is defined as the five standard and five user 
 blocks, plus the file control block (Figure 5a) that describes them. 
 The standard blocks, since GLASP and GUTS know their formats, can be 
 automatically displayed. The user blocks must be explicitly manipulated 
 by a segment for alteration or display, but can have any contents 
 (provided the block/entry format is maintained). For example, a picture 
 created by a simulation and modeling application segment might use two 
 of the user blocks to contain text entries. These text entries would 
 describe the equations, parameters, and variables needed for the network 
 under consideration. Display or alteration of these entries would be 
 performed only by the segment after a request from the user. The network 
 in question would be described by the standard blocks (lines, text, 
 subpicture instances, terminals) and could be displayed or altered automatically. 
 
 A "mnemonic" is defined simply as a Mnemonic Storage Block 
 (Figure 11 ) and is created from the standard blocks of a picture. Only a 
 mnemonic can be used to create entries in the instance block of one 
 picture that represent an instance of another picture. This was deemed 
 necessary in order that picture regeneration not overburden the resources 
 of the satellite computer. All pictures and mnemonics (e.g., the constituent 
 blocks) for each user are stored in IR. Examining or altering a block can 
 
 Examining or altering a block can be performed only via the 
 DSMN routines of GUTS. Assume that a picture has already been associated 
 with the terminal; that is, a picture is "current." This means that 
 the FCB for the picture has been read from IR and placed in the PCB . 
 Also, each of the ten blocks used in the picture has been read from IR 
 and its status indicated in the appropriate PCB control entry. Now, the 
 segment calls a routine in DSMN (the loader) to ensure that the desired 
 block is, in fact, in core. The loader examines the appropriate PCB 
 control entry: if the block is in core, the loader sets the PCB control 
 pointers (BLKNUM, BLK0RG, ENT0RG, and P0INTR) , marks the control entry 
 to indicate "fixed," and returns to the segment via 0PD0NE. If the 
 
block was not in core, the loader makes an attempt to allocate space 
 in DSBANK. After space is obtained, IR can be called (internally) to 
 read in the block from an IR temporary file. Of course, if space was 
 not obtained, the loader tries to swap-out (e.g. store in IR under a 
 temporary file) as many unfixed blocks as necessary until adequate space 
 is available for loading the desired block. Note that calling the 
 loader can only be done via R0UTX since a device (the disk) may be 
 used during processing. When the block is in core, the loader sets the 
 pointer and control entry as previously mentioned and returns via 0PD0NE. 
 
 The segment can operate on a successfully loaded block by calling 
 other DSMN routines. Most of these can be called directly since they only 
 perform immediate functions, such as moving the block pointers, copying 
 data out of the block, or testing data within the block. Others must 
 be called via R0UTX, since they might cause the block to be expanded or 
 moved. For example, adding an entry or inserting data within an entry 
 may cause the initial allocation for the block to be exceeded. In this 
 case, the allocation is automatically increased by the necessary amount, 
 but in order to obtain enough contiguous core area for the expanded 
 block, DSMR might have to rearrange DSBANK slightly. IR must be called 
 and disk accessing must be performed, thus "losing control" for the 
 segment. As soon as the segment is finished with the block, a DSMN routine 
 is called to mark the control entry to indicate "unfixed." This designation 
 means that no Input/Output or other operations are being performed on the 
 block. Hence, the DSMN loader may store the block in an IR temporary 
 if space is needed for other operations. 
 
 1 .3 Console Vector Detail 
 
 Primary control usage of the console vector fields is described 
 below; other manipulations of various fields are documented in segment 
 descriptions or GLASP routine descriptions (see later). 
 
Locations +0 through +13 are for GLASP control: 
 
 +0...+1 contain the segment return information during a R0UTX call. 
 
 +2 contains the number of the GUTS service requested by the 
 
 segment in a R0UTX call. A zero in this location indicates 
 the terminal (e.g., execution by the associated segment) is 
 "not busy." A positive number means a GUTS service has been 
 requested and is queued; a negative number (-l) indicates 
 that a requested service is in the process of being performed. 
 Both a positive or negative number is considered to indicate 
 that the terminal is "busy." 
 
 +3 contains the input status of the terminal. Zero indicates 
 that the terminal is physically available, but not in use; 
 ^000 means that the terminal is physically unavailable and 
 should not be used. 2000 indicates that the terminal is in 
 use (active) but no device input is pending. Device input 
 pending for an active terminal is specified by 
 2001:2701 
 2002 : operator 
 200^ : DPU 
 2010: timer 
 Note that 2003 (2701 and Operator) and other combinations are 
 valid conditions. 
 
 +k contains the number (0-37) of the segment currently associated 
 
 with the terminal. "Zero" is the logon monitor segment; this 
 segment is automatically called to execution for a terminal 
 when input arrives for an available but inactive terminal 
 (e.g., a "here is" condition). 
 
 +5... +12 contains the logon string identifying the user at the terminal, 
 This is set only by segment zero. 
 
 +13 contains an internal identifier for the user at the terminal. 
 This is set only by segment zero. 
 
Locations +lk through +17 are for a timer element for the terminal 
 
 +lk 
 
 +15 
 
 +16 
 
 +17 
 
 contains a negative number representing the duration of an 
 
 interval. This location is incremented every l6ms , so -lll6 
 
 ■would represent 10 seconds. The timed interval is expired 
 
 when the count reaches zero and no further intervals are 
 
 required (see +l6, +17 below). 
 
 contains a zero or nonzero flag. If zero, expiration of the 
 
 timed interval is to be ignored. That is, timer input is 
 
 NOT to be accepted. Hence, 2010 would NOT be set in +3. If 
 
 nonzero, timer input is to be accepted, so 2010 would be 
 
 set in +3. 
 
 contains a negative number specifying the number of intervals 
 
 comprising a "timed interval." Whenever +lk reaches zero, 
 
 this location is incremented. If the result is not zero, +lU 
 
 is reset from +17 (see below) and timing continues. If the 
 
 result is zero, the timed interval has expired, timing ceases, 
 
 and timer input pending is set in +3, if applicable. For 
 
 example, to get an interval of 35 seconds, set +1*4- = -UU7 
 
 (5 sec), +17 = -lll6 (10 sec), +16 = -k , and +15 to nonzero. 
 
 A similar result could be obtained by setting +lk = -U021 
 
 (35 sec.), +16 = -1, and +15 to nonzero (+17 is not used). 
 
 Timed intervals can range from l6ms to about 70 hours. 
 
 a negative number to be copied into +lU in the event +l6 is 
 
 nonzero. 
 
 Locations +20 through +23 are for device input entry addresses 
 
 +20 
 +21 
 +22 
 +23 
 
 2701 entry address or zero 
 Operator entry address or zero 
 DPU entry address or zero 
 Timer entry address or zero 
 
 Whenever +3 indicates input pending, the GLASP scheduler 
 periodically tests +2 for "not busy." As soon as "not busy" is recognized, 
 the associated segment (specified in +h) is loaded and entered at 
 
the corresponding entry address. Of course, if the corresponding entry 
 address was zero at the time the input arrived, +3 would NOT have been 
 set, and the input would have "been flushed. Hence, +20 through +23 
 specify whether to accept or ignore the different possible device inputs. 
 
 Locations +2k through +36 are for filtering terminal X-Y and keyboard input 
 +2^ Screen segment flag 
 
 +35 Screen segment 9 flag 
 
 The display area of each terminal is separated into 10 blocks 
 (Figure 13). Even when DPU input in general is to be accepted 
 (+22 is nonzero), certain input may be considered as spurious. 
 For example , the segment may only want to allow the user to 
 hit (joystick interrupt) in the menu area or return box. 
 Disabling input from all other screen areas avoids the need to 
 load a program segment just to find out that the input is 
 spurious. Hence, if the flag for an area is zero, DPU input 
 pending will NOT be set in +3, even though +22 is nonzero. If 
 the flag for an area is nonzero, a hit in the area will cause 
 input pending to be set. Moreover, the nonzero flag is the 
 entry address used to begin segment execution. Thus, the 
 segment not only gets the X-Y input but immediately "knows" 
 what screen area was hit. 
 
 +36 keyboard input entry address or zero (ignore). As above. 
 
 Location +37 is for 2701 indicative text-line handling: 
 
 +37 line Y coordinate 13^ to 170. Certain 2701 text records are 
 
 displayed on the terminal immediately. This location serves 
 as a permanent pointer to the next available line on the 
 display surface. The value is decreased by a line height 
 after each use; the value ikk (bottom) causes wraparound to 
 the value 13^1+ (top). 
 
10 
 
 Locations +U0 through +h'J are for service parameters: 
 
 +40...+U7 the parameter needed for GUTS calls are saved here while 
 the request is enqueued by R0UTX. 
 
 Locations +50 through +77 are for segment usage : 
 
 +50... +77 all locations are available to segments; consult segment 
 
 descriptions for use. Exceptions are +50 and +51; consult 
 the REGEN description in section 1.7- 
 
 1.1+ Picture Control Block Detail 
 
 Primary usage of PCB fields is described below. Other 
 manipulations of these areas are outlined in the GUTS and segment 
 descriptions. 
 
 Locations +0 through +57 are for the File Control Block (FCB): 
 
 +0. . .+2 The six character name of the current picture. 
 +3 Type character word for a picture (^000). 
 +U...+5 Zeroes (Spares) 
 
 Consult the REACT segment description for additional 
 conventions pertaining to use of +0...+5. 
 +6 Zero (reserved for protection bits). 
 +7 Internal identifier of user who created picture. 
 +10... +57 control entries for the ten constituent blocks of the picture 
 
 Consult Figure 5b for the detail of a control entry. 
 
 Locations +60 through +77 are for four accessory block control entries: 
 
 +60...+63 work block. Available for use by any segment. For example, 
 the drawing segments use this block for building mnemonic 
 storage blocks, while the REACT segment uses this block for 
 buffering data blocks transmitted via the 2701. 
 
11 
 
 +6U...+67 regeneration block. Used by the automatic display regeneration 
 routines for buffering mnemonic storage blocks during display 
 of the instance block. 
 
 +70... +73 spare block. Currently available for general use. 
 
 +7^... +77 menu block. Contains the logged-on user's list of pictures 
 and mnemonics saved by the drawing segments. 
 
 Locations +100 through +117 are control fields: 
 
 +100 BLKNUM. On exit from any DSMN routine to a segment, the 
 
 address of the control entry for the block accessed by that 
 routine is stored here. Conversely, on entry to any DSMN 
 routine from a segment, this location is used to indicate 
 the "current" block being investigated. The appropriate 
 "current" ENT0RG and P0INTR for the block can be fetched 
 from the control entry described by BLKNUM. 
 
 +101 lockout. Used by the DSMR loader to indicate that no 
 
 lockout (0) or lockout (-1) occurred while attempting to 
 
 allocate space for a block. This location is set only by 
 
 the loader, so all subsequently invoked routines (GUTS and/or 
 
 segments) can test it. 
 
 +102.. .+103 
 
 spares . 
 
 +101+ . . .+105 
 
 previous ENT0RG and previous P0INTR. DSMN routines that 
 
 alter ENT0RG or P0INTR first store the old values here. 
 
 This is sometimes useful while searching down the entries in 
 
 a block. 
 
 +106 instance block regen. The automatic display regeneration 
 
 routines save the number of the control entry that points to 
 the instance block being redisplayed in this location. 
 
 +107 spare. 
 
 +110 MNM0D. One of the DSMN routines that alters P0INTR always 
 adds in the contents of this location. This is very useful 
 for scanning down the entries of a block and looking at a 
 particular data word. The normal value of MNM0D is zero. 
 It should always be reset to zero after use with another value. 
 
12 
 
 +111 spare. 
 
 +112... +113 
 
 Y, X coordinates. The DPU input filtering routine always 
 
 stores the Y, X coordinates here for accepted joystick 
 
 input from the terminal . 
 
 +11U...+115 
 
 reference center. The Y, X coordinates of the screen area 
 
 reference center are stored in these locations. Several 
 
 DPU routines utilize these. The normal values are 1000, 1000. 
 
 +116...+117 
 
 spares . 
 
 +120. ..+177 
 
 work area (PCW0RK). Generally available for segments. Often 
 
 used to buffer 2701 indicative text-lines before display at 
 
 the terminal or to buffer text lines from the terminal before 
 
 transmission over the 2701. Other usage indicated in the 
 
 segment descriptions. 
 
 1.5 GLASP Routines 
 
 The monitor is composed of two sets of routines: system 
 functional and segment functional. The former handle all internal 
 control operations needed by the system and are activated either by 
 device interrupts or by entry from GUTS routines or segments . The 
 latter perform some utility function upon entry from a segment. 
 
 System : 
 
 Interrupt handler (INTHND): trap all device interrupts, link to GUTS 
 
 device routines, and link to input routines. 
 2701 input (FR2701) : recognize remote input, set 2001 pending. 
 Operator input(0PKB): recognize operator command input, set 2002 pending 
 DPU input (DPUINR): recognize DPU input, set 200U pending. 
 Timer input (CLKQR): recognize timer input, set 2010 pending. 
 GUTS service requests (R0UTX): enqueue segment service requests, set 
 
 request pending. 
 Scheduler (TSTQUE) : text input pending and service request pending for 
 
 each terminal, attempt to start segment if pending found. 
 
13 
 
 Idler (WAIT): test system priority flags, call scheduler, await device 
 
 interrupts . 
 GUTS service completion (0PD0NE): restart segment execution according 
 
 to console vector data. 
 Segment completion (RELESE ) : mark terminal "not "busy," safety unfix 
 
 of all data blocks, call idler. 
 
 Segment : 
 
 Load new segment (XCTL) : change segment associated with terminal, 
 
 loads new segment and begins execution. 
 2701 indicative lines (GSMSGA): displays 2701 text-line message on terminal, 
 Terminal input filtering (DPUDIN): helps filtering spurious terminal input. 
 Standard block display (GREGEN): automatically regenerates display at 
 
 terminal for five standard system "blocks . 
 Text messages (GREGPl) : helps set messages into display files for 
 
 output to terminal . 
 SVPUT: pass a parameter to a particular service parameter location 
 
 in UTBANK. 
 FREDPU: clear DPU flags and blank first part of input buffer. 
 
 This call MUST ALWAYS be made as soon as the segment is 
 
 done examining the DPU input . 
 RETIME: reset timer element for ten minutes. 
 FREDIM: call FREDPU and RETIME. 
 
 RLV1,RLV2,RLV3: call XCTL for return to a previous segment. 
 M0VEDT: arbitrary movement of data between any pair of banks. 
 
 SADCV 
 
 SSTCV 
 
 SADPC 
 
 SSTPC 
 
 ST0P 
 
 STWK 
 
 LDWK 
 
 add to the ACC the word at +n in the console vector. 
 
 store the ACC at +n in the console vector. 
 
 add to the ACC the word at +n in the PCB. 
 
 store the ACC at +n in the PCB. 
 reset the console vector beginning at +lk through +37- 
 reset the console vector beginning at +50 through +77* 
 reset the page work area (loc 150-177) from the workspace 
 save area in the console vector (+50 through +77) • 
 
Ik 
 
 SVPRLD: reset the page service parameter area in GLBANK or UTBANK 
 
 from the console vector (+1+0 through +1+7). 
 SVPRSV: reset the console vector service parameter area (+k0 through 
 
 +1*7) from the page service parameter area of GLBANK or UTBANK. 
 T0LAC: test a terminal for active/online/offline status. 
 GLINE: calculate a line number from a menu Y coordinate. 
 
 More detailed descriptions of the GLASP routines are 
 presented in Appendix C. 
 
 1.6 GUTS Service Routines 
 
 The routines comprising GUTS are divided into numbered groups 
 according to function and to system resource monopolized: 
 
 1. Data Structure Management (DSMN) Core 
 
 2. Information Retrieval (IR) Disk 
 
 3. 2701 Send (T027O1) 2701 out-channel 
 k. 2701 Receive (F027O1) 2701 in-channel 
 
 5. Display Processing (DPU) DPU channel and buffer 
 
 6. Hardcopy Printing (INK) Inktronic printer 
 
 The request number specified in a R0UTX call is the group number. Each 
 service group is associated with a flag word and an entry address. When 
 the flag is zero, the service is not busy (idle); hence, another 
 segment request for its function can be accepted. The terminal's console 
 vector address is stored into the flag word (the service is now busy; 
 subsequent requests from other terminals will be enqueued) and execution 
 is begun at the service's entry address in UTBANK. When the service is 
 completed, 0PD0NE will replace the console vector address in the flag word 
 with zero, setting the service "not busy." 
 
 DSMN : 
 
 R0UTX entry (MNNTRE): SVPRM1 specifies routine to be used. On return 
 to R0UTX, ACC stored in console vector SUPRM8 location as 
 return code. Before the indicated routine is invoked, the 
 
15 
 
 BLKNUM field in the PCB is used to reset the current block: 
 ENT0RG, P0INTR, and BLK0RG are set from the indicated PCB 
 entry. After the indicated routine terminates, the current 
 values of ENT0RG, P0INTR, and BLKNUM are saved in the 
 appropriate PCB area. This provides a means for passing the 
 current block from one routine to the next , even when the 
 routines must be invoked with R0UTX. 
 
 Direct call entry (MNDPC) : SVPRM1 specifies routine to be used. ACC 
 contents passed to routine and final ACC contents returned 
 to calling program. Current block pointers set and saved as 
 in MNNTRE. 
 
 Load data structure block (MNL0DR) : make specified block ready for 
 
 manipulation. If not in core, bring it in from IR; initialize 
 pointers to the first entry in the block and set status 
 in -core /fixed. This block is now considered as the "current 
 block" being manipulated. (Called via R0UTX) . 
 
 Set status "Unfixed" (MNUNF) : current manipulation of the specified 
 
 block is at an end; mark it as available to be "swapped out" 
 (Called via direct). 
 
 Delete a block (MNDEB): if the specified block is in use, mark it as 
 
 not in use; free any core it may occupy; and delete its storage 
 temporary from IR if one exists. If the current picture is 
 subsequently stored in IR, this block will NOT be part of the 
 picture. (R0UTX). 
 
 Start a block (MNIBA) : essentially do an MNDEB to clean up, then set the 
 initial size of the block (initial allocation) and call MNL0DR. 
 Core will be allocated, and the block is marked in-use, in- 
 core, fixed, but NOT initialized. This block is now the current 
 block. If the current picture is subsequently stored in IR, 
 this block will NOT be part of the picture. (R0UTX). 
 
 Set first data (MNIBD) : set the initial block data desired into the 
 current block; the block is marked initialized. A previous 
 MNIBA call is assumed; all other DSMN routines can NOW be called 
 to manipulate the block. Unless an MNDEB call is made, this 
 block will be part of the picture if subsequently saved in 
 IR. (Direct). 
 
16 
 
 Swap block out (MNST0R) : explicitly store specified block in an IR 
 temporary, thus freeing whatever core it is occupying. 
 This call is ROT usually needed, since MNL0DR automatically 
 swaps out unfixed blocks as the need arises. (R0UTX). 
 
 Save status (MNBSV) : the pointers associated with the current block 
 
 are saved in the appropriate PCB entry. See MNBRS and MNBTB. 
 Note that the block remains marked as fixed and in-core. (Direct) 
 
 Reset status (MNBRS): the pointers stored in the PCB entry of the 
 
 specified block are used to reset that block as the current block. 
 The specified block is assumed to be fixed and in-core (e.g., a 
 call to MNL0DR, some arbitrary DSMN calls, and an MNBSV call 
 all preceded this call). See MNBSV and MNBTB. (Direct). 
 
 Block-to-block data transfer (MNBTB): data or entire block entries are 
 copied, inserted, or replaced from one block to another. The 
 FR0M location is specified by the pointers in the PCB entry of 
 the specified block (e.g. saved by MNBSV). The T0 location is 
 specified by the pointers of the current block. After some 
 set up, MNBTB calls the DSMN routine specified, usually 
 MNRPL, to actually perform the operation. See MNBSV, MNBRS, 
 and MNRPL. (R0UTX). 
 
 Next entry (MNNXTE) : move the pointers of the current block to the next 
 entry in the block. The current values of ENT0RG and P0INTR 
 are first stored in SHDERG and SHDPTR to allow one-level back 
 tracking. Then ENT0RG is updated to the address of the next 
 sequential entry, while P0INTR is updated to the address of 
 the first data word in that entry plus a specified displacement 
 (MNM0D). See MNFPR. (Direct). 
 
 Move pointer (MNFPR) : the P0INTR of the current block is reset within 
 
 the current entry by the positive or negative amount in the ACC. 
 See MNFPRA. (Direct). 
 
 Reset pointer current (MNFPRA) : the P0INTR of the current block is reset 
 from its current position in the entry to the beginning of the 
 entry, as in MNNXTE. See MNNXTE. (Direct). 
 
IT 
 
 Reset entry (MNPERG) : both ENT0RG and P0INTR of the current block 
 
 are reset as in MNNXTE , but to the specified n-th entry. (Direct). 
 Reset and locate (MFPRT) : both ENT0RG and P0INTR of the current block 
 
 are reset as in MMXTE, but to the first entry in the block. 
 
 In addition, the address of the block is returned in the ACC. 
 
 This address is ONLY to be used when calling IR or 2701 services ; 
 
 explicit manipulation of blocks is not allowed. (Direct). 
 Load word (MPL0D, MNEL0D, MNBL0D) : the word in the current block 
 
 pointed to by P0INTR, ENT0RG, or BLK0RG, respectively, is 
 
 returned in the ACC. (Direct). 
 Store word (MNPSET, MNESET, MNBSET): the ACC is stored at the word in 
 
 the current block pointed to by P0INTR, ENT0RG, or BLK0RG, 
 
 respectively. (Direct). 
 Replace data (MNRPL) : the specified data replaces data at the current 
 
 position indicated by ENT0RG and P0INTR in the current block. 
 
 Depending on parameters supplied, entire entries can be 
 
 replaced, inserted, or deleted, and data within an entry can 
 
 be replaced, inserted or deleted. (R0UTX). 
 Insert new entry (MNNEN): the specified data is inserted into the current 
 
 block before the current entry indicated by ENT0RG as a new 
 
 entry. After some set up, MNRPL is called for the actual 
 
 operation. (R0UTX). 
 Inset new entry end (MNNNE): exactly as MNNEN, but new entry is at the 
 
 end of the current block. (R0UTX). 
 Insert new data (MNINE): exactly as MNRPL, but allows data to be inserted 
 
 at the end of the current entry. (R0UTX). 
 Insert new data end (MILE) : exactly as MINE, but allows data to be 
 
 inserted at the end of the last entry of the current block. (R0UTX) 
 Extract (MEXTC): the specified amount of data is extracted (copied) to 
 
 the specified location from the current P0INTR location of the 
 
 current block. (Direct). 
 Build mnemonic (MNMNEM) : a Mnemonic Storage Block is constructed in 
 
 block 12 from the standard blocks of the current picture. (R0UTX). 
 
18 
 
 Integrate mnemonic (MNMNIN): the Mnemonic Storage Block currently in 
 block 12 is integrated into the instance block (block 2) and 
 terminal block (block k) of the current picture. (R0UTX). 
 
 Complete remote block transmission (MN2TB) : set up the current block 
 to receive a 2701 input record. See F02701 and Appendix B. 
 (Direct ) . 
 
 The above routines, along with a large number of other less 
 often used routines, are described in greater detail in Appendix D, Part 1. 
 
 IR: 
 
 R0UTX entry (IRREQ): initiate an operation in the local filing system. 
 This is the only call available (or necessary) for segments 
 desiring direct access to the filing package. The parameters 
 needed are: 
 
 SVPRM1 = function 
 
 SVPRM2 = file type 
 
 SVPRM3-5 = 6 character file name 
 
 SVPRM6 = core location of data 
 
 SVPRM7 = file length (write) or available core (read) 
 
 SVPRM8 = owner's ID (protection) 
 
 The functions available include: 
 
 READ into DSBANK (6l00) or into WKBANK (6000) 
 WRITE from DSBANK (2100) or WKBANK (2000) 
 DELETE (2200) 
 
 A file is uniquely identified by its name plus the owner's ID 
 plus its type. Note that IR directory blocks are accessed by 
 hash coding the ID and the file name ; the type is purposely 
 left out of the hash procedure. This ensures that the directory 
 entries for all files that differ only by type will be located 
 close together, thus speeding retrieval of all such "related" 
 files. The following conventions have been established for 
 storing pictures (l), mnemonics (2), block temporaries (3)» 
 and menu blocks (U), in IR: 
 
19 
 
 NAME 
 
 ID 
 
 (1) six user-specified from console 
 characters vector 
 
 (2) six user-specified from console 
 characters vector 
 
 (3) 0, PCB control 
 entry, address 
 
 (1+) 0,0, user's ID 
 
 TYPE 
 l+000(8)-l+0l2(8)* 
 
 l+ol+o(8)-Uol+7(8)** 
 
 1+001(8) -1+017(8)' 
 hoi6 + 
 
 All other name/type combinations can be used by segments as 
 desired, except for types 1+020-1+037 and 1+050-1+077 which are 
 reserved for future system use. 
 
 Note, for example, that the picture DI0DE composed of blocks 0, 
 1, 2, 1+, 5, and 6 with mnemonics DI0DE.O and DI0DE.1 will be 
 stored in nine related IE files. All nine will have the same 
 six character names and user ID, but the types will be 1+000, 
 1+0001, 1+002, 1+003, 1+005, 1+006, 1+007, UOUO, and UoUl. Note, 
 also, that to read or write the information contained in a data 
 structure block, the block must have been loaded (MNL0DR or 
 MNIBA) and its address obtained via MNFPRT. 
 
 A complete description of the operation of IR is presented 
 
 m 
 
 [6] 
 
 * The last two digits correspond to the respective block number, with 
 00=file control block, 01=block 0,..., 12=block 9. 
 
 ** The last digit corresponds to the mnemonic designation, e.g., RESIST. 6 
 implies type h0h6 . 
 
 Same as for *, but file control block is never stored in a temporary; 
 1+013-1+106 are for work blocks 10 to 13 (1+017 is currently unused since 
 there is no block designated ll+). 
 
20 
 
 T02TO1 : 
 
 R0UTX entry (T027O1) : transmit data to the 360/75. The parameters 
 needed are : 
 SVPRM1 = record type 
 SVPRM2 = data bank 
 SVPRM3 = data address 
 
 SVPRM4 = data length minus 1 (0-1+095 = I-U096) 
 Transmission can only take place when the 2701 is not "busy, 
 e.g., a read cannot be in progress. Note that to send the 
 information contained in a data structure block, the block must 
 have been loaded (MNL0DR) and its address obtained via MNFPRT. 
 Record types for data structure blocks are identical to IR 
 file types, e.g. UOOO-UOIT and h0k0-k0k r J . Types 7770-7777 are 
 reserved for monitor-to-monitor internal commands ; type 
 always means the record is a simple text-line. Type 1 is used 
 by some segments (REACT, etc.) to indicate joystick X, Y data. 
 All other types, except U020-U037 and kO^O-hOTl , are available 
 for arbitrary segment use. A good example is provided by 
 REACT; see section 1.7, REACT. 
 
 The record actually transmitted is: 
 
 +0 +1 +2 +3 ... +n 
 
 00N0 TYPE LEN |«- DATA ->| 
 
 where N is the terminal number and DATA is the information 
 beginning at the location specified by SVPRM3. If n > 128 
 (>125 data words), two records are actually sent. The first 
 contains the terminal number, record type, total length, and 
 the first 125 data words; the second record contains just the 
 remaining data words. This procedure facilitates buffering in 
 the 360/75. Note that the 360/75 uses this two-part 
 convention for sending records to the PDP-8. 
 
21 
 
 K02TO1 : 
 
 R0UTX entry (F027O1) : complete a record transmission from 360/75. 
 Whenever a send to the 360/75 is not in progress, a read- 
 ready status is maintained in the PDP-8. Due to the two-part 
 record convention (see T027O1) , the PDP-8 must remember 
 whether the input data is the second part of a record or the 
 first part of a new record. In the first case, the data is 
 only read into the PDP-8 after an appropriate segment call to 
 F027O1; before making the call, the segment must provide a 
 buffer for the entire record and must move the first part of 
 the record into the buffer. The F027O1 call not only completes 
 the read operation, but also allows the system to reset in 
 case the first part of a new record comes along. In addition, 
 a check is made to see if a T027O1 call became pending while the 
 read was in progress; if it did, a write operation is started. 
 
 In the second case, when the first part of a new record is 
 expected, the system automatically reads the data into a 128 
 word buffer. The terminal to be notified (via GLASP routine 
 FR2701) can be ascertained from the terminal number in the first 
 word of the record. After the proper console vector is marked, 
 no further action is taken until the segment makes the F027O1 
 call. Note that this is true even if no second part is expected. 
 System processing of further 2701 input must wait until the 
 appropriate segment examines the record in the system buffer, 
 takes action, and notifies the system that the buffer is now 
 "clear" with the F027O1 call. 
 
 When the segment's execution begins at its "remote (2701) data 
 record received" entry point, the following information is 
 available in UTBANK: 
 
 F2701C is the start of the 128 word buffer containing the first 
 
 part of the record. 
 F2701T (F2701C+1) contains the record type (all types 
 
 identical to T027O1 usage). 
 
22 
 
 F2T01L (F2T01C+2) contains the data length -1 (as in T02TO1). 
 
 F2T01D (F2T01C+3) is the first data word. 
 
 I2701P is a flag containing a 1 (second part expected) or 
 
 a -1 (no second part since F2T01L < 128 (<125 data -words)). 
 
 From this information, the segment should be able to decide 
 how big the entire record is and what should be done with it. 
 Even if no second part is expected, the F027O1 call must be 
 made so that the system realizes that tie buffer is clear and 
 2701 input or output processing can begin again. The system 
 will not try to read a non-existent second part since the 
 I2701P flag is checked by the F027O1 routine. The parameters 
 for F027O1 are: 
 
 SVPRM2 = data bank 
 SVPEM3 = data address 
 
 SVPRM^ = data length (0 means "use preset remainder"; see 
 example below) 
 
 A typical use of the 2701 input facility would be the transmission 
 of a data structure block from the 360/75 to replace a block in 
 the current picture of the receiving terminal. The first part 
 of the record is sent by the 3^0/75 an< 3- automatically read into 
 the standard buffer in the PDP-8. The appropriate console 
 vector is marked, and the associated segment begins execution. 
 The segment uses F2701L to calculate the total number of core 
 pages required by the block; MNIBA is then called to establish 
 a block of this size. MN2TB is called next; this routine moves 
 the data from the standard buffer into the beginning of the 
 new block. It then calculates and returns the address within 
 the block at which the second part of the record, if it exists, 
 would start. In addition, it calculates and sets the remaining 
 record length for the second part ("preset remainder"). The 
 segment sets SvPRM2=DSBANK,SvPEMU=0 , and SVPRM3=address- 
 returned-by-MN2TB ; and F027O1 is called. If the second part 
 exists, the read operation transfers the data directly into 
 
23 
 
 the receiving block. Then the system resets for the next 
 record. If the second part does not exist, just the reset 
 occurs. Note that in this example, the segment did not ever 
 check whether the record was composed of one or two parts, 
 since its actions in either event would have been the same. 
 
 DPU : 
 
 R0UTX entry (DPUENQ) : serialize the use of the buffering controller 
 (DPU). The requesting terminal (segment) now has exclusive 
 control of the terminal output buffer and the buffer is 
 initialized. The segment makes direct calls to other DPU 
 routines to construct a display file in the buffer. When the 
 display file is finished (marked complete), it will be sent 
 to ACID for transmission to the specified terminal. When the 
 buffer has been emptied by ACID, control is returned to the 
 segment via 0PD0NE. See Appendix A. If SVPRM8 is not zero, 
 its contents are assumed to be an immediate command, such as 
 "Erase" or "Disable." This one-word display file is sent 
 immediately to ACID, the DPU is released, and control returns 
 to the segment via 0PD0NE. If SVPRM8 is zero, control returns 
 directly to the segment so direct calls can commence. The 
 output buffer is U000(8) words, long enough to hold the display 
 file for an entire screen of text. If during direct calls this 
 buffer is exceeded, further calls are ignored (e.g., no data is 
 placed in the buffer) until the file is marked complete by the 
 segment. The truncated file is then sent to ACID. 
 
 Direct call entry (DPUPDC): the ACC specifies the routine to be used. 
 ENT0RG and P0INTR are reset from the PCB entry indicated by 
 BLKNUM (e.g. , current block) as in DSMN processing for those 
 DPU routines that need to examine the current block. However, 
 the final values of ENT0RG and P0INTR are NOT returned to the PCB, 
 
 Initial text-line and complete (DPUA): the buffer is initialized, the 
 
 specified data is inserted as a single text line at a specified 
 Y, X and the file is marked complete. Control is returned to 
 the segment when the buffer is empty (E). 
 
2k 
 
 Initial vector and complete (DPUB): as in DPUA, but the display file 
 
 is a line "between two Y, X pairs. 
 Initial file and complete (DPUC): as in DPUA, but the display file 
 
 is any arbitrary data supplied by the segment. Also, if the 
 
 data length specified is zero, the buffer is not initialized. 
 
 Rather, the current file under construction is marked complete; 
 
 control then returns to the segment as in DPUA. 
 Position beam point (DPUDP): a point command moving the beam to the 
 
 specified Y, X is added to the current display file. The 
 
 point may be specified as visible or blanked (not visible). 
 
 Control returns immediately to the segment (i). 
 Position beam vector (DPUDV, DPUDl): a vector command moving the beam 
 
 between a pair of specified Y, X points is added to the current 
 
 display file. If the beam is specified as visible, a line 
 
 results. (I) . 
 Text-line (DPUE): the specified data is added as a single text line at 
 
 a specified Y, X to the current display file. (i). 
 Add small (DPUF) : up to five data words are added to the current 
 
 display file from the SVPRMU-8. (i). 
 Add arbitrary (DPUG): arbitrary length data as specified is added to 
 
 the current display file. (i). 
 Add vectors (DPUH): arbitrary length data consisting of vector commands 
 
 is added to the current display file, but an enter-vector-mode 
 
 command is inserted first and an exit-mode sequence is added at 
 
 the end. (I ) . 
 Add text entry (DPUI): all text-lines in the current block entry pointed 
 
 to by ENT0RG and P0INTR are formatted for display and added to 
 
 the current display file. (I). 
 Add text block (DPUJ): all text-lines in the current block entry pointed 
 
 to by ENT0RG and P0INTR and all text from all remaining entries 
 
 in the current block are formatted for display and added to the 
 
 current display file. (I). 
 
25 
 
 Pass text line (DPUK, DPUKA, DPUKB) : transmit specified text line to 
 
 DPU for placement in terminal's line creation buffer. (E). 
 Add terminal entry (DPULY): format and add specified terminal entry to 
 
 current display file. (i). 
 Add terminal "block (DPUL) : format all terminals and terminal connections 
 
 in current block (terminal block h) and add to current 
 
 display file. (i) . 
 Add line block (DPUNL): format all point groups in current block (line 
 
 block 0) and add as visible vector commands to current display 
 
 file. (I). 
 Add mnemonic instance (DPUM) : format lines and text, or parameters 
 
 model list, or lines only, or text only as specified from 
 
 current block (mnemonic storage block 12 or 13) and add to 
 
 current display file. (I). 
 
 A complete list of the DPU routines is presented 
 in Appendix D, Part 2. 
 
 INK: 
 
 R0UTX entry (INKENQ): serialize the use of the local hardcopy printing 
 device. The requesting terminal (segment) now has 
 exclusive control of the printer output buffer and the buffer 
 is initialized. Control is immediately returned to the 
 segment ; the segment makes direct calls to INKLP for each 
 complete line (80 characters or less) to be printed. 
 
 Print a line or complete ( INKLP ): the specified data, a packed character 
 string, is unpacked into the print buffer, and printing begins. 
 Control is not returned to the segment until the line is 
 finished. If the data length is specified as being zero, the 
 service is marked not busy (as would be done by 0PD0NE) and 
 control immediately returns to the segment. 
 
 SVPEM5 = character count (<_ >_ 80) 
 SVPRM6 = data address 
 SVPRM7 = data bank 
 
26 
 
 1.7 Program Segment Descriptions 
 
 GLASP has provision for 32 concurrently available segments; the 
 normal (typical) allocation of "system" and "application" segments is 
 shown in Figure lU. The minimum number of system segments is three (CALR, 
 DEX1 , and PSIR) ; if the number of valid users is fairly large (>256) and 
 if special functions are added to IR, as many as three more segments may 
 be needed (DEX2, DEX3 , and SPIR) . Three segments containing utility 
 functions (GUT1, GUT2 , and GUT3) are available; these utilities may be 
 called by any segment. A very powerful generalized drawing package is 
 provided (GND1, GND2 , and GND3) which requires still another three 
 segments. Hence, the number of truly free segments for application use 
 is usually 20. Supporting the Simulation and Modeling application 
 (GSAM) required less than one-half of a single segment; a shortage of 
 application space seems highly unlikely. Moreover, whenever the system 
 is loaded, any group of 20 application segments may be loaded. 
 
 The general activity, and some of the possible events, that 
 may take place during execution of the segment GSAM will be briefly 
 described since this segment exemplifies typical applications support. 
 On entry from CALR (the user picked GSAM from the menu), GSAM uses routine 
 ST0P to reset the control area of the console vector; this includes the 
 timer element, device input addresses, and the screen segment filter 
 words. GSAM then enqueues the DPU with a R0UTX call and uses GREGP1 as 
 well as DPU direct call routines to build a display file. The new display, 
 containing some messages and a list of three mode options in the menu area, 
 is sent to the terminal with a DPUC call. When the DPU output buffer in the 
 PDP-8 is empty, the DPU service is marked "not busy" and control is returned 
 to GSAM via 0PD0NE. GSAM returns to GLASP via RELESE to await terminal 
 input, specifically a hit on one of the options in the menu. 
 
 Several user hits in the draw, prompt, and light button areas 
 as well as a keyboard text-line are ignored by GLASP; the filter words 
 in the console vector, as set by ST0P, indicate these inputs are considered 
 invalid. Meanwhile, an indicative text message (type=0) arrives over 
 the 2701; this input is to be accepted. GSAM calls routine GLMSGA to 
 transfer the line to the terminal at the top of the draw area. Finally, 
 
27 
 
 the user hits in the menu area; GLASP stores the Y, X coordinates in the 
 PCB (via PICSEG). BPUDIN is entered and transfers control to the entry 
 in GSAM specified by the menu area filter word. Since only the Y 
 coordinate needs to be investigated and it is already in the PCB, an 
 immediate call to FREDTM Is made. The DPU input mechanism is released 
 for more terminal input, and the timer for this terminal is reset to 
 ten minutes . 
 
 The menu line hit was C0NSTR, so GSAM puts return data into 
 the console vector level two return and uses XCTL to call the 
 generalized drawing package, GND1. The user interacts in a similar 
 manner with GND1 : building a picture, calling IR, directly invoking 
 REACT, etc. Finally, the user returns from GND1 to GSAM, and GSAM 
 re-initializes the console vector and display as it did on the first 
 entry from CALR. 
 
 Now the user hits menu line two: SPECFY. GSAM changes the 
 console vector control area and puts up a new list of options. The 
 sixth option is chosen, Indicating that the user wants to add some 
 equations to the picture. This means text editing in entry one of block 
 6. MNL0DR is called via R0UTX, but the return code is "NOT IN USE"; 
 GSAM calls MNIBA via R0UTX to establish the block, then MNIBD to 
 initialize it with two empty text entries. The text entry editor in 
 GUT1 is now called with an XCTL (return data is first placed in the 
 level 3 return of the console vector) and with parameters indicating 
 editing of entry one, block 6. The user interacts with the text editor 
 and finally returns to GSAM where the console vector and display are 
 reset with the SPECFY options list. RETURN is hit, so GSAM returns to 
 its main three option mode; RETURN is hit again, so GSAM returns (exits) 
 to CALR. 
 
 Functional descriptions of CALR, GNDR(GND1,GND2 ,GND3 ) , GUT1 
 (the text entry editor), GUT3( REACT), and GSAM are presented in [7]. 
 PSIR appears in [6]. Detailed information concerning these segments' 
 use of the console vector work area and the PCB, their device input 
 procedures, as well as some very useful subroutines they employ, is found 
 
28 
 
 in the listings (usually the first few pages of each). Segments of 
 particular interest are GND1 and GUT3. A brief resume of the facilities 
 provided by GUT2, as well as some additional information on GUT3, 
 follows below. Detailed procedures for calling the utilities in GUT2 
 appear in the listings; LDNMBK is of particular interest in that segment. 
 
 REGEN 
 
 This routine is invoked normally ONLY by the GREGEN facility 
 in GLASP; it provides a means for regenerating all of the instance 
 mnemonics referenced in an instance block (usually block 2). However, 
 REGEN can be called by segments to display an arbitrarily located 
 instance block (c.f. REACT). 
 
 During automatic redisplay of the standard visible blocks 
 (GREGEN), the existence of an initialized block 2 (instance block) 
 causes GREGNE to XCTL to GUT2 at entry RGINST. RGINST assumes that the 
 block has at least one valid instance reference (three entries). Each 
 instance reference in the block is examined sequentially; the instance 
 name and Y, X position are extracted. The specified mnemonic instance 
 block is loaded from IR into work block 13n by an internal call to 
 LDNMBK (see below). DPUM is then used to create the appropriate display 
 files. RGINST eventually returns to GREGNE, using console vector 
 locations +51 to reset the terminal's current program ID. The terminal's 
 return address was stored by GREGEN in console vector location +50. 
 
 LDNMBK 
 
 This routine loads a named block from IR into the specified 
 block of the current picture or into a work block; the listing of the 
 routine is quite descriptive and should be examined. LDNMBK can be 
 called on level 3 as a subroutine by any segment; it is also called 
 internally by RGINST during instance block display (above) or by LDNMHP 
 (load new picture, see below). 
 
29 
 
 SVNMBK 
 
 This routine saves the specified "block (after loading it 
 into core via MNL0DR) in IR with the indicated name. It can "be called 
 on level 3 as a subroutine (e.g., to save some block just created) or 
 internally (e.g., "by SWMHP for each block in the current picture). 
 The specified block is unfixed before return. 
 
 DUJMBK 
 
 This routine deletes the indicated named block from IR. It 
 can be called on level 3 as a subroutine or internally (e.g. , by 
 DLNMHP for each block in the specified picture). 
 
 SVNMHP 
 
 This routine, called on level 3 only, saves the FCB and all 
 initialized blocks of the current picture in IR with the name specified. 
 Internal calls to SWMBK are made for each block to be saved. The 
 specified name is also inserted into the user's menu block (see below). 
 Before the FCB is saved, the specified name is inserted at its beginning 
 along with a user ID of 0. Hence, IR will use the current logged-on 
 user's ID in the directory entry created. 
 
 LDNMHP 
 
 This routine, called on level 3 only, loads the specified 
 (named) picture from IR and makes it the current picture. First, all 
 blocks of the old current picture are purged from core with MNDEB. Then 
 the FCB of the new picture is loaded from IR. Using the data in the FCB, 
 each initialized block in the new picture is loaded with an internal call 
 to LDNMBK. After being loaded, each block is unfixed. 
 
 DLNMHP 
 
 This routine, called on level 3 only, deletes the named picture 
 from IR. First, the FCB is deleted; then each block is deleted by an 
 internal call to DLNMBK. The picture name is also deleted from the user's 
 menu block (see below). 
 
30 
 
 SVENMN 
 
 This routine, called on level 3 only, saves the current contents 
 
 of block 12 _ with the specified name — the block is. assumed to be a 
 mnemonic storage block. Before calling SVNMBK internally for the actual 
 IR save, the name is inserted into the block, along with a user ID of 
 (c.f. SVNMHP). The name is also inserted into the user's menu block. 
 
 DELNMN 
 
 This routine, called on level 3 only, deletes the named mnemonic 
 from IR and the mnemonic name from the user's menu block. 
 
 (Note that a routine to load a named mnemonic is NOT provided since this 
 is accomplished merely by a direct call to LDNMBK) 
 
 SNDHDR 
 
 This routine, called on level 3 or internally by SNDPC (below) 
 transmits the specified block over the 2701 via a R0UTX call to T027O1. 
 
 SNDBLK 
 
 This routine, called on level 3 or internally by SNDPC (below), 
 transmits the specified block over the 2701 via a R0UTX call to T027O1. 
 The indicated block must already by loaded. 
 
 SNDPC 
 
 This routine, called on level 3 only, transmits the current 
 picture over the 2701. SNDHDR is first called internally to send the 
 FCB; then, after appropriate MNL0DR calls, SNDBLK is internally called 
 for each initialized block. 
 
 MEN UP 
 
 This routine, called on level 3 or internally (by DLNMHP, 
 DELNMN), deletes the indicated name from the user's menu block. The 
 block is first loaded via MNL0DR; then a scan routine (MENUSW) tries 
 to locate the name. If found, the name is removed by a call to MNRPL 
 which compresses the block at that point. 
 
31 
 
 MENUA 
 
 This routine, called on level 3 or internally ("by SVNMHP, 
 SVENMN) , adds the indicated name to the user's menu block. The block 
 is first loaded; then MENUSW tries to locate the name. If not found, 
 the name is inserted by a call to MNRPL which expands the block at 
 the alphabetic location reached by MENUSW. 
 
 MENUX 
 
 This routine, called on level 3 or internally, extracts the 
 indicated n-th name from the user's menu block. For example, MENUX is 
 usually called after a menu area hit in GND1; it is also used during 
 CALR's purgeout processing. 
 
 DIMEM 
 
 This routine, called on level 3 or internally, displays the 
 first 32 names in the user's menu block in the menu area. After loading 
 the menu block, DIMENN enqueues the DPU and builds the display file 
 via DPUE calls. The file is sent to the display; DIMENN unfixes the 
 block and returns. 
 
 DIMNF1, DIMNF2, DIMNF3 
 
 These are three entry points in DIMEM, called on level 3, 
 that cause display of the second, third, and fourth 32-name groups, 
 respectively, in the user's menu block. 
 
 REACT (GUT3) 
 
 As previously discussed, this program provides generalized 
 user-to-remote-program communication facilities. Two areas bear special 
 mention; the first involves 2701 record handling. 
 
 Unless otherwise altered by the program in the 36Q (see below), 
 user keyboard lines and joystick hits are sent directly to the 360. Keyboard 
 lines are sent with type=0 , joystick hits with type=l. The format is 
 as follows : 
 
32 
 
 Keyboard : 00N0 0000 OOnn (packed characters) 
 
 +0 +1 +2 +3 . . . +nn+U 
 
 +0 through +2 are the usual record control -words , as 
 described previously (N = console number, 0000 = type, 
 nn = length), nn is ^_ k3n since the maximum character 
 line is 72 1Q characters (e.g. T2/2 - 1 = 35 = **3g) . 
 This, is the same form as the so-called 'Indicative text line 
 messages" sent from the 360 to the PDP-8. 
 
 Joystick : 00N0 0001 0002 Y X n 
 +0 +1 +2 +3 +k +5 
 
 +0 through +2 as above . +3 and +h are the hit coordinates , 
 while +5(n) is the screen segment number in "which the hit 
 occurred. Note that REACT has a special test to use any hit 
 in the system message area (screen segment 0) as an EXIT 
 REACT request; this cannot be altered by the 360 program. 
 
 In addition, as described in [7], REACT can transmit pictures and mnemonics 
 to the 360. The record types for these blocks are identical to the 
 convention used by local IR as presented in section 1.6 (IR) . Moreover, 
 LSD uses the same type-word conventions for storing picture and mnemonic 
 blocks in the 360 remote filing system. 
 
 Data sent to REACT from the 360 looks much the same. Record 
 type = is an indicative text message line, so the line is displayed 
 on the terminal in the next available location. When the bottom of the 
 draw area is reached, the screen is erased, the frame is redrawn, and 
 the "available location" pointer (kept in +37 of the console vector) is 
 reset to the top of the draw area. Records with the high-order bit set 
 on (e.g. i+xxx) are assumed to be data structure blocks composing parts of 
 pictures or mnemonics. All other records (types 1-3777) are ignored 
 (flushed). For data structure blocks, type bits 0077 specify the block, 
 3600 specify options, 4000 must always be on, and 0100 must always be off 
 (else a type of 7770-7777 could be generated which would be confused with 
 a monitor-monitor internal record). The options are listed below; bits 
 are numbered high order (left) to low order (right), to 11. 
 
33 
 
 bit : 1 ( always ) . 
 
 "bit 1: 1 (replace the similarly numbered block in the current 
 
 picture with the block in this record) . 
 
 (put the block in this record into work block 12n). 
 
 bit 2: 1 (do not display the block in this record). 
 
 (display the block in this record immediately on 
 
 the terminal). 
 
 bit 3: 1 (before displaying block (bit 2=0), erase screen 
 
 and set available location pointer to draw area top). 
 
 G (do not erase screen). 
 
 bit k: 1 (before displaying block (bit2=0), add frame to the screen) 
 
 (do not add frame). 
 
 bit 5 : ( always ) . 
 
 bit 6- 
 
 bit 11: data block (FCB), 1 (line block 0), etc., or 
 
 mnemonic as per section 1.6 (IR). 
 
 For example, type = U001 would cause the block in the record to be treated 
 as a line block. It would be put in the work block and a display file 
 would be created from it ; this file would be sent to the terminal 
 immediately. A subsequent type U002 record would cause a text block to be 
 displayed (the old contents of the work block area replaced (lost) by 
 the text block). In both cases, the current picture (FCB plus blocks 
 0...11J is undisturbed. A type 700U record would cause the current 
 picture's terminal block to be replaced by the block in the record; no 
 display activity occurs. 
 
 Other options can be set with certain words in the FCB; REACT 
 currently uses only the first six words, of the FCB. The first four words 
 specify a picture name as usual; if the first word is nonzero, this name 
 is put into the current picture FCB. The fifth word specifies the "auto- 
 save" option: 
 
 = auto save off (do not save current picture in IR) 
 
 1 = auto save on (save current picture in IR) 
 
 2 = purge (current picture is purged from core) 
 
3^ 
 
 The sixth word (IMASK in CALLER/ COMMUNE ) sets the joystick and keyboard 
 filter of the console vector; this word is always saved in the sixth 
 word of the current picture FCB, except when auto-save = 2 (see below). 
 
 hit 0: echo (0=display keyboard line typed by the user on 
 the screen at the available location after 
 transmission to the 360 ; l=no display). 
 
 bit 1- 
 
 bit 9' screen areas (l=accept joystick hit in corresponding 
 
 screen area 1-9; 0=do not accept), 
 bit 10: keyboard (l=accept; 0=do not accept), 
 bit 11 : ( spare ) . 
 
 A typical sequence would be: l) record type U000 (FCB) with fifth word = 2 
 arrives; the current picture is removed (note that when this option occurs, 
 no other options such as reset name or alter filter are executed); 2) record 
 types 7001, 7002, 7003, 7005, and 7006 arrive (in any order), these new blocks 
 (line, text, instance, terminal, and first nonstandard) become the 
 respective blocks of a new current picture; 3) another record type U600 
 arrives, the fifth word is N0T=2 , so other options are examined. The first 
 word is not zero , so a new name is put in the current FCB ; the sixth 
 word is used to reset the console vector filter; and bits 0600 indicate 
 the screen is to be erased and the frame added. However, word five is 
 examined again after the filter is reset and before 0600 is tested. The 
 content is formed to be 1, so the current picture (new FCB with new blocks) 
 is saved in IR; 0600 is not tested in this case. Note that 700x, 460x, and 
 UoOx records can arrive at any time ; hence , the 360 program can aribitrarily 
 change any block in the current picture (700x) . Moreover, the current 
 display can be arbitrarily changed (U60x) or added to (^00x). This is the 
 essence of the philosophy behind REACT. 
 
 Mnemonics can also be saved automatically (but not displayed). 
 Any block of type >U012 (e.g. ^OUl) is considered a mnemonic; these 
 blocks must always be marked for "replace in work block" (type bit 1=0). 
 The first six words of the first block entry are examined; if word five=l 
 (as with an FCB), the assumed mnemonic is saved in IR with the name 
 supplied by the first four words. No other FCB options apply. 
 
35 
 
 The second area of mention is a short note involving the 
 display of an instance block located in -work block 12 „. REACT uses a 
 little trick to call GREGNE to accomplish the regeneration. Consult 
 the listing at label "C0MINS" since this is a handy procedure to know. 
 
 REACT has many interesting sections of code that call system 
 functions (e.g., send picture, send block, save picture, etc.). One of 
 particular interest is the handling of input data structure blocks via 
 MR2TB. Consult the listing at label "C0MMTB." 
 
 Short, annotated flowcharts giving the overall flow of control for 
 currently available program segments are found in Appendix E. 
 
36 
 
 REMOTE SUBSYSTEMS 
 
 As is shown by Figure 1, three subsystems plus "user level 
 programs" (hereafter termed "programs") comprise the remote section 
 
 of GRASS. 
 
 The top most monitor level (G80PERAT) is responsible for 
 communicating with the operator, for performing the actual 2701 I/O 
 linking the remote and local computers, and for controlling the second 
 level of the monitor. The lower level (SPACT) is a complete multi- 
 terminal package, capable of attaching a separate task (program) to 
 each terminal. Each task can then communicate with its assigned terminal 
 and with the filing system (XFILE) . XFILE provides permanent storage 
 for picture and other data generated by programs or transmitted from the 
 satellite PDP-8. 
 
 Complete descriptions of the operation of the 2701 link, XFILE, 
 and the monitors, from the viewpoint of the terminal user and his programs 
 are provided in [8, 9 5 and 7l« These topics, as such, will not be 
 presented here. Information for generating and running the system is 
 found in Appendix B, Part 2. 
 
 G80PERAT is considered as the only truly permanent (e.g. 
 continuously resident) part of the system. Current operator commands 
 include : 
 
 S name parm (start second level module called "name" and pass 
 
 it "parm") 
 ZAP (unconditionally stop (e.g. detach) second level) 
 HALT (request second level to stop) 
 
 DUMP (output dumps for second level and all its subtasks) 
 NEVER (execute STAE as added protection against bomb-out) 
 UWEVER (delete STAE condition) 
 GRASS-0UT (terminate execution) 
 
37 
 
 Whenever the second level is NOT attached, any input records from the 
 PDP-8 are considered to be operator commands. In addition, G80PERAT can 
 be passed a command as a parameter when it first begins execution. Some 
 special options can be specified in this last case: use of the WT0R's 
 for communicating with the 360 machine operator, as well as use of the 
 system timer, can be suspended. 
 
 G80PERAT uses the "P8" type macros (see below) for direct 
 communication with the 2701. All hardware error diagnostics and retries 
 are performed on a given read or write operation by G80PERAT. No 
 assumptions are made about the data nor is the data transformed in any 
 way (except, of course, in the case of command records). Records are 
 read or written only as requested by the second level of the monitor. 
 
 The system's second level can by any program, and more 
 specifically, might be any program using the "G8" type macros (see 
 below) to request G80PERAT to read or write over the 2701. In particular, 
 the second level currently used is the multi-terminal package, SPACT. 
 SPACT has several functions, the primary being the attaching or detaching 
 of any program module associated with any given user terminal in the system. 
 SPACT also maintains an input/output record queuing system to allow each 
 program in the 360 to communicate with the terminal to which it is attached, 
 Any 2701 input record of type=0 (c.f. G8-macro descriptions) with first 
 character of "!" is assumed to be a SPACT command. All other 2701 input 
 is assumed to be data for the attached user programs. SPACT only 
 examines the data portion of command records . The data of all other 
 records is solely the responsibility of the issuing or receiving program 
 module. The format of 2701 records is adequately described in [9]; long 
 data records are handled with a two-part transfer as discussed in F027O1 
 (section 1.6) . 
 
 Any user program can run under SPACT, but again, those of 
 particular interest are the ones that communicate with the terminals via 
 the 2701. Examples are LSD and the various modules of the Simulation and 
 Modeling System [5, 8]. These modules utilize the S8-macros [9] to fetch 
 
38 
 
 records out of SPACT's input queue or place records into its output 
 queue. Since the relationship of program-to-terminal is maintained by 
 SPACT, any program can be attached to any terminal. Furthermore, the 
 S8-macros can be used in re-entrant programs, so if more than one terminal 
 wants the same program simultaneously, only one copy of the program need 
 be in core. For similar reasons, re-entrant user program linkage to 
 XFILE is also possible [9]. 
 
 In the following discussions, some knowledge of 0S/36O 
 programming has been assumed. Note that the entire monitor and XFILE 
 complex runs exclusively in bulk core; appropriate use of HIARCHY=1 has 
 been made throughout (GETMAIN, ATTACH, LINK, L0AD, XCTL, etc.). The 
 monitors and XFILE require approximately 18-20K bytes of memory; the 
 number and size of user programs to be run concurrently under SPACT 
 dictates the total memory space (REGI0N) that must be assigned to the job. 
 
 2.1 G80PEPAT 
 
 The overall flow of control for this module is shown in 
 Figure 15. Salient features include: (numbers refer to indicated 
 flowchart boxes) 
 
 1. All G80PERAT flags are set to (off) . The PARM field 
 from the 0S EXEC statement is examined for initial parameters. The 2701 
 link is made available via 0PEN and ENBATN (enable attention) macro calls. 
 
 Note that ENBATN is a simple installation 0S modification that 
 allows a program to realize that a device desires service . Such a 
 facility is not normally available in 0S 360 but is usually added at 
 installations where timesharing systems are hung on 360 machines. 
 
 The parameter string format for the PARM field is: 
 
 [ [option] [command] ] 
 
 Valid "options" are NM, MS, NT, TM, and {NM,MS}{NT,TM} ; an example of the 
 last is MSNT. Unless overridden, MS and TM are assumed by G80PERAT. The 
 
39 
 
 "command" is always passed to the operator command analyzer as if it had 
 been received from the 3^0 operator. This is a handy debugging aid and 
 is also convenient for starting SPACT (e.g., command = S SPACT) automatically, 
 Any G80PERAT command can appear in "command." 
 
 MS 
 NT 
 TM 
 
 do not issue WT0R's to operator 
 issue WT0R's, as normal 
 do not use system timer 
 use system timer, as normal 
 
 2. Await an event or system timer. An 0$ (and HASP) feature 
 exists that causes termination of a job if that job remains in the wait 
 state (inactive) for more than a certain number of minutes. Since this 
 is an interactive monitor, the possibility of a long wait between events 
 exists. Hence, the system timer is used to interrupt G80PERAT (make it 
 active) periodically to avoid cancellation. During debugging, use of 
 the timer in this manner is often not desired, hence the NT option. 
 
 3. Execute the indicated command . All commands have the form 
 Verb [Object] [parameters] where Verb is the field tested by the command 
 analyzer. It is the responsibility of the routine that executes the Verb 
 to test and use the remaining fields as needed. ZAP, HALT, DUMP, NEVER, 
 UNEVER, and GRASS-0UT as listed previously are straightforward and self- 
 explanatory. Only "S name parm" (start second level) need be discussed here 
 
 G80PERAT uses an ATTACH macro to begin execution of module 
 "name" as a subtask. This subtask is passed a parameter list address in 
 register 1; the list format is: 
 
 +0 
 
 +k A( request ECB's) 
 
 +8 A(parm string) 
 
 The subtask must P0ST the first location in the list when it begins 
 executing (c.f. G8ENTRY macro description). This notifies G80PERAT that 
 
ko 
 
 the subtask has indeed begun executing; G80PERAT will then continue 
 normal processing. If 0S 360 P0ST's the task-termination ECB specified 
 in the ATTACH macro before the subtask Pj&ST's its location, G80PERAT 
 assumes execution of the subtask never started (module not found, 
 insufficient core, etc.). 
 
 When G8ENTRY, in the subtask, P0ST's list location +0, 
 it also inserts the address of a subtask ECB into the location. If 
 G80PERAT P0ST's this ECB, the subtask must terminate processing; this 
 ECB is tested whenever the subtask issues a G8WAIT macro. A HALT 
 command, or a GRASS-0UT command while a subtask is executing, will cause 
 G80PERAT to P0ST this subtask ECB. 
 
 The subtask G8EHTRY macro also extracts the information at 
 +k and +8 in the list. Whenever the subtask desires 2701 input or output, 
 the appropriate ECB in the pair pointed to by the address at +k must be 
 P0STed. The subtask inserts the address of a record request block into 
 the P0STed ECB (c.f. G8-macro descriptions). The "parm" field in the 
 start command is copied into a 3^ byte area before the ATTACH is issued; 
 the address of this area is placed in +8 of the list. Access to the 
 parameter is thus provided; if no parameter was specified, "$N" is placed 
 in the area. 
 
 Figure l6 summarizes these linkages between G80PERAT and 
 its subtask. 
 
 k. Indicate 2701 operation complete . G80PERAT uses the subtask 
 record request block address found in the appropriate read or write 
 request ECB. The first word at this address is P0STed by G80PERAT with a 
 completion code. Consult Figure l6. 
 
 5. Execute 2701 operation . The P8-macros, described below, are 
 used to transmit data to the PDP-8. The G8-macros used by subtasks are also 
 described here to increase understanding of their interaction with G80PERAT. 
 Consult Figure l6. 
 
Ill 
 
 Necessary information is extracted by G80PERAT from the 
 indicated record request block; P8EETRY is used to perform the desired read 
 or write operation. The actual transmission routines are generated by 
 P80PRS and P80PRSX. Lower level P8-macros (P8RCCW, P8WCCW, and P8WAIT) 
 are available for more flexible use of P80PRS facilities. 
 
 label P8RETRY0P, data addr, len, retry count [,ECBLST=, 0THER=] 
 
 Generates : 
 
 BAL 1, *+20 
 
 DC A (data addr) 
 
 DC ALl( retry count) 
 
 DC AL2(0P) 
 
 DC AL2(len) 
 
 DC A(ecb list) 
 
 DC A(other evert routine ) 
 
 BAL Ik, PDP8RTRY 
 
 (Rl points to params , RlU is the return register) 
 
 0P is X'll 1 (WRITE), X'12 1 (READ), or (R) (X'll' or X f 12' is in 
 register R) . Retry count should be less than 20. 
 
 ECBLST and 0THER are optional: 
 
 ECBLST is the address of a list of ecb addresses containing 
 
 at least 'PDP8ECB' BUT NOT 'PDP8ATTN'. 
 
 If omitted, a list containing only 'PDP8ECB' is used. 
 
 0THER is the address of a routine to be entered if an ecb 
 is posted besides 'PDP8ECB' (i.e. ECBLST=lab was coded). 
 
 Rl = A( ecb list) 
 RlU = return address 
 R15 = routine address 
 
 The routine must "take note," clear the appropriate ecb, and 
 return via KLk to await I/O quiescence. The routine must save 
 registers 0, 1, 13, lh, 15- 
 
 On return from P8RETRY, the operation (including any needed retries) is 
 complete and R15=0K(O), ERR(*0 , T0(8), or ATTN( write only) (12). 
 
k2 
 
 Note that on initial entry to PDP8RTRY for READ, the system assumes 
 'PDP8ATTN' has already been posted and then cleared by caller. If 
 retries are needed, the system waits for a new posting of 'PDP8ATTN f 
 before each retry. If such a post does NOT occur within 10 seconds, 
 retry processing is terminated and R15=8(T0) is returned to the 
 calling program. 
 
 P80PRSX 
 
 (contains the actual retry routines and linkages to P80PRS) 
 
 P80PRS 
 
 (contains the actual 2701 I/O routines, DCB, I0B, ECB's, etc.) 
 
 Generates : 
 
 PDP8READ (start read operation) 
 
 PDP8RITE (start write operation) 
 
 PDP8EXCP (start EXCP I/O as indicated by PDP8READ or PDP8RITE) 
 
 PDP8WAIT (await EXCP completion) 
 
 PDP8DCB (link to 2701) 
 
 PDP8ELST (default ECB list for PDP8WAIT) 
 
 PDP8ECB (EXCP completion ECB) 
 
 PDP8ATTN (2701 attention ECB posted by 0S) 
 
 Ihe user (e.g., G80PERAT) must issue 
 
 0PM ( PDP8 DCB , ( INPUT ) ) 
 
 ENBATN DCB=PDP8DCB,ECB=PDP8ATTN 
 
 oefore using the 2701 facilities and must issue 
 
 ENBATN DCB=PDP8DCB 
 CL0SE (PDP8DCB) 
 
 oefore exiting to 0S when the job terminates. Also, a DD card named 
 'PDP8DD' must be included in the job's JCL to define the 2701: 
 
 //PDP8DD DD UNIT=021 
 
 Note that if a delay in dispatching the task occurs, it is possible that 
 "PDP8ATTN 1 or some other ecb may have been posted between the time 
 'PDP8ECB' was posted (Operation complete) and the time control is returned 
 to the calling program. Hence, care should be exercised in the use of 
 any "safety" clears of ecb's. 
 
k3 
 
 label {p8WCCW* data addr > len 
 
 Generates : 
 
 BAL ik, PDP8READ 
 BAL Ik, or PDP8RITE 
 
 RO contains the byte len: if >i+095, this must be specified as in a 
 register , i.e., 'data addr,(R)'. 
 Rl contains the data addr. 
 
 The above call results in the generation of a simple COW; this 
 CCW is then passed to PDP8EXCP to perform the actual operation. P8RCCW 
 and P8WCCW are used in conjunction with P8WAIT to give the program complete 
 control over the I/O operation. P80PRSX actually uses P8RCCW, P8WCCW, 
 and P8WAIT. Note that performing complex I/O functions is possible. 
 Instead of using P8RCCW or P8WCCW, the program can build its own chain 
 of CCWS. Then the program executes BAL 1U,PDP8EXCP with the address of 
 the CC¥ chain in register 1. 
 
 label P8WAIT ecbaddrlist ,0Kaddr,ERRaddr,T0addr[ ,N0T27Olecbaddr] 
 
 Generates : 
 
 BAL Ik , PDP8WAIT 
 
 B 0Kaddr successful completion return 
 
 B ERRaddr hardware error return 
 
 B T0addr timeout return 
 
 [B N0T2TOlecbaddr return if event other than 2701 occurs] 
 
 Rl contains the address of the ecb-address list : this list must contain 
 at least PDP8ECB . If only PDP8ECB is included, 'N0T27Olecbaddr' should 
 be omitted. PDP8ELST may be used for 'ecbaddrlist ' in which case only 
 PDP8ECB in a standard list will be used. In the event of a , N0T27Olecbaddr' 
 return, the program must "take note," clear the appropriate ecb, and issue 
 a new PoVAIT . 
 
 G8ENTRY termecb 
 
 Generates : 
 
 G8RWC0M (request read or write from G80PERAT) 
 
 G8WTC0M (await operation completion) 
 
 G8RDECB (record request block 1 (READ)) 
 
 G8RTECB (record request block 2 (WRITE)) 
 
kh 
 
 This macro must be issued by the subtask of G80PERAT after addressing is 
 established but before register 1 is destroyed. Besides linking the 
 subtask to G80PERAT, G8ENTRY contains the routines used by G8READ, G8WRITE 
 and G8WAIT for communicating 2701 records via G80PERAT. The subtask must 
 provide a vord to be used as the HALT request ecb at 'termecb'. 
 
 , , ., rG8READ i a , 
 
 label GflWRTTF ^ a ^ a a ddr, len 
 
 Generates : 
 
 BAL 1, *+12 
 
 DC A(data addr) 
 
 DC X'00', ALl(0P), AL2 (len) 
 
 BAL iU,G8RWC0M 
 
 label G8WAIT ecb list addr [ ,0THER=routine addr] 
 
 Generates : 
 
 BAL lU , G8WTC0M 
 
 R0 contains or the routine address of an 'other-event' routine, Rl 
 contains addr of ecb addr list (minimally: G8RDECB and G8RTECB; usually 
 plus terminal, etc.) Blk is return register. 
 
 On return, R15=0K(O), ERR(U), T0(8), or ATTN(write only) (12). On 'other- 
 event' routine entry, the program must take note, clear the ecb, and issue 
 a new wait as in P8WAIT . 
 
 2.2 SPACT 
 
 The overall flow of control for this module is shown in 
 Figure 17. Salient features include: (numbers refer to indicated 
 flowchart boxes ) 
 
 1. Set-up to begin . G8ENTRY is called to link SPACT to 
 G80PERAT; XFILE is L0ADed and its entry address saved. SPACT then sends 
 a monitor-monitor record to the PDP-8 ; this record (type=7770) indicates 
 to the PDP-8 that the 360 is available. 
 
^5 
 
 2. P0ST G80PERAT with read request . Since a P0ST is used, 
 care must be taken that a second P0ST does not occur before G80PERAT 
 clears the first. Three special tests are thus performed before SPACT 
 issues its outstanding G8READ request. 
 
 3. Await event including 2701 Eead/Write . The test for part 1 
 or part 2 of the record that appears in the flowcharts at B and C is 
 really taken care of by the code after the G8WAIT. Whenever a read or 
 write is started, the initializing routine sets the appropriate return 
 address into WTRET or RDRET. 
 
 k. Execute the indicated command . After removing the leading 
 "!," SPACT commands are identical in format to G80PERAT commands. All 
 are self-explanatory except for Start, which will be discussed briefly 
 here. Start works exactly the same in SPACT as it does in G80PEFAT, 
 except that the parameter list is different and S8ENTRY performs the 
 linkage from user programs to SPACT. Consult [9]. The linkage performed 
 by S8EWTRY is shown in Figure 18 ; the terminal control area for each 
 terminal is shown in Figure 19. 
 
 As general information, note that the S8-macros interact with 
 SPACT in a manner directly analogous to the interaction of the G8-macros 
 with G80PERAT. Furthermore, as is obvious from Figure IT, SPACT transmits 
 long records in two parts in a manner directly analogous to the operation 
 of T027O1 (section 1.6). 
 
he 
 
 KEGURES 
 
hi 
 
 w 
 
 CO 
 
 1-3 
 
 Q 
 
 B 
 
 *H 
 
 X! 
 
 W) 
 
 RAT 
 
 Pro 
 
 W Eh 
 
 
 Ph q 
 
 u 
 
 tS. < 
 
 <u 
 
 00'**pL < -* 
 
 '-^ to 
 
 t3 CO 
 
 E=> 
 
 H 
 £ 
 
 o 
 
 LT\ 
 
 O 
 
 en 
 
 
 Ph 
 
 CO 
 Pf 
 •H 
 .3 
 
 m 
 o 
 
 H 
 CU 
 K 
 
 is 
 o 
 
 O 
 
 -P 
 
 
 a5 
 
 M 
 
 a 
 
 CU 
 
 -p 
 w 
 !» 
 
 0) 
 •H 
 
k8 
 
 ra 
 
 -P o 
 
 o3 H 
 
 a pq 
 
 Sd 
 
 M 
 
 o 
 
 p 
 
 o 
 o 
 
 pq 
 o 
 
 ft 
 
 o 
 
 o 
 
 H 
 
 o3 
 
 a -p t* 
 
 •h <u 
 
 a ft <h 
 
 0) s 3 
 
 EH O rO 
 
 o 
 o 
 o 
 
 H 
 
 pq 
 o 
 ft 
 
 o 
 o 
 o 
 
 O 
 
 o 
 
 o 
 
 w 
 S-i 
 
 a; 
 -p 
 
 a3 
 ft 
 
 0) 
 o 
 
 •H 
 
 fc 
 CD 
 
 CO 
 
 ■ o 
 
 -3- 
 
 Q 
 
 O 
 O 
 
 CM 
 
 f F 
 
 
 1 
 
 w 
 
 
 
 
 ^ 
 
 
 
 
 CD 
 
 
 
 a) 
 
 P 
 
 
 
 H 
 
 <L! 
 
 
 
 O 
 
 S 
 
 
 
 W 
 
 o3 
 
 al 
 
 
 S 
 
 U 
 
 <u 
 
 
 o 
 
 o3 
 
 ^ 
 
 
 o 
 
 ft 
 
 a3 
 
 
 -p 
 
 <D 
 
 ,d 
 
 w 
 
 a 
 
 o 
 
 o 
 
 9 
 
 
 
 P 
 cd 
 
 a 
 
 s 
 
 
 o 
 
 o 
 
 o 
 
 w 
 
 W 
 
 ft 
 
 o 
 o 
 o 
 
 i. 
 
 o 
 t- 
 
 OJ 
 
 o 
 o 
 o 
 
 D 
 Oh 
 O 
 
 O 
 O 
 O 
 
 w 
 
 •H 
 
 CM 
 
 o 
 o 
 
 1 
 
 T 
 
 13 
 
 T3 -H 
 
 d to 
 
 a3 G 
 
 CD 
 
 S P 
 
 2 X 
 
 CO W 
 
 O 
 
 o 
 
 J- 
 
 CO 
 
 Sh 
 O 
 -P 
 O 
 CD 
 > 
 
 o 
 w 
 
 a 
 o 
 o 
 
 o 
 
 
 oj 
 
 & 
 O 
 
 u 
 ft 
 -p 
 
 fl cd 
 
 3 CD 
 O 03 
 
 H 
 
 Jt 
 
 tu 
 
 ■a 
 
 o 
 
 H 
 O 
 !h 
 
 •P 
 
 § 
 
 a 
 
 0) 
 
 p 
 
 CD 
 
 !» 
 CQ 
 
 «H 
 
 O 
 
 S3 
 O 
 
 •H 
 P 
 0} 
 
 t) 
 O 
 
 K 
 
 o • « 
 
 • o • • 
 
 • O O 
 
 o • 
 
 • • O 
 
 O • 
 
 ■ • O 
 
 CM 
 
 -3- 
 
 LA O 
 
 O 
 
 o 
 
 O 
 
 o 
 
 
 H 
 
 H CM 
 
 O 
 
 o 
 
 O 
 
 o 
 
 
 
 
 H 
 
 CM 
 
 -=t 
 
 VD 
 
1*9 
 
 addr 
 
 +0 
 +1 
 +2 
 
 +3 
 
 +k 
 +5 
 
 +12 
 +13 
 
 contents • 
 
 function 
 
 +50 
 
 +77 
 
 \ service request return data 
 
 CIF CDF 
 
 ADDR 
 
 Request No. (0=free(No Request), >0=Service Requested 
 
 -l=Service Being Processed) 
 
 Cons ole Status ( 0=inactive , 4000=of f line , 2000=active , 
 
 >2000=console input pending) 
 
 Input flags: 010 000 00A BCD (A-D=timer, DPU, operator, 
 
 2701, respectively) 
 
 Prog ID (0-31) 
 
 initially 
 
 
 
 'PSN0NAMEABCD' 
 USER ID 
 
 (8 bits-Acct No, 4 bits- 
 User No. ) 
 
 +14 
 
 Interval Durati 
 
 on 
 
 
 ^ 
 
 _ 
 
 +15 
 +16 
 
 Zero or nonzero 
 Interval Count 
 
 
 
 / Timer Queue Element 
 
 
 
 +17 
 
 Interval Duration 
 
 Reset 
 
 J 
 
 - 
 
 +20 
 
 2701 
 
 
 
 ^ 
 
 — 
 
 +21 
 
 Operator 
 
 
 
 V Console Input Prog Entry 
 
 - 
 
 +22 
 
 DPU 
 
 
 
 [Addresses (zero on entry 
 
 - 
 
 +23 
 
 Timer 
 
 
 
 ) from caller) 
 
 - 
 
 +24 
 
 Screen Seg #0 
 
 
 
 > 
 
 - 
 
 . 
 
 
 
 
 \ Joystick Input Filering 
 J Control 
 
 
 +35 
 
 Screen Seg #9 
 
 
 
 _ 
 
 +36 
 
 Keyboard input 
 
 control ( 
 
 routine address or 0) 
 
 - 
 
 +37 
 
 2701 Indicative 
 
 message 
 
 control (next screen Y) 
 
 - 
 
 +1+0 
 
 SVPRM1 
 
 
 
 1 
 
 - 
 
 ; 
 
 
 
 
 /Service Parameter Save 
 
 • 
 
 +47 
 
 SVPRM8 
 
 
 
 J Area During GUTS Call 
 
 - 
 
 /Workspace Save Area 
 
 Figure 3 . Console Vector Detail 
 
50 
 
 addr 
 +0 
 
 +57 
 
 contents 
 
 function 
 
 Current file Data block allocation 
 
 Control block (FCB) 
 
 +60(10) 
 +6i(ll) 
 
 +70(12) 
 +7M13) 
 
 Work blk 
 Re gen blk 
 
 Spare 
 
 Menu blk 
 
 Mnemonic construction, commune 
 
 temporary, etc. 
 
 Work area for instance regeneration 
 
 Local file names control 
 
 +100 
 
 BLKNUM 
 
 +101 
 
 (lockout) 
 
 +102 
 
 Spare 
 
 +103 
 
 Spare 
 
 +10 k 
 
 SHDPERG 
 
 +105 
 
 SHDPTR 
 
 +106 
 
 SHDRGN 
 
 +107 
 
 Address of last blk investigated 
 Special lockout flag (-1) 
 
 ENT0RG before last reset 
 P0INTR before last reset 
 Blk no of instance block 
 during regen 
 
 Spare 
 
 +110 
 
 MNM0D(O) 
 
 +111 
 
 Spare 
 
 +112 
 
 YH 
 
 +113 
 
 XH 
 
 +111+ 
 
 Y scan (1000) 
 
 +115 
 
 X scan (1000) 
 
 +116 
 
 Spare 
 
 +117 
 
 Spare 
 
 P0INTR displacement (idle value = 0) 
 
 Y position on J.S. bit 
 X position on J.S. hit 
 Draw area 
 reference center 
 
 +120 
 
 +177 
 
 PCW0RK 
 
 Program segment scratch area 
 (kO words = 80 characters 
 8 words = control) 
 
 Figure k. Picture Control Block (PCB) 
 
51 
 
 addr contents 
 
 +0 
 
 +k 
 
 +5 
 
 +6 
 
 +7 
 
 +10(0) 
 
 +14(1) 
 
 +20(2) 
 
 +24(3) 
 
 +30(4) 
 
 +34(5) 
 
 +5^(9) User 5 
 
 +5T-End 
 
 Six character name plus two spare characters 
 
 Spare (0) 
 
 Spare (0) 
 
 Protection 
 
 User ID 
 
 Local lines -v 
 
 Comment text l System standard data 
 
 Subpicture instances / "block control entries 
 
 (Reserved) J 
 
 Terminal Types, Connections, and Terminals 
 
 User 1 
 
 User defined data 
 block control entries 
 
 } 
 
 Figure 5a. File Control Block 
 
 Word 1 
 
 CIO 000 0NN NNN C=0(incore) or l(not) 
 
 I=0( initialized) or l(not) 
 
 NNNlJN=number blocks allocated or 
 
 Word 2 
 
 FUA AAA A00 000 F=0(not fixed) or l(fixed) 
 
 U=( reserved) 
 AAAAA=block addr in DSBANK 
 
 Words 3 
 
 ENT0RG last used for this block; saved here on return from any DSMN routine. 
 
 Word k 
 
 P0INTR last used for this block; saved here on return from any DSMN routine, 
 
 Figure 5b. Data Block Control Entry Detail 
 
52 
 
 PCB supplied control itemt : 
 
 BLKNUM=j (block under consideration) 
 
 BLKORG=A (starting addr) 
 
 ENTORG=;B Gentry in block under consideration) 
 
 -.POINTH»C. (data in entry under consideration) 
 
 block j control entry: 
 
 allocated blocks (NNNNN)=LL 
 
 Core addr (AAAAA)=A 
 
 control 
 
 DS BANK data block: 
 
 data 
 
 B+e 
 
 A+L 
 
 — disp to end=L* 
 pdisp to next** 
 
 i-disp to next=e 
 
 •{ data ) 
 
 ,disp to next 
 
 ■END 
 
 A+LL- 
 
 -(allocated) 
 
 Disp-to-end ALWAYS < 20U8 (i.e., positive); hence, maximum len of 
 data in a block < 20^7. 
 
 ** Disp -to-next -entry ALWAYS < 20>+7 (i.e., < L) ; hence, maximum len of 
 data in an entry < 20k6. 
 
 Figure 6. PCB Control and Data Structure Relationships 
 
Lk 
 
 53 
 
 -Disp to End 
 
 -Disp to next entry - entry 1 (PT-PT lines) 
 
 Displacement applied to all 
 points in entry. 12 -bit signed 
 numbers. Ususally = (0,0) 
 
 Four word line or symbol group. 
 Y , X is starting point. 
 
 If S=0, IX is ending point 
 
 If S=l, Y X is a reference 
 
 to a closed vector-generated 
 symbol centered on IX. The 
 
 symbol is inserted into display 
 file during display operation. 
 
 Y, X are absolute points w.r.t. (0,0) 
 
 
 dY 
 
 
 dX 
 
 
 
 Y l 
 
 
 
 X l 
 
 s 
 
 Y 2 
 
 
 X 2 
 
 END 
 
 Figure 7« Line Block (No. 0) 
 
 — Disp to End 
 
 r~Disp to next entry - entry 1 (standard text entry) 
 
 Absolute point w.r.t. (0,0) which gives 
 the upper left coordinates for the 
 top line in a contiguous line group. 
 
 Y l 
 
 
 x l 
 
 
 len 
 
 \ 
 
 text 
 
 A i 
 
 len 
 
 B i 
 
 text 
 
 B i 
 
 'Disp to next 
 
 Y 2 
 
 
 \ 
 
 
 len 
 
 A 2 
 
 text 
 
 A 2 
 
 len 
 
 B 2 
 
 text 
 
 B 2 
 
 
 
 len = number of words 
 of text 
 
 entry 2 text = string of trimmed 
 
 ASCii characters, 
 two per word 
 
 entry i 
 
 'END 
 
 Figure 8. Text Block (No. l) 
 
5U 
 
 i~ Disp to End 
 
 r Disp to next entry- 
 Name 1,2 
 Name 3 ,** 
 Name 5 >6 
 Name Option 
 Y 
 X 
 00 (INST SEQ NO) 
 
 USER ID 
 J*Disp to next entry 
 Y 
 X 
 
 L i 
 
 Text 1 
 
 L 2 
 
 Text 2 
 
 HDisp to next entry 
 13UU 
 
 
 L i 
 
 Text 1 
 
 L 2 
 Text 2 
 
 entry 1 (control for first instance) 
 six character name of mnemonic 
 
 two character option (koko-kok'j) 
 
 position of instance center 
 
 w.r.t. (0,0) 
 
 identification number assigned to 
 
 this instance 
 
 ( creators ) 
 
 entry 2 (Parameter Assignment) 
 
 standard text entry 
 (c.f. block 1) 
 
 (but Y, X relocated w.r.t. entry 1 Y, X) 
 parameter values assigned to 
 this instance 
 
 - entry 3 (type name list) 
 
 standard text entry 
 (c.f. block 1) 
 
 type names referenced by 
 terminals of this instance 
 
 'Disp to next entry - entry k (control for second instance) 
 
 every three entries specify 
 a mnemonic instance 
 
 END 
 
 Figure 9- Instance Block (No. 2) 
 
55 
 
 Disp 
 
 to End 
 
 Disp 
 
 to next entry 
 Y = 13UH 
 
 
 X = 
 
 
 L i 
 
 
 TXT 
 
 
 L 2 
 
 
 TXT 
 
 - entry 1 (type name list for local terminals) 
 
 standard text entry 
 
 *Disp to next entry - entry 2 (terminal connection list) 
 VO(FROM TRM SEQ WO) 
 00(T0 TRM SEQ NO) V=l, visible connection; =0, invisible 
 
 FROM (TRM SEQ N0) ! s are 10 bits each 
 
 TO 
 
 ^Disp to next entry 
 0D(INST SEQ NO) 
 
 V0 (TRM SEQ NO) 
 
 A0 (TYPE NAME NO) 
 
 00 (Y) 
 00 (X) 
 T)isp to next entry 
 
 L 
 
 ■*"END 
 
 - entry 3 (first terminal) 
 
 0=1, local terminal; =0, terminal 
 belongs to a subpicture instance 
 
 D=l, external (0 must = l) , 
 =0, internal 
 
 (INST SEQ NO) is 10 bits specifying 
 subpicture instance to which 
 terminal belongs (e.g. if = 0) 
 
 V=l, blank numeric data during display; 
 =0, normal terminal display 
 
 (TRM SEQ NO) is 10 bits specifying 
 identification assigned to this terminal 
 
 A=l, type not assigned; =0, type assigned 
 
 (TYPE NAME NO) is 10 bits indicating 
 type name. If terminal is local (0=1) 
 reference is to entry 1 of this block; 
 if an instance terminal (0=0), 
 reference is to type name list in 
 instance entry specified by (INST SEQ NO). 
 
 Center of terminal symbol 
 
 - entry k (second terminal) 
 
 Typical instance/internal terminal appears as . where 'b3T' is 
 generated from (TRM SEQ NO) and 'b' is generated from 0D 
 
 Figure 10. Terminal Block (No. k) 
 
56 
 
 Disp to End 
 
 f-Disp to next entry- 
 Name 1,2 
 Name 3 9 h 
 Name 5 ,6 
 Name option 
 Spare 1=0 
 Spare 2=0 
 00 protection 
 User's ID 
 "Disp to next entry 
 Y 
 X 
 
 h 
 
 Text 
 
 V 
 
 Text,. 
 
 Disp to next entry 
 Y = 13UU 
 X = 
 
 L i 
 
 Text 
 
 L 2 
 
 Text„ 
 
 ^)isp to next entry 
 A0 (TYPE NAME NO) 
 
 Y i 
 x i 
 
 AO (TYPE NAME NO) 
 
 Disp 
 
 to next 
 dY 
 dX 
 PT Y 
 
 PT X 
 
 PT 2 Y 
 
 PT 2 X 
 
 entry 
 
 entry 1 (control) 
 six character name 
 
 2 character option (UoUO-h-OUT) 
 
 (c.f. block 2) 
 
 creator's ID, not current user 
 
 entry 2 (parameter model list) 
 
 standard text entry 
 (c.f. block 1) 
 
 - entry 3 (type name list) 
 
 standard text entry 
 (c.f. block 1) 
 
 entry k (terminal list) 
 
 A=l, type not assigned; =0, assigned. 
 
 (TYPE NAME NO) is index into entry 3 
 of this block 
 
 List corresponds in order to external 
 terminals in structure definition 
 
 - entry 5 (lines) 
 
 standard line entry 
 
 (c.f. block 0) 
 
57 
 
 ~Disp to next entry - entry 6 (comment text) 
 " . Y 
 X 
 L standard text entries 
 
 Text (c.f. "block l) 
 
 L 2 
 
 Text„ none, one or several of 
 
 these entries may be 
 '. present 
 
 - entry: (comment text) 
 
 I 
 
 END 
 
 Figure 11. Mnemonic Storage Block (M.S.B.) 
 
 ■Disp to End 
 
 ■Disp to next entry - entry 1 (only entry) 
 
 Name each 'name' is four words lon| 
 
 6 characters plus type word 
 
 Name 127 
 
 'END 
 
 Figure 12. Menu Block 
 
58 
 
 lUUo. 
 
 Xklk 
 
 1370 
 
 170 
 
 Ikk 
 
 120 
 
 Ik 
 
 50 
 
 2k 
 
 a SYSL ? 
 
 2tLINES 
 
 USEL V 
 
 3 TIME 
 
 -•.(1023,800) 
 
 11 
 
 1 MENU 
 
 32 -LINES 
 
 < 10 7-: 
 
 characters 
 
 2 ANSWER 
 3 -LINES 
 
 4- 
 
 3 YES/NO 
 2 -LINES 
 
 k DRAW AREA 
 
 -136U 
 
 MC 
 
 DC 
 
 75 
 
 characters 
 
 5 PROMPTS 
 
 ■<*l6k 
 
 6 LIGHT BUTTONS 
 
 9 PANIC 
 KLO -CHARACTERS- 
 
 KEYBOARD INPUT LINE 
 
 -irr- 
 i 
 
 170 
 l6h 
 
 -<=-70 
 
 n — 
 
 160k 
 1600 
 
 1777 
 
 DC (Draw Area Center) = (107^, 71*0 
 
 MC (Mnemonic Center) = (1000, 1000 ) 
 
 Draw Area = 6U0 by 90U points (U.5" by 7-5") 
 
 Characters = 8 by 12 points set in the lower left 
 
 corner of 12 by 20 point areas 
 The number to the left of each area name designates that area 
 (e.g., the Draw Area is screen segment k) 
 
 Figure 13. Display Screen Composition Detail 
 
59 
 
 number 
 
 
 1 
 2 
 
 3 
 h 
 5 
 6 
 
 7 
 10 
 
 11 
 
 12 
 13 
 11+ 
 
 15 
 16 
 
 IT 
 20 
 21 
 22 
 23 
 2h 
 
 25 
 26 
 27 
 
 30 
 31 
 32 
 33 
 3k 
 35 
 36 
 37 
 
 name 
 
 CALR 
 GSAM 
 LLSD 
 ARCH 
 TEXT 
 (etc. ) 
 
 GND1 
 GND2 
 GND3 
 
 function 
 
 Logon /program menu (SYSTEM) 
 Simulation and Modeling 
 Library Manipulation 
 Architectural Design Aid 
 Document Preparation 
 
 ) (APPLICATIONS) 
 
 generalized drawing 
 package 
 
 >) 
 
 GUT1 (mini text editor) 
 
 GUT2 (regen, file, send, menu) } Utility Functions 
 
 GUT3 (REACT) 
 
 DEX1 S 
 
 DEX2 1 Logon directory extensions (SYSTEM) 
 
 DEX3 J 
 
 SPIR (Spare) 
 
 PSIR IR initializer/blk sorter 
 
 Figure ik. Program Segment Allocation 
 
START 
 
 1 
 
 INITIALIZE 
 FLAGS, OPEN 
 PDP-8 LINK. 
 INDICATE EXEC 
 
 ■0 
 
 6o 
 
 MSG 
 
 SEND 
 
 MESSAGE TO 
 360 
 OPEFATOR 
 
 M 
 
 SET SYSTEM 
 TIMER, 
 AWAIT AN 
 EVENT 
 
 (Event Occurred) 
 
 Jwo 
 
 (ABEND since 
 invalid event) 
 
 Figure 15. G80PERAT Flow of Control (Part 1 of 2 ) 
 
RETURN 
 INVALID 
 COMMAND 
 MESSAGE 
 
 PERFORM 
 COMMAND. RETUBI 
 APPROPRIATE 
 MESSAGE 
 
 -Wmsg\ 
 
 61 
 
 CLEAN UP 
 TCB 
 
 MSG 
 
 YES 
 
 CLOSE PDP-8 
 LINK, IN DIC ATE 
 FINISHED 
 
 Exit to 0S/36O 
 
 YES 
 
 CONVERT TO 
 EBCDIC 
 
 MARK INPUT 
 PENDING 
 
 PERFORM READ 
 WITH TIMEOUT 
 AND SAFETY 
 TIMER 
 
 INDICATE 
 RESULT TO 
 SECOND LEVEL 
 
 MARK SECOND 
 LEVEL 
 REQUESTED 
 READ 
 
 YES 
 
 PERFORM WRITE 
 
 WITH 
 
 TIMEOUT 
 
 INDICATE 
 OUTPUT BROKEN 
 TO SECOND 
 LEVEL 
 
 INDICATE 
 RESULT TO 
 SECOND 
 LEVEL 
 
 <D 
 
 <D 
 
 Figure 15- (Part 2 of 2) 
 
62 
 
 After G80PERAT ATTACH of subtask, "but before G8ENTRY call: 
 
 Parmlist for subtask Subtask 
 
 +0 ( Unknown ) 
 
 +k A( RDRQECB) 
 +8 A( STRING) 
 
 G80PERAT 
 
 RDRQECB = 
 WTRQECB = 
 (e.g., WRTQECB is at R3DRQECB+4) 
 
 After G8MTRY call, but before any subtask 2701 requests: 
 
 Parmlist for subtask Subtask (within G8ENTRY) 
 
 +0 A(SUBTECB) +0 SUBTECB = (for G80PERAT 
 
 +k A(RDRQECB) +k A( RDRQECB ) HALT notice) 
 
 +8 A( STRING) 
 
 G80PERAT 
 
 RDRQECB = 
 WTRQECB = 
 
 Figure 16. G80PERAT/Subtask Linkage (Part 1 of 3) 
 
63 
 
 After subtask request for 2701 read (G8READ) : 
 Parmlist for subtask Subtask 
 
 (same as above) 
 
 G80PERAT 
 
 RDRQECB = A( INECB) 
 WTRQECB = 
 
 (subtask read request pending) 
 
 (same as above) 
 
 Record Request Block 1 
 
 +0 INECB = 
 
 +k A(INBUF) 
 
 +8 (reserved) 
 
 +10 Byte length of INBUF 
 
 INBUF (subtask supplied area) 
 
 After 2701 read complete 
 
 Parmlist for subtask 
 
 (same as above) 
 
 G80PERAT 
 
 RDRQECB = 
 WTRQECB = 
 
 (subtask read request cleared) 
 
 Subtask 
 
 (same as above) 
 
 Record Request Block 1 
 
 +0 INECB = return code 
 +k 
 
 (same as above) 
 +10 
 
 INBUF* 
 
 +0 console number (00N0) 
 
 +2 record type (XXXX) 
 
 +h record len (PDP-8 -words -l) 
 
 +6 
 
 Data 
 +n 
 
 * All input in the unpacked PDP-8 format 
 
 (e.g., 00XXXXXX00XXXXXX = one 12-bit PDP-8 word) 
 
 Figure l6. (Part 2 of 3) 
 
6k 
 
 After subtask request for 2T01 write (G8WRITE) 
 
 Parmlist for subtask 
 
 (same as above) 
 
 G80PERAT 
 
 RDRQECB = 
 WTRQECB = A(0UTECB) 
 
 (subtask write request pending) 
 
 Subtask 
 
 (same as above) 
 
 Record Request Block 2 
 
 +0 0UTECB = 
 
 +k A(0UTBUF) 
 
 +8 (reserved) 
 
 +10 Byte length of 0UTBUF 
 
 0UTBUF* 
 
 +0 console number (OOHO) 
 
 +2 record type (XXXX) 
 
 +k record len (PDP-8 words -l) 
 
 +6 
 
 Data 
 +n 
 
 * All output in unpacked PDP-8 format. 
 
 After 2701 write complete: 
 
 Parmlist for subtask 
 
 (same as above) 
 
 G80PERAT 
 
 RDRQECB = 
 WTRQECB = 
 
 (subtask write request cleared) 
 
 Subtask 
 
 (same as above) 
 
 Record Request Block 2 
 
 +0 0UTECB = return code 
 +k 
 
 (same as above) 
 +10 
 
 0UTBUF 
 
 (same as above) 
 
 Figure l6. (Part 3 of 3) 
 
65 
 
 START 
 
 SAVE INPUT 
 PARM STRING. 
 G8ENTRY CALL. 
 INITIALIZE 
 
 MAINTAIN 
 OUTSTANDING 
 READ REQUEST 
 TO SPACT 
 
 M MAINWAIT 
 
 AWAIT AN 
 EVENT 
 
 (Event occurred) 
 
 ® © ® 
 
 2701 2701 Other 
 Read Write 
 
 SET LOOP 
 TO 
 
 TEST 
 TERMINALS 
 
 Figure 17. SPACT Flow of Control (Part 1 of 7) 
 
WT0 
 
 WITH 
 
 MESSAGE 
 
 NO 
 
 NO 
 
 WT0 
 
 WITH MESSAGE 
 
 CLEANUP 
 
 ys\ 
 
 POST 
 
 TERMINAL 
 WITH RECORD 
 ADDRESS 
 
 *© 
 
 \PROGRAM / 
 RtSiNING/ 
 
 ADD RECORD 
 TO INPUT 
 QUEUE 
 
 *© 
 
 NO 
 
 CLEANUP 
 
 (FLUSH 
 
 RECORD) 
 
 *© 
 
 Figure IT- (Part 2 of 7) 
 
 © 
 
 66 
 
 ADD RECORD 
 TO OUTPUT 
 QUEUE 
 
 YES 
 
 START A PART 
 1 WRITE ON 
 FIRST RECORD 
 IN OUTPUT QUEJE 
 
67 
 
 MARK TERMINAI 
 HAVING A REAI 
 REQUEST 
 OUTSTANDING 
 
 ADD RECORD 
 TO OUTPUT 
 QUEUE 
 
 DELINK 
 RECORD 
 FROM 
 QUEUE 
 
 RA 
 
 ® 
 
 *© 
 
 
 
 _L_ 
 
 PURGE ANY RECORDS 
 IN INPUT OR OUTPUT 
 QUEUES FOR THIS 
 TERMINAL (ONLY 
 INPUT. RECORDS ARE 
 FREEMAINed) 
 
 DETACH TERMINAL 
 SUBPROGRAM AND 
 FETCH OS 
 COMPLETION CODE 
 
 (PREPARE A SINGL 
 REPLY FOR THE 
 TERMINAL (WTC0N) 
 
 Figure 17 . (Part 3 of 7) 
 
© 
 
 _L 
 
 LOAD 
 
 LOGGON 
 
 DIRECTORY 
 
 2 
 
 68 
 
 SET LOOP 
 TO TEST 
 TERMINALS 
 
 YES 
 
 SETUP ACCOUNT- 
 ING AND TERM- 
 INAL CONTROL 
 SET LOGGED IE 
 
 NO 
 
 SET 
 
 "ILLEGAL 
 COMMAND" MSG 
 
 SET 
 
 "READY" 
 
 MESSAGE 
 
 DELETE 
 
 THE 
 
 DIRECTORY 
 
 SEND MES- 
 SAGE TO THE: 
 TERMINAL 
 (WTC0N) 
 
 SET SAFETY 
 TIMER, POST 
 PROGRAM TO 
 HALT 
 
 TIMER INTERRUPT OR 
 PROGRAM HALTED, SO 
 CANCEL TIMER. DETACH 
 TASK. PURGE INPUT 
 AND OUTPUT QUEUES 
 FOR THIS TERMINAL. 
 
 Exit to 0S/36O 
 
 © 
 
 Figure IT. (Part 1* of 7) 
 
YES 
 
 WT0 WITH 
 MESSAGE. PASS 
 COMPLETION 
 CODE h OR 8 
 
 69 
 
 C3 
 
 WAS OUTPUT 
 BROKEN; LEAVE 
 RECORD ON 
 OUTPUT QUEUE 
 
 -Wmr j 
 
 PASS 
 
 COMPLETION 
 CODE (0K) 
 
 ■©— 
 
 PURGE RECORD 
 FROM QUEUE 
 
 FREEMAIN 
 THE REPLY 
 AREA 
 
 YES 
 
 START A PART 
 2 WRITE ON 
 FIRST RECORD 
 IN OUTPUT QUAUE 
 
 */mT\ 
 
 NO 
 
 POST TERMINAL 
 WITH CODE 
 IF STILL 
 RUNNING 
 
 — © 
 
 WT0 WITH 
 MESSAGE 
 PASS CODE h 
 
 (ABEND SINCE 
 "BROKEN" SHOULD 
 NEVER HAPPEN ON 
 PART 2 WRITE) 
 
 Figure IT. (Part 5 of 7) 
 
70 
 
 [NT Dl 
 ).F TERMINALS 
 ?R0GI 
 
 r>c 
 
 jT tj 
 
 TERMINALS 
 J>R0GRAM> 
 
 DETACH 
 TERMINALS 
 .PROGRAM. 
 
 10 
 
 Dart 
 'terminal 
 
 .PROGRAM 
 
 [no 
 
 jOGOUT 
 'THE TERMINi 
 
 CSSAC 
 ■DR ANO' 
 .TERMINAL 
 
 YES. 
 
 DUMP 
 
 OPEN DUMP 
 DATASET. SNAP 
 PROGRAM. CLOSE: 
 DATASET 
 
 HALT 
 
 YES 
 
 POST HALT 
 REQUEST TO 
 PROGRAM 
 
 ZAP 
 
 YES 
 
 PURGE RECORDS 
 IN QUEUES, 
 THEN DETACH 
 PROGRAM 
 
 Sname PARM k 
 
 YES 
 
 START A 
 PROGRAM FOR 
 THE TERMINAL 
 
 L0G0UT 
 
 YES 
 
 CLEANUP 
 TERMINAL CONI, 
 SET NOT 
 LOGGED ON 
 
 YES 
 
 Mnn-msg 
 
 /SEND "MSG" 
 TO SPECIFIED 
 TERMINAL nn 
 
 .(WTC0N) 
 
 'SMD 
 
 "COMPLETE" 
 MSG TO TERMI 
 .(WTC0N) 
 
 'SEND "HALT 
 REQUESTED" 
 MSG TO TERMI) i 
 (WTC0N) 
 
 fSEND "TASK 
 TERMINATED" 
 MSG TO TEBMH":.-vr, 
 (WTC0N) 
 
 'SEND "TASK 
 
 STARTED" 
 
 MSG TO TERMI. 
 .(WTC0N) 
 
 'SEND "GOOD- 
 BYE" MSG TO 
 TERMINAL 
 (WTC0N ) 
 
 Figure IT- (Part 6 of 7) 
 
71 
 
 SEND "ILLEGAL 
 J COMMAND" MSGL_ 
 \ TO TERMINAL P" 
 \(WTC0N) / 
 
 DSPACT 
 
 OPEN DUMP 
 YES J DATASET.SNAP 
 SPACT. CLOSE 
 DATASET 
 
 AL 
 
 OPEN ACCNT 
 DATASET, SEND 
 INITIAL MSG 
 
 NO 
 
 U! 
 
 SEND FINAL 
 MSG, CLOSE 
 DATASET 
 
 fSEND "SPACT 
 DUMP COMPLE 1 
 TO TERMINAL 
 
 ,(¥TC0N) 
 
 SEND "ACCNT 
 STARTED" MSG] 
 TO TERMINAL 
 (WTC0N) 
 
 'SEND "ACCN r 
 
 STOPPED" 
 
 MSG TO 
 
 TERMINAL 
 t (WTC0N) 
 
 \ 
 
 TED" 
 
 f WTC0N J — » 
 
 GETMAIN A REPLY 
 BUFFER; IF NO 
 SPACE ,WT0. MOVE 
 IN MSG AND 
 TRANSLATE FOR 
 PDP-8 
 
 (Return) 
 
 Figure 17 . (Part 7 of 7) 
 
72 
 
 SPACT 
 
 Subtask 
 
 Parmlist for subtask 
 
 +0 
 
 +k 
 
 +8 
 
 U2 
 
 u6 
 
 ( available ) 
 A(user work area) 
 A(XFILEOOl) 
 A(log user) 
 A(parm string) 
 
 (user must: 
 
 1. save parmlist address 
 
 2. set XFTLE001 into V-con 
 
 3. call S8ENTRY 
 before anything else) 
 
 Parmstring 
 
 2k characters : 
 parm field 
 (from START command) 
 
 Loguser 
 
 8 characters : 
 
 user logon name 
 
 Trmcntrl 
 
 User Work Area (ik words) 
 
 +0 
 
 +k 
 
 A(27O10PRQ) 
 
 +8 
 
 
 
 +12 
 
 
 
 +1$ 
 
 (+8,+12,+0) 
 
 +28 
 
 (+8.+0) 
 
 +36 
 
 (+12 s +0) 
 
 +kk 
 
 
 
 +kQ 
 
 
 
 +52 
 
 
 
 SPACT ECB for 
 HALT request 
 2701 request link 
 2701 Read done ECB 
 2701 Write done ECB 
 S8WAIT ECBLIST 
 S8READ ECBLIST 
 S8WRITE ECBLIST 
 A(0THER) 
 
 Register 2 save wrd 
 Addressability 
 save word 
 
 +0 27O10PRQ: READ request ECB 
 
 +k WRITE request ECB 
 
 +8 A(User work area) +8 0Pdone ECB's 
 
 Figure 18. SPACT/User-Program Linkage After S8ENTRY 
 
73 
 
 Trmcntrl 
 
 +0 Read request E£B: P0STed by subtask when S8KEAD issued. 
 +k Write request ECB: P0STed by subtask when S8WRITE issued. 
 +8 A( Subtask Op-completed ECB's): set by S8ENTRY. ECB's P0STed by 
 
 SPACT as appropriate. 
 +12 Subtask TCB: Used for DETACH and DUMP; if zero, no subtask running 
 
 (Saved after ATTACH) 
 +16 Subtask End ECB: P0STed by 0S when subtask terminates (this ECB 
 
 specified during ATTACH). 
 +20 A(ACCNT): A (Ac counting Area) for this terminal. 
 
 Accnt 
 
 +0 User logon string 
 
 +8 Status -word one, , _ , 
 .,„ „. . , , } record counts, funds, etc. 
 +12 Status -word two 
 
 +16 Control byte (X'80 1 = logged on) 
 +17 Data logged on 
 +20 Time logged on 
 
 Figure 19. SPACT Terminal Control Area Detail 
 
■7* 
 
 LIST OF REFERENCES 
 
 [l] Michel ,■ M. J. GRASS: System Overview , Department of Computer 
 Science Report No. U65 , University of Illinois, Urbana, 
 Illinois 618OI, July 1971. 
 
 [2] Gear, C. W. An Interactive Graphic Modeling System , Department 
 of Computer Science Report No. 3l8, University of Illinois, 
 Urbana, Illinois 6l801, April 1969. 
 
 [3] Gear, C. W. Generalized Simulation and Modeling System , Department of 
 Computer Science File No. 785 » University of Illinois, 
 Urbana, Illinois 6l801, December 1968. 
 
 [k] Michel, M. J. GRAPHICAL REMOTE-ACCESS SIMULATION SYSTEM (GRASS) 
 The Communication and Monitor Components (GASP/GLASP) , 
 Department of Computer Science Report No. 3^6, University 
 of Illinois, Urbana, Illinois 618OI, August 1969. 
 
 [5] Gear, C. ¥. , et.al. The Simulation and Modeling System — A 
 
 Snapshot View , Department of Computer Science File No. 82U, 
 University of Illinois, Urbana, Illinois 6l801, February 1970. 
 
 [6] Levin, H. Local Information Retrieval for the Simulation and 
 
 Modeling System , Department of Computer Science Report No. U09, 
 University of Illinois, Urbana, Illinois 618OI, August 1970. 
 
 [7] Michel, M. J. and Koch, J. GRASS: Terminal User's Guide, Department 
 of Computer Science Report No. k6"J , University of Illinois, 
 Urbana, Illinois 6l801, August 1971. 
 
 [8] Haskin, R. , Nickolls, J., and Michel, M. J. GRASS : Remote 
 
 Facilities Guide , Department of Computer Science Report No. hGG^ 
 University of Illinois, Urbana, Illinois 6l801, July 1971. 
 
 [9] Michel, M. J. and Haskin, R. GRASS: Extended Remote Facilities 
 
 Guide , Department of Computer Science File No. 867, University 
 of Illinois, Urbana, Illinois 6l801, August 1971. 
 
 [10] Haskin, R. GRAPHICS 8: System Maintenance (Software), Department of 
 Computer Science File No. 865, University of Illinois, Urbana, 
 Illinois 618OI, July 1971- 
 
 [ll] Nickolls, J. GRAPHICS 8: System Maintenance (Hardware), Department 
 of Computer Science File No. 866, University of Illinois, 
 Urbana, Illinois 6l801, August 1971. 
 
 [12] Carter, C. E. , et.al. GRAPHICS 8: Graphics Hardware— IU69 Gear, 
 Department of Computer Science Report No. 371 , University of 
 Illinois, Urbana, Illinois 6l801, December 1969. 
 
75 
 
 [13] Carter, C. E. , et.al. DEC PDP-8 Interface to IBM 2701 PDA , 
 
 Department of Computer Science Report No. 372, University of 
 Illinois, Urbana, Illinois 6l801, March 1970. 
 
 [Ik] Lopeman, H. E. GRAPHICS 8: PDP-8 Interface Hardware— 1U69 Gear , 
 Department of Computer Science File No. 828, University of 
 Illinois, Urbana, Illinois 6l801, March 1970. ' 
 
 [15] Levin, H. and Lopeman, H. PDP-8 /I to PDP-8 Interface , Department 
 of Computer Science File No. 8U3, University of Illinois, 
 Urbana, Illinois 6l801, June 1970. 
 
 [l6] Hyde, C. PDP-8 Disk Interface , Department of Computer Science 
 
 File No. 86l, University of Illinois, Urbana, Illinois 6l801, 
 November 1970. 
 
 [17] Programmed Buffered Display 338 , Digital Equipment Corporation, 
 DEC-08-G61C-D, 1967. 
 
 [l8] Disk Monitor System Programmers Reference Manual , Digital Equipment 
 Corporation, DEC-D8-SDAB-D, 1968. 
 
 [19] System 360 , International Business Machines Corporation, 1966- 
 1971 series. 
 
 [20] COMPUTER User's Manual , Series U00/15 CRT Display System, Computek 
 Inc., Bulletin iiOOM, July 1969. 
 
 [21] Quarterly Progress Reports , Department of Computer Science Section 3.3 : 
 University of Illinois, Urbana, Illinois 6l801, March 1970- 
 June 1971. 
 
16 
 
 APPENDIX A 
 Buffering Control Program (ACID) 
 
77 
 
 A program has "been developed for the PDP-8/I to maintain the 
 storage tube terminals that are attached to it. Basically^ display files 
 are read out of the PDP-8, buffered in the PDP-8 /I, and then fed to the 
 terminal. In the other direction, joystick (X,Y) and keyboard text-lines 
 input by a user at a terminal are sent to the PDP-8. A chained buffering 
 scheme with storage allocation/deallocation is used, so that all attached 
 terminals can be sent display data simultaneously. In addition, the line 
 that a user types is refresh displayed in write-through (non-storing) 
 mode, enabling typed corrections to appear immediately and in place. 
 Moreover, since the line is not stored in this "line buffer" area, the 
 display need not be erased and regenerated for the user to type his next 
 line in the buffer. 
 
 Communication between the two CPU's is accomplished with two 
 software flag words in the PDP-8, one for Input (terminal to_ PDP-8), and 
 one for Output ( PDP-8 to_ terminal) . 
 
 (TFLAG8) Input: 1. zero means no input yet. 
 
 2. set to nonzero by PDP-8/I means input ready 
 to be processed by PDP-8. 
 
 3. set to zero by PDP-8 means processing of input 
 now completed; ready for more; go to state l) . 
 
 (DFLAG8) Output :1. zero means no output yet. 
 
 2. set to nonzero by PDP-8 means output ready to 
 be processed by PDP-8 /I. 
 
 3. set to zero by PDP-8/I means processing of output 
 now completed; ready for more; go to state l). 
 
 TFLAG8 is located at 2000 in bank 3 (GLBANK), while DFLAG8 is at 50 in 
 bank 3. TFLAG8 is the first word of a kO word buffer; DFLAG8 is the first 
 of three words. 
 
 For the following discussions, bits in a word are numbered most 
 significant (left) to least significant (right), to 11. 
 
78 
 
 Flag Designations 
 
 A. TFLAG8: bit (input ready when on) 
 
 bit 1-8 (interrupt character) 
 
 = carriage return (text line) 
 
 1-7 = joystick hit (X,Y) 
 
 8-255 = function option (currently unspecified) 
 
 bit 9-H (console number) 
 
 Rest of Buffer: 
 
 keyboard line Joystick hit 
 
 word 2 number of characters Y (10 bits) 
 
 (max currently allowed = 72) 
 
 word 3 (unused) X (10 bits) 
 
 word U- UO 
 
 six bit packed ascii (unused) 
 
 characters with last 
 set to a "blank" if 
 count (word 2) is odd 
 
 B. DFLA.G8: bit (output ready when on) 
 
 (function) 
 
 = enable console 
 
 = input text line to console's 
 text -line display buffer 
 
 = process display file for 
 console (e.g. , display) 
 
 bit 
 
 
 
 
 bit 
 
 1- 
 
 1 
 
 2 
 
 3 
 
 -5 
 
 
 k- 
 
 -31 
 
 (unspecified) 
 
 Display File 
 
 The display file input by the PDP-8/I is in the DEC 338 file 
 format [l7]» except for the use of the "spare" mode 7- This mode is used 
 to provide special display instructions to the PDP-8/I. Each bit (of bits 
 3-11) represents an option and the bits are "executed" right to left, 
 so "microprogramming" of options is possible. (option is "on" if bit is a 
 "1"). 
 
19 
 
 bit 11 - disable output of terminal to PDP-8 
 bit 10 - erase screen 
 bit 9 - add frame lines to display- 
 bit 8 - enable output of terminal to PDP-8 
 bit 7 - end of display file segment (e.g., another 
 
 file -will be output soon for this terminal; do 
 
 not release buffers) 
 bit 6 - (same as bit 7 currently) 
 bit 3, k, 5 currently unspecified 
 
 Terminal Character Set 
 
 For the following, "f represents a control character and - 
 means the indicated character is ignored. All numbers are octal. 
 
 typed on 
 
 keyboard 
 
 « 
 
 (2) 
 
 -E 
 
 (5) 
 
 W 
 
 (6) 
 
 «AC 
 
 (10) 
 
 fEAB 
 
 (11) 
 
 « 
 
 (13) 
 
 CR 
 
 (15) 
 
 Fl 
 
 (21) 
 
 F2 
 
 (22) 
 
 F3 
 
 (23) 
 
 Fh 
 
 (2k) 
 
 F5 
 
 (3k) 
 
 F6 
 
 (35) 
 
 echoed in line buffer as 
 
 move text -line cursor to 
 (Mtlct) 1st line character 
 
 Mtlct last line character 
 
 Mtlct next right character 
 
 Mtlct next left character 
 
 Mtlct 6th right character 
 
 Kill character line 
 
 Mtlct 1st line character, reset 
 
 sent to PDP-8 as 
 
 Not sent 
 Not sent 
 Not sent 
 Not sent 
 Not sent 
 Not sent 
 Send line 
 Joystick hit 
 Joystick hit 
 Joystick hit 
 Joystick hit 
 Joystick hit 
 Joystick hit 
 
 ( continued) 
 
80 
 
 space 
 
 (4p) 
 
 t 
 
 (41) 
 
 tt 
 
 (42) 
 
 # 
 
 (43) 
 
 $ 
 
 (44) 
 
 % 
 
 (45) 
 
 & 
 
 (46) 
 
 i 
 
 (47) 
 
 ( 
 
 (50) 
 
 ) 
 
 (51) 
 
 * 
 
 (52) 
 
 + 
 
 (53) 
 
 » 
 
 (54) 
 
 - 
 
 (55) 
 
 • 
 
 (56) 
 
 / 
 
 (57) 
 
 
 
 (60) 
 
 • • • 
 
 9 
 
 (71) 
 
 • 
 
 (72) 
 
 5 
 
 (73) 
 
 < 
 
 (.74) 
 
 = 
 
 (75) 
 
 > 
 
 (76) 
 
 1 
 
 (77) 
 
 A 
 
 (101) 
 
 space 40 
 
 ! 41 
 
 42 
 
 * 43 
 $ 44 
 
 * 45 
 & 46 
 
 47 
 ( 50 
 
 ) 51 
 
 * 52 
 + 53 
 
 54 
 55 
 56 
 
 / 57 
 
 o 6o 
 
 • • • • • • 
 
 9 71 
 
 : 72 
 
 ; 73 
 
 < 74 
 
 75 
 
 76 
 
 ? 77 
 
 A 01 
 
 (continued) 
 
81 
 
 z (132) z 32 
 
 [ (133) ( 50 
 
 ^ (134) -, 36 
 
 1 (135) ) 51 
 
 (137) 35 but NOT sent; 
 
 can only come 
 FEOM the PDP-8 
 
 a (lUl) a 01 
 
 z (172) z 32 
 
 { (173) ( 50 
 
 I (17^) I 34 
 
 } (175) ) 51 
 
 -1 (176) -! 36 
 
 Note that 0, 33, and 37 are never sent to the PDP-8 since these mean 
 carriage -re turn, line-feed, and escape, respectively, when they appear 
 in a display file. In addition, 35 (underscore) is never sent to the 
 PDP-8. All possible keyboard characters not mentioned above explicitly 
 are ignored by ACID. 
 
82 
 
 APPENDIX B 
 System Generation and IPL 
 
83 
 
 1. Local System Generation 
 
 Use a PDP-8 Disk Monitor System [18] to assemble and save the 
 programs as shown "below. PEND contains just a $ to mark the end of 
 PAID input. PSEQ contains a large number of equates; this facilitates 
 symbolic references to all control areas and "between separately 
 assembled programs. 
 
 GLASP: GMN2,PEND 
 
 .SAVE GMN2! 30000-35777 ;30203 
 
 IR: PSEQ, DISK, DIRC,SVIR,PSIR,PEND 
 
 .SAVE GLJR! 26000-27777 ;26l 1+3 (moved to GLBANK during system IPL) 
 .SAVE PSIR! 3^000-35777; 30150 (segment 37) 
 
 GUTS : UTEQ,GTS1 ,DSM1 ,DSM2 ,DSM3 ,DSMU ,DSM5 ,IRRE ,GT32 ,2701 ,DPU1 ,PRIN, 
 DPU2,DSM6,PEMD 
 
 .SAVE GUTS! 10000-17777 ;100U3 
 
 Segments : PSEQ ,name , PEND 
 
 .SAVE name 13^000-35777; 30150 (segments 0-36) 
 
 ACID : ACID 
 
 .SAVE ACID: 0-3777 ;200 
 
 A system load tape is then built from these modules using WL.0D as 
 described below. GL0AD and GEXIT for loading the system, and the library, 
 are described in [7]. 
 
 WL0D 
 
 a. Mount the tape to be modified on Unit k, write enabled. 
 
 b. Start execution of WL0D from the DMS. 
 
 c. Type the name of the contiguously saved program to be 
 written on the tape . 
 
 d. Type the octal number associating the program with an 
 area on the tape. See following chart. 
 
 e. Go to C) and repeat until all desired programs written; 
 then type control C to exit to DMS. Unload tape. 
 
Qk 
 
 Data 
 
 WL0D No. Blocks on Load Tape Blocks on Disk* 
 
 DECtape System** 
 
 - 
 
 0-3TT 
 
 — 
 
 Program Segments 
 
 0-37 + 
 
 UOO-TTT 
 
 llUO-1537 
 
 GLASP 
 
 1+0 
 
 1000-1021* 
 
 - 
 
 GLIR 
 
 1*1 
 
 1025-1031* 
 
 - 
 
 GUTS 
 
 1*2 
 
 1035 -107U 
 
 - 
 
 ACID 
 
 1*3 
 
 1075-Hll* 
 
 '■ - 
 
 Data 
 
 Blocks 
 
 on Library Tape 
 
 Blocks on Disk* 
 
 Core copy of free 
 block list 
 ( 6h words ) 
 
 
 
 
 —(from GLIR) 
 
 Control Pointers 
 (6 -words) 
 
 
 
 
 — (from GLIR) 
 
 Free "block list 
 
 
 1-20 
 
 151*0-1557 
 
 Directory blocks 
 
 
 21-120 
 
 1560-1657 
 
 Library blocks 
 
 
 121-2637 
 
 1660-U377 
 
 One other utility is available for tape modification. PEEPER 
 allows octal alteration (in a manner similar to XOD or HELP) of arbitrary 
 tape blocks. 
 
 PEEPER 
 
 a. 
 
 b. 
 
 Start execution of PEEPER form the DECtape system (e.g. , 
 on a GRASS load tape). 
 In response to "PGM#:", respond with 
 
 1. a WL0D number (0-1*3) if a GRASS program modification 
 is desired, or 
 
 * Consult [6]. 
 
 + 
 
 Corresponds to program segment numbers . 
 
 ** Includes: X0D, XDUP, XFILE, etc., as well as GL0AD, GEXIT, PEEPER 
 
85 
 
 2. a DECtape -unit number (D0-D7) if an arbitrary tape 
 "block is desired. In this latter case, an octal 
 block number also must be specified when "BLK#:" 
 is requested. 
 
 c. The program (l) or tape block (2) will be read into core. 
 
 d. Now proceed as with X0D to examine and change locations. 
 Obviously, locations outside the range of the requested 
 program or tape block (0-177) cannot be modified. 
 
 e. Typing control-P or control-C will write out any 
 changes made ; the former will then cause PEEPER to 
 restart at step b), while the latter causes return to 
 the monitor. 
 
 2. Remote System Generation 
 
 The remote system makes use of three OS/360 data sets. A 
 macro library, used only during the assembly of system or user programs, 
 contains the following: 
 
 P8 -macros 
 
 P8I0 
 
 P80PRS 
 
 P80PRSX 
 
 P8RCCW 
 
 P8RETRY 
 
 P8WAIT 
 
 P8WCCW 
 
 G8-macros 
 
 G8EWTRY 
 G8READ 
 G8WAIT 
 G8WRITE 
 
 S8-macros 
 
 XFile macros 
 
 S8DATA 
 
 XAPPEND 
 
 S8ENTRY 
 
 XCL0SE 
 
 S8READ 
 
 XDELETE 
 
 S8SETUP 
 
 XDESTR0Y 
 
 S8WAIT 
 
 XINIT 
 
 S8WRITE 
 
 XLINK 
 
 
 XLIST 
 
 
 X0PEN 
 
 Utility macros 
 
 XREAD 
 
 PAIS 
 
 XREADDIR 
 
 PBR 
 
 XREADIRS 
 
 PLR 
 
 XREAOT 
 
 PI£T 
 
 XREADS 
 
 PSTR 
 
 XREWIND 
 
 
 XTERM 
 
 
 XWRITE 
 
LSD 
 
 
 ITEM ^ 
 
 
 GL0BAL1 1 
 
 . Simulation and 
 
 GL0BAL2 1 
 
 Modeling Package 
 
 ELIM 1 
 
 
 C0MP1 | 
 
 
 SPARSE 
 
 
 86 
 
 Two other data sets are active at execution. The first is the 
 library data set used by XFILE. This contains the remote directory, 
 space allocation bit map, and library blocks. The second is a load 
 module library containing the system programs and all user programs 
 that run under it. Modules included are: 
 
 System User 
 
 G80PEFAT 
 
 SPACT 
 
 GIDS 
 
 XFILE 
 
 C0MMUNE 
 
 BATCH 
 
 P0T 
 
 Some other modules in this data set are used during linkediting: 
 
 CALLER 
 
 S8SETUP 
 
 MY#FI0CS 
 
 Note that all software runs in HIARCHY=1 and is system independent for 
 release 18 and above of 0S/36O. 
 
 Sample JCB 
 
 1. Create top monitor level 
 
 // EXEC ASM,MACFILE='MACR0S' 
 
 (G80PERAT Source) 
 // EXEC LKED,LIBFILE= , L0ADM0DS' ,PARM='LIST, X 
 // XREF^T^IAR 1 
 
 HIARCHY 1,G80PERAT 
 
 NAME G80PERAT(R) 
 
87 
 
 2. Create a typical lower level or user module 
 
 // EXEC ASM... 
 
 (source) 
 // EXEC LKED,PARM=' LIST, XREF, LET, RENT' 
 
 NAME XX(R) 
 
 (The above module is loaded by a higher level module iito the proper 
 storage; hence, HIARCHY parameters need not be used). 
 
 3. Create a typical user module containing CALLER and special 
 FORTRAN I/O 
 
 // EXEC ASM or F0RT. . . 
 (source) 
 
 // EXEC LKED,PARM=... 
 ENTRY CALLER 
 INCLUDE SYSLIB(MY#FI0CS) 
 NAME XX(R) 
 
 (Consult [8]). 
 
 h. Run the monitor system 
 
 //J0BLIB DD DSN=L0ADM0DS,DISP=SHR 
 
 //GRASS EXEC PGM=G80PERAT, 
 
 // REGI0N=(12K,25OK), 
 
 // PARM='S SPACT' 
 
 //SYSUDUMP DD SYS0UT=A 
 
 //SYSPRINT DD SYS0UT=A 
 
 //PDP8DD DD UNIT=021' 
 
 //DISK DD DSN=GRAPHLIB,DISP=0LD 
 
 //FT05F001 DD DUMMY 
 
 //FT06F001 DD SYS0UT=A 
 
 //FT0TF001 DD DUMMY 
 
88 
 
 5 . Run the P0T plotting package 
 
 //J0BLIB DD DSN=L0ADM0D3 ,DISP=SHR 
 
 //P0T EXEC CALC0MP, 
 
 // REGI0N=(1T5K,3OK), 
 
 // PARM='EP=P0T,PL=3O 9 TIME=6.OO , 
 
 / /G0 . SYSLM0D DD DSN=L0ADM0DS , DISP=SHR 
 
 //G0.SYSPRINT DD SYS0UT=A 
 
 //G0.SYSUDUMP DD SYS0UT=A 
 
 //G0.DISK DD DSN=GRAPHLIB ,DISP=0LD 
 
 //G0.FTO5FOO1 DD DUMMY 
 
 //G0.SYSIN DD * 
 
 ( input cards ) 
 
 6. Run the BATCH test module 
 (Consult [9]). 
 
 7. Save the remote library on tape 
 
 //SAVE EXEC PGM=IEBGENER 
 
 //SYSPRINT DD SYS0UT=A 
 
 //3YSUT1 DD DSN=GRAPHLIB,DISP=SHR, 
 
 // DCB=(BLKSIZE=T93,LRECL=T93,RECFM=F) 
 
 //SYSUT2 DD DSN=SAV0NTAP s UNIT=TAPE,LABEL=i, 
 
 // DISP=dTEW,KEEP),V0L=SER=tapeid s 
 
 // DCB=(BLKSIZE=T93,LRECL=T93,RECFM=F) 
 
 8. Reload the remote library from tape 
 
 //REL0AD EXEC PGM=IEBGENER 
 
 //SYSPRINT DD SYS0UT=A 
 
 / /SYSUT1 DD DSN=SAV0NTAP , UNIT=TAPE ,LABEL=i , 
 
 // DISP=0LD s V0L=SER=tapeid, 
 
 // DCB=(BLKSIZE=T93,LRECL=793,RECFM=F) 
 
 //SYSUT2 DD DSN=GRAPHLIB,DISP=0LD, 
 
 // DCB=(BLKSIZE=793,LRECL=793,RECFM=F) 
 
89 
 
 APPENDIX C 
 GLASP Routines — Detail 
 
90 
 
 INTHND ' 
 
 Entered via location 2, "bank 0, with standard DEC interrupt 
 procedure. First tests disk done and immediately goes to IR entry point 
 BSRTRN (6000) if found. Next tests DPU software flags and goes to 
 DPUINR if (l) DPU input not currently being processed (DPUINP=0) and 
 (2) new DPU input is in "buffer (DPUINF N0T 0). Clock flag is tested 
 next; if on, all timer queue elements are incremented with INTHN2 
 (CLKQR). If INTHN2 finds any terminals to be interrupted, CLKQR3 is 
 used to set 2010 pending for each such terminal. Note that the interrupt 
 handler is N0T exited during this processing (as opposed to calls to 
 BSRTRN and DPUINR) . INTHN2 returns to the mainstream of INTHND processing 
 at INTHN3, but after ELAPC is called to update the time display area for 
 the system message line. INTHN3 is the final phase of interrupt 
 processing; two tables are used to test all remaining device flags. The 
 first table contains the I0T, while the second contains the appropriate 
 address in bank 1 (UTBANK) for device handling if the associated I0T 
 "skips" (flag on). Note that undesirable device flags can be ignored 
 simply by using a "clear" I0T instead of a "skip" I0T in the first table. 
 The last entry in the first table is a jump to the WAIT routine; hence, 
 if only the clock or an undesired device flag caused the interrupt, GLASP 
 returns to the wait state. 
 
 FR2701 
 
 Entered from INTHND if "2701 ready to send to PDP-8" was found. 
 Uses preset data to begin the read operation, then goes to WAIT. When the 
 operation is complete, FD2701 is entered from INTHND. This routine tests 
 for and begins a retry if necessary (data error, etc.). If the record was 
 correct, the routine goes to FN2701 to check if it was the first or second 
 part of a record. The I2701P flag is set accordingly. If the record was 
 a second part, FE2701 is entered to reset the system for another first part; 
 GLASP is then called via 0PD0NE (e.g., 2701 completion service is finished). 
 If the record is a first part, I0T information is preset for use by FR2701 
 in case a second part is expected. Then the record type is tested for a 
 monitor-monitor internal command. If such is found, the appropriate 
 
91 
 
 internal routine is called; if not found, the record is for a terminal, 
 so FC2T01 is called. This routine calls F2701W in GLBANK. F2T01W tests 
 the status of the terminal with T0LAC (see "below). If the terminal is 
 offline, FC2701 is told to flush the record internally and return to WAIT. 
 If the terminal is online but inactive, FC2701 flushes the record, but 
 causes the subsequent execution of segment (CALLER) for the terminal 
 (via SYSCTL) . If the terminal is active, 2001 is set pending for the 
 terminal and lockout checking is performed. Finally, F2701W goes to WAIT. 
 
 The only internal monitor-monitor command currently in use is 
 indicated by type=7770. This means the remote monitor is up; an "H" is 
 printed on the operator's TTY printer and an internal flag Is cleared 
 (see 0PKB). 
 
 0PKB 
 
 Entered from INTEND if a character on operator's TTY keyboard 
 is sensed. All commands are currently one character long and execute 
 immediately. The input character plus a carriage-return, line feed sequence 
 are sent to the TTY printer. If the command is unrecognized, a "?" is 
 printed. Current commands are : 
 
 ! = ignore segment 2701 output operations (e.g. , an internal 
 flag (Q2701P) is set so the whole operation proceeds as 
 normal except that no transmission takes place). Used 
 when the remote monitor is not up. 
 
 " = the internal flag is cleared so 2701 output operations will 
 indeed transmit data. Used when GLASP is restarted and 
 remote monitor is already up. 
 
 Operator device input to a terminal is not currently supported. 
 
 DPUINR 
 
 Entered from INTEND if DPU input ready to be processed. Calls 
 PICSEG to test input data type; for keyboard lines PICSEG tests the 
 terminal's filter word (+36 console vector), while for joystick hits 
 PICSEG first determines the screen segment hit and then tests the appropriate 
 
92 
 
 filter word. In either case., an accept/not-accept code is returned to 
 DPUINR. T0LAC is then called to test the terminal's status. If the 
 terminal is offline, the input will be flushed internally; control is 
 returned to WAIT. If the terminal is online but inactive, the input 
 is flushed but segment (CALLER) is started on the terminal via a call to 
 SYSCTL. If the terminal is active and the code from PICSEG was "accept," 
 20()1+ is set pending; control returns to WAIT. 
 
 CLKQR 
 
 Entered during INTEND processing of clock interrupts to 
 increment timer queue elements. If a timed interval reaches zero for 
 an active terminal that has "accept timer input" set, CLKQR3 is used to 
 set 2010 pending for that terminal. After all terminals are checked, 
 control returns to INTHN3. 
 
 R0UTX 
 
 Entered via JMS from segments or system to begin a service for 
 the current terminal. The desired service group is indicated by the 
 number in the ACC at entry. Necessary parameters for the service are 
 assumed already in SVPRM1-8 in GLBANK; these are saved in the console 
 vector. The caller's restart address and bank are also saved in the 
 console vector. Availability of the desired service is then tested via 
 R0UTXR. If the service is not free, R0UTX stores the service group 
 number in the console vector (thus indicating that a request is pending) 
 and goes to WAIT. If the service is free, R0UTXR copies the parameters to 
 SVPRM1-8 in UTBANK, sets the service request word in the console vector 
 to -1 (terminal busy, service being processed), sets the service busy (with 
 the address of the caller's console vector), and jumps to the R0UTX entry 
 point of the routine in UTBANK. The console vector address is passed to 
 the UTBANK routine in the ACC. 
 
93 
 
 TSTQUE 
 
 Entered from WAIT to test all "pending" conditions (e.g. device 
 input and service requests). Each console vector is tested; if the busy- 
 flag is on (request word = -l) , no action is taken. If the flag is > 
 (e.g., a service request is pending), R0UTXR is called to try to start the 
 request. A successful start by R0UTXR obviously terminates TSTQUE 
 processing. Otherwise, testing the next terminal follows the R0UTXR call. 
 If the flag is (e.g., terminal free (not busy)), the device input 
 pending bits are tested. If a bit is found on, the corresponding device 
 routine address is checked; zero means ignore, nonzero means accept. 
 TSTQUE has a list of "ignore" entry point addresses, one for each device. 
 The appropriate routine is called, and the input is internally flushed. 
 In the case of "accept," the nonzero flag is the entry address; the 
 current terminal segment is started via XCTLS (TSTQUE processing is 
 terminated). If no action is needed or none can be initiated by TSTQUE, 
 control returns to WAIT. 
 
 WAIT 
 
 Entered whenever processing must be suspended pending completion 
 or occurrence of an operation or event. A group of priority flags are 
 tested first; this enables certain critical internal processes to ensure 
 serial use of particular resources. If a priority flag is set (not zero), 
 the appropriate resource busy flag is tested. A zero (not busy) resource 
 flag causes control to be passed to the routine address specified by the 
 priority flag. The called routine is responsible for clearing and 
 setting the priority flag, as necessary. WAIT processing is at an end. 
 If no action is taken during priority flag testing, TSTQUE is then called 
 to schedule pending requests or input if possible. If TSTQUE returns to 
 WAIT, the interrupt is turned on (I0N) and the program loops until an 
 interrupt occurs (e.g., a device or the clock). This is the one and only 
 idle state for the entire local system. 
 
9b 
 
 0PD0NE 
 
 Entered from a completing service routine or from XCTL (see 
 below). As soon as possible, the segment for the indicated terminal 
 is restarted at the atdress (and bank) stored in the console vector. The 
 ACC tells 0PD0NE which service is completing (0 for XCTL) ; the terminal 
 to be restarted is indicated by the contents of the service's busy flag. 
 This word is used to reset CURC0N (current console), and the service 
 flag is set to zero (free). TSTPCR is then called to check if the segment 
 needed for this terminal is the one currently in core. If it is, the 
 SVPRM save area in the console vector is copied into SVPRM1-8 in GLBANK; then 
 the return information is extracted. Control is passed to the restart 
 location; 0PD0NE processing terminates. If the required segment is not 
 in core, the console vector address for this terminal is placed in a stack, 
 and a priority call to WAIT is made (GETPl). 0PD0NE processing terminates 
 temporarily. 
 
 As soon as the disk busy flag is clear, the priority flag 
 scan in WAIT will transfer control back to 0PD0NE. The last entry on 
 the console address stack is extracted, and, if the stack is now empty, 
 the priority request is cleared. 0PD0NE now calls FETPA to load the 
 segment needed by the indicated terminal from the disk. When the segment 
 is in core, 0PD0NE processing proceeds as above. Note that the disk busy 
 flag is made "busy" when EETPA is called; hence, WAIT will never make a 
 priority return to 0PD0NE while a segment is being fetched. 
 
 RELESE 
 
 Entered from a segment when current processing of input has been 
 completed. The terminal (e.g., segment) is now ready (and waiting) for 
 more input. RELESE sets the request word to zero (free), and then performs 
 a safety "unfix" via MNIMF for all standard, nonstandard, and work blocks 
 associated with the terminal. Control is then passed to WAIT. 
 
95 
 
 XCTL 
 
 Entered to begin execution of a different segment for the 
 current console. The call is: 
 
 TAD X 
 
 JMS I XXCTL 
 
 ADDR 
 
 ID 
 
 ADDR gives the new entry point; ID (0-37) gives, the new segment number. 
 If X < 0, the SVPRM1-8 area in GLBANK is saved in the console vector 
 before the operation commences; otherwise, the GLBAHK copy is lost 
 (before execution of the new segment begins, the console vector SVPRM1-8 
 area is copied to the GLBANK area). XCTL simply resets the locations 
 used by R0UTX and calls 0PD0NE with ACC =0. If ID = -1, the segment is 
 not changed; the current segment is entered at the new location. One 
 routine mentioned previously, SYSCTL, is merely a call to XCTL that 
 specifies CALLER as the segment and ^000 as the entry address. 
 
 GLMSGA 
 
 Entered to take an indicative text-line from the 2701 and display 
 it on the appropriate terminal. The call Is a JMP to GLMSGA with SVPRM3 = Y 
 and SVPRM1+ = X giving the screen position of the line. GLMSGA returns to 
 RELESE when finished, not to the segment. The appropriate call; is made to 
 R0UTX (service h) to complete 2701 processing. If the input is not of 
 type = 0, the data is flushed, and a message is sent to the terminal. If 
 the input is type = 0, the input appears on the terminal. PCW0RK is used 
 to buffer the input; the 2701 is cleared; and then the DPU is enqueued. 
 When DPU processing is complete, the word at PCW0RK is set = 0, and RELESE 
 is called. Since some segments (for example the text editor in GUTl) use 
 PCW0RK for user area message lines , setting PCW0RK = will prevent a 
 DPU error when such a segment is re-entered following GLMSGA processing 
 (c.f. the text editor and GREGPl). Note that a segment can enter this 
 routine at a point GLMSG for displaying a line already in PCW0RK. 
 
96 
 
 DPUDIN 
 
 Entered to transfer control to the proper routine after DPU 
 input marked pending. Segments desiring to accept DPU input should 
 always use DPUDIN as the device entry address (+22 in the console vector) . 
 TSTQUE will transfer control to DPUDIN as appropriate; DPUDIN uses 
 information saved by PICSEG to transfer control to the proper screen 
 segment or keyboard line routine. DPUDIN always moves words at DPUINF+1 
 and DPUINF+2 into +112 and +113 of the PCB. For joystick DPU input, 
 these are the Y and X hit coordinates. 
 
 GREGEN 
 
 Entered to automatically redisplay the standard blocks of the 
 current picture. The routine assumes that an erase, the frame, and any 
 desired frame text have already been sent by the segment. The line, 
 text, terminal, and then instance blocks are added to the screen via 
 calls to R0UTX, the DPU, and GUT2 (RGINST). Control is returned to 
 the segment. 
 
 GREGP1 
 
 Entered to add a preformed display file (such as a text 
 message or the mnemonic "box" in GNDRW) to display file being constructed 
 in the DPU output buffer. The call is: 
 
 TAD X 
 JMS GREGP1 
 FILEH 
 FILEH , LEN 
 
 (Rest of file) 
 
 The TAD X is used ONLY if the file ( FILEH) is not in GLBANK; in this case, 
 
 X should = otherbank - GLBANK. The file is considered as an entity and 
 
 is added directly onto the current file with DPUG. When the DPU buffer 
 is complete, the segment should call: 
 
 TAD X 
 
 JMS GREGP2 
 
97 
 
 where X is zero or any desired initial 700X display command. A DPUC call 
 will be set up; the segment should follow this call with: 
 
 GIF CDFIUTBANK 
 JMS I XDPUDP 
 
 to send the display. 
 
 SVPUT 
 
 Pass a parameter to an SVPRM location in UTBANK: 
 
 TAD PARM 
 JMS SVPUT 
 SVPRMn 
 
 /n = 1-8 
 
 FREDPU 
 
 Clear the DPU flags (DPUINP and DPUINF) and set first eight 
 DPU input buffer words to blanks (i+O^O's). This allows the DPU to 
 asynchronously store more input into the buffer; this call MUST be made 
 as soon as the executing segment finishes using the data in the buffer. 
 (JMS FEEDPU). 
 
 RETIME 
 
 FREDTM 
 
 Reset the timer queue element for ten minutes. (.JMS RETIME). 
 
 Calls FREDPU, then RETIME. (JMS FREDTM). 
 
 RLV1 
 
 Use the data stored at console vector location +j6 to form a 
 parameter list and call XCTL (ACC = 0). Some segments store return data 
 in locations +72 (level 3), +lh (level 2), and +l6 (level l) of the console 
 vector before Invoking a segment subfunction; the subsegment uses this to 
 return via RLV1, RLV2 , or RLV3 to the calling segment. (.JMP RLVn). 
 
98 
 
 M0VEDT 
 
 Move data between any two locations. At entry, the PDP-8 
 data field register specifies the hank of the- calling program. Data 
 is moved starting at the specified address and continuing until the 
 word count reaches zero. The call is: 
 
 CIFIGLBANK 
 
 JMS I (M0VEDT 
 
 From addr 
 
 To addr 
 
 From bank (00F0) 
 
 To bank (00T0) 
 
 Count (> 0) 
 
 SADCV 
 
 ACC: 
 
 Add the specified word in the current console vector to the 
 
 JMS SADCV 
 disp (0-77) 
 
 SSTCV 
 
 vector: 
 
 Store the ACC at the specified word in the current console 
 
 JMS SSTCV 
 disp (0-77) 
 
 SADPC 
 
 Add the specified word in the current PCB to the ACC: 
 
 JMS SADPC 
 disp (0-177) 
 
 SSTPC 
 
 Store the ACC at the specified word in the current PCB: 
 
 JMS SSTPC 
 disp (0-177) 
 
99 
 
 ST0P 
 
 Reset the current console options area (+l^-...+37): 
 
 TAD X 
 JMS ST0P 
 Addr 
 
 Use TAD X only to specify that less than 2H„ words are to be reset 
 starting at +lk (e.g., 2h + X = number reset). Addr is the location 
 of the new contents (in GLBANK only!). 
 
 STWK 
 
 Reset the current console -work are (+50... +77): 
 
 TAD X 
 JMS STWK 
 
 The use of TAD X is analogous to its use in ST0P. The data moved in 
 is assumed to be located at +150... +177 in GLBANK page 0. 
 
 LDWK 
 
 Reset +150. . .+177 in GLBANK page from the current console 
 vector work area (+50... +77): 
 
 JMS LDWK 
 
 No alternate data length may be specified. 
 
 SVPRLD 
 
 Copy the current console vector SVPRM area (+1+0... +^7) to 
 the SVPRM area in page (+lU0. . .+1U7) of the specified bank: 
 
 TAD BNK 
 JMS SVPRLD 
 
 BNK = OOnO, where n = 3 (GLBANK) or l(UTBANK). 
 
100 
 
 SVPRSV 
 
 Copy the SVPEM area in page (+lU0., .+IU7) of the specified 
 bank to the current console vector SVPRM area. (+k0-. . .+h"j): 
 
 TAD BIK' 
 JMS SVPBSV 
 
 BNK = OOnO, where n - 3(GLBANK) or l(UTBANK). 
 
 T0LAC 
 
 Test current console status : 
 
 TAD X 
 
 JMS T0LAC 
 +0 (inactive return) 
 +1 (offline return) 
 +2 (active return) 
 
 The status of the terminal is indicated by the address of the return. If 
 the terminal was inactive and the ACC was zero on entry to T0LAC, T0LAC 
 will set the terminal to active before it returns at +0. If the ACC was 
 not zero, T0LAC just returns at +0. 
 
 GLINE 
 
 Calculate a line number (l...n) for a given Y coordinate given 
 the number of lines in the list and the Y coordinate of the top line. 
 The input Y coordinate is assumed to be in +112 of the PCB (e.g., set by 
 DPUDIN, etc. ). 
 
 JMS GLINE (ACC MUST = 0) 
 List length 
 Top Y coord 
 
 If is returned in the ACC, the input Y missed the list. This routine 
 is obviously handy for menu picking. 
 
101 
 
 APPENDIX D 
 GUTS Service Routines — Detail 
 
102 
 
 1. DSMN Routines 
 
 1.1 List 
 
 Entries 
 
 MNDPC - 
 MNNTRE ■ 
 
 Direct call entry 
 R0UTX call entry 
 
 R0UTX Calls 
 
 MEBTB - 
 MKTDEB - 
 MMIBA - 
 MGTILE - 
 MNINE - 
 MNL0DR - 
 MNMNEM - 
 MKMNIN - 
 
 MNNEN - 
 MNOTE - 
 MNREAL - 
 MNRED - 
 MNRPL - 
 MNST0R - 
 
 Block-to-block data transfer 
 
 Delete a current picture block 
 
 Initially allocate space and load nev block 
 
 Insert data at end of last entry in current block 
 
 Insert data at end of current entry 
 
 Load a current picture block into core 
 
 Build a mnemonic block from the current picture 
 
 Integrate a mnemonic as an instance into the 
 
 current picture 
 
 Insert a nev entry in the current block 
 
 Insert a nev entry at the end of the current block 
 
 Reallocate (e.g., expand) a current picture block 
 
 Reduce the allocation of a current picture block 
 
 Insert, delete, or replace data in the current block 
 
 Explicitly store a current picture block in an 
 
 IR temporary 
 
 Direct Calls 
 
 MNBL0D - 
 MNBRS - 
 
 MWBSET - 
 MDffiSV - 
 
 Load the word in the current block pointed to by BLK0RG 
 
 Reset the specified block from its PCB entry as the 
 
 current block (see MNBSV) 
 
 Store the ACC in the word pointed to by BLK0RG 
 
 Save the status of the current block in its 
 
 PCB entry (see MBRS) 
 
103 
 
 MNDEN - 
 MNDTX - 
 MNEL0D - 
 
 MNELST - 
 
 MNENUM - 
 MNESET - 
 MNEXT - 
 MNEXTC - 
 MNFIX - 
 MNFPR - 
 MNFPRA - 
 
 MWFPRT - 
 
 MNHTTJ - 
 
 MNIBD - 
 
 MNINS - 
 MNLTH - 
 
 MNM0V - 
 MNMRK - 
 
 MNMVP - 
 
 MNNXTE - 
 
 Delete the current entry in the current block 
 
 Delete text-lines in the current entry 
 
 Load the word in the current "block pointed to 
 
 by ENT0RG 
 
 Return the number of entries in the current 
 
 block (calls MMDRVE) 
 
 Return the number of the current entry (l...n) 
 
 Store the ACC in the word pointed to by ENT0RG 
 
 Extract the specified text-line from the current entry 
 
 Extract arbitrary data at P0DTTR in the current entry 
 
 Mark the specified block as fixed 
 
 Reset the P0INTR in the current entry 
 
 Reset the P0INTR to the beginning of the data 
 
 +MNM0D in the current entry 
 
 Reset ENT0RG and P0INTR to the first entry in the 
 
 current block and return the block's 
 
 address (BLK0RG) 
 
 Return the highest terminal sequence number +1 
 
 from the current block (assumed to be a terminal 
 
 block) or return if no terminals in the block yet 
 
 Set the initial data for a block and mark the 
 
 block initialized 
 
 Search for a Y, X match on an instance 
 
 Move P0INTR to the specified K-th text-line 
 
 (or the end) of the current entry 
 
 Move the specified data into the area of P0INTR 
 
 Mark the specified bits in the specified word 
 
 of the current entry 
 
 Move data (<_ 5 words) from SVPRMU-8 into the 
 
 area of P0INTR 
 
 Move ENT0RG and P0LNTR to the next sequential entry 
 
 in the current block and return an error if block 
 
 end exceeded. 
 
10U 
 
 MNPERG - Position ENT0RG to the specified n-th entry in 
 
 the current block 
 MNPL0D - Load the word at the current P0INTR location 
 
 MNPRG - If the current "block is marked in core and 
 
 initialized, its core is released by a call to MNFRE 
 MNPSET - Store the ACC at the current P0INTR location 
 
 MNTR1 - _ Search current (assumed terminal) block for 
 
 terminals "with the specified instance sequence 
 
 numbe r . Call MNS CAN 
 MNTR2 - Same as MOTEL, but search is for specified 
 
 terminal sequence number 
 MNTR3 - Similar to MNTR1, but search is for specified 
 
 Y, X and call is to MNYXF 
 MNTXS - Calls MNYXF to search the current (assumed text) 
 
 block for an entry that matches the specified Y, X 
 MNUNF - Mark the specified block as unfixed 
 
 MNYNM - Return the line number for the text-line in the 
 
 current entry that corresponds to the input 
 
 Y value 
 MN1EX - Extract one word from the current entry at the 
 
 specified location 
 MN2TB - Move data from the system 2701 first-part record 
 
 input buffer to the current block (essentially 
 
 MNIBD) ; set 2701 input I0T data for the second- 
 part of the record; and return the second-part 
 
 input address 
 
 Internal Routines (some of these are NOT restricted to DSMN use) 
 
 CTIME - 
 
 DECML - 
 
 DECTYP- 
 
 Return least significant two decimal digits of 
 an input binary number to GLBANK calling routine 
 Call DECTYP to obtain four decimal digits of an 
 input binary number; UTBANK call only. 
 Convert input binary number to decimal 
 
105 
 
 DSMNG0 - 
 
 D3MNG3 - 
 
 DSMNGU - 
 
 DSMNG6 - 
 
 DTYPE - 
 
 MNADST - 
 MNADTB - 
 
 MNALC 
 MNB0ST - 
 MNBTAD - 
 MNCEW2 - 
 
 MNDRVE - 
 
 MNFRE - 
 
 MMGET - 
 
 MNIDLM 
 MNIDLR 
 MNLDAD 
 
 Calls DSMNG6 to access IR internally for writing, 
 reading, and deleting block temporaries. 
 Called by MNST0R, MNDEB, MNL0DR 
 Called from DSMNG6 to perform actual IR call. 
 Saves and restores pertinent terminal data; 
 calls DSMNIR in GLASP to ensure serialized IR 
 use (via GETDS WAIT priority call). 
 Same as DSMNG0 but called from MNLDST during 
 MNL0DR processing (need more core). 
 Common routine to build IR parameter list for 
 DSMNG3. Called from DSMNG0 and DSMNGU. 
 Called by DECTYP to pack four decimal digits 
 into two words 
 Extract a word in a table 
 Convert a block address to a block (MNGET 
 "page") number 
 
 NOT a routine, but the MNGET page allocation list 
 Use the current BLKNUM to extract and set BLK0RG 
 Convert an MNGET page number to a block address 
 Set location Z and the data field for accessing 
 word two of a PCB entry- 
 Move ENT0RG to last entry in current block and 
 P0INTR to the end of that entry 
 Set the indicated group of pages in the MNALC 
 list to FREE 
 
 For the specified number of contiguous pages 
 desired, return the block number of the first 
 page allocated. All blocks in the group are 
 allocated by setting the appropriate word in the 
 MNALC list to N0T FREE. If not enough contiguous 
 blocks were found, -1 is returned. 
 Set MNM0D to zero 
 Set MNRSL to -1 
 
 Add an entry to the end of MNLDDA (see below). 
 If a similar entry appears in the middle of MNLDDA. 
 remove it before adding the new entry. Called by 
 MNL0DR after a block is successfully loaded 
 
io6 
 
 MNLDDA - NOT a routine, but the list of blocks currently 
 in core, whether fixed or unfixed. Each one- 
 word entry contains the addrsss of the PCB 
 control entry for the respective block. The 
 last word on the list represents the most 
 recently used block (see MNLDST, etc.) 
 
 MNLDDL - Delete an entry from MNLDDA. Called from 
 
 several routines, particularly MNDEB after a 
 block is no longer in core 
 
 MNLDFD - Called from MNLDAD and MNLDDL to find a 
 specified entry in MNLDDA 
 
 MNLDPR - Called to compress MNLDDA by one word (delete 
 an entry) from MNLDDL and MNLDAD 
 
 MNLDST - Write out in an IR temporary (as well as free 
 
 core and delete from MNLDDA) the oldest unfixed 
 block in MNLDDA. Called from MNL0DR when out 
 of space 
 
 MNMAT - Test if ACC and word at P0INTR match. Uses the 
 
 absolute value of the difference and masks result 
 with MNRSL 
 
 MNMVR - Move data into DSBANK 
 
 MNMVX - Move data within DSBANK in reverse (e.g., end 
 
 to beginning). Used to expand blocks and entries 
 
 MNNIS - Called by MNRPL to complete expansion processing. 
 Calls MNREAL to expand block, then moves in 
 remaining data from MNRPL operation 
 
 MNNMST - Resets BLKNUM as specified by ACC 
 
 MNSALC - Set the specified core page to N0T FREE by 
 marking the appropriate MNALC word 
 
 MNSCAN - Scans each sequential entry in the current block 
 for a data match 
 
 MNSTNM - Same as MNNMST, but uses SVPRM2 instead of ACC 
 
107 
 
 MNTALC - Test if the specified core page is marked 
 
 FREE or N0T FREE in MNALC 
 MNTRMX - Position ENT0RG and P0INTR to the first 
 
 terminal entry in the current (assumed 
 
 terminal) block 
 MNXTR - Extract data from DSBABK. 
 MNYXF - Calls MNSCAN to perform a Y, X vicinity test 
 
 on entries in the current "block 
 MEYXMV - Sets SVPRM5 and SVPRM6 in UTBAUK from +112 (Y), 
 
 +113 (X) in the current PCB 
 PCBXGA - Resets. PCBADR for the current terminal. Uses 
 
 the PCB copy of BLKNUM (e.g., current block) 
 
 to reset ENT0RG, P0HTR, and BLK0RG 
 PCBXGT - Calls PCBXGA after fetching current console 
 
 address from GLBA1K (INTC0N). Called by 
 
 MMTRE, MDPC, DPUPDC 
 PCBXST - The analog of PCBXGT. Saves current BLKWUM in 
 
 PCB; stores EWT0RG and P0IWTR as appropriate 
 
 (correct BLK0RG already in PCB entry) 
 SADPC - Add word at specified location in PCB to ACC 
 
 (same as GLASP SADPC ) 
 SSTCV - Same as GLASP SSTCV 
 SSTPC - Same as GLASP SSTPC 
 UTNCV - Reset console vector address in GLBANK as 
 
 specified by ACC 
 
108 
 
 1.2 Discussion 
 
 The operation, and use of, many DSMN routines is obvious and 
 clearly discernible from the listings. Only the more complex and critical 
 routines will be described here. 
 
 Loading a data structure block in the current picture is 
 normally straightforward. If the block is already in core, the PCB 
 entry is marked by MNL0DR as fixed and ENT0RG, P0INTR, BLKNUM, and 
 BLK0RG are reset to indicate that the specified block is now the current 
 block. If the block is not already in core, it must be either in an 
 IR temporary or not-initialized. MNL0DR uses the allocated page length 
 in word one of the PCB entry to request space from MNGET. If MNGET 
 returns the first page number of a suitable contiguous area, MNL0DR can 
 complete its processing. The block is brought in from IR (via DSMNG0) 
 unless the PCB entry is marked not-initialized; noninitialized blocks are 
 never stored in IR temporaries. ENT0RG, P0INTR, BLKNUM, and BLK0RG 
 are set as above, and the proper return code is saved (0K or not- 
 initialized). Finally, MNL0DR places the PCB entry address for the 
 specified block on the end of a special list, MNLDDA. This list contains 
 a one word entry for each block that is successfully loaded by MNL0DR, 
 with the last entry being the one most recently loaded. Whenever a 
 loaded block is stored in an IR temporary or deleted (MNDEB) from the 
 current picture, its entry in MNLDDA is deleted. The page list in MNGET 
 (e.g., MNALC) plus the cronological in-core block list (MNLDDA) provides 
 a description of core availability and usage in DSBANK at any time. 
 
 Note that in addition to the obvious R0UTX call, MNL0DR may 
 be invoked by other circuitous paths. A simple one is via MNIBA; the 
 equivalent of MNDEB is performed, then MNL0DR is called to set up the 
 space in core (e.g., not-initialized is the usual return code of MNIBA). 
 A deeply embedded path is via MNRPL: a block must be expanded to accept 
 inserted data, so MNNIS and MNREAL are called. MNREAL explictly stores 
 the block (MNST0R) in an IR temporary and alters the page allocation in 
 the PCB entry. Then MNREAL calls MNL0DR to bring the block back into 
 core with the new space allocation. 
 
109 
 
 The problem arises, of course, when MNGET does not locate 
 enough space. MNLDDA now comes into use; MNL0DR calls MNLDST to 
 swap-out an ,in-core block. MNLDST scans the list of blocks to find the 
 least recently used block that is unfixed. Fixed blocks, by definition, 
 cannot be swapped-out. If no unfixed blocks are found, a lockout 
 condition has occurred; MNL0DR must pass the appropriate return code. If 
 an unfixed block is found, its entry is removed from the list, and the 
 block is written into an IR temporary via DSMNGU. The core occupied by 
 the block is then released via MNFRE, and MNLDST returns to MNL0DR. 
 MNL0DR again tries to load the desired block (e.g., calls MNGET for 
 space) and, if successful, processing terminates as above. If the block 
 still cannot be allocated, MKTLDST is called again. This continues until 
 either the block is loaded or MNLDST runs out of unfixed blocks. 
 
 MNRPL is a very general routine for altering data within the 
 current data structure block, as is shown by the parameter descriptions 
 in the listing. MNRPL first calculates the length of data to be removed 
 and stores this value in MNRPL^; a simple test ensures that the length 
 does not exceed the size of the current entry. The displacement from 
 ENT0RG to P0INTR is saved in MNRPL5; this value is used to reset P0INTR 
 after the operation. The difference between the lengths of the data to 
 be removed and the data to be inserted is saved in MNRPL6; this is the 
 amount that the entry (and block) must be contracted or expanded. MNM0V 
 is then called to move in all of the input data (MNRPL6 is positive, 
 removal len > insert len) or the first part of the insert data (MNRPL6 is 
 negative, removal len < insert len; MNRPLU, the removal length, is used 
 instead of S VPRM7 , the insert length, for the call to MNM0V) . If 
 MNRPL6 is in fact zero, the replacement was exact, so a CLuick exit is 
 taken. Otherwise, P0INTR and SVPRM6 are incremented by SVPRM7 (e.g., the 
 T0 and FR0M addresses, respectively, now reflect the MNM0V operation), 
 and MNRPL6 is checked again. For MNRPL6 positive, the block only needs 
 to be contracted. After some setup, the block length and entry length 
 are altered, and MNMVR is called to move up the rest of the block to the 
 current P0INTR. Finally, P0INTR is reset using MNRPL5 to its original 
 position relative to ENT0RG, and MNRPL exits. For MNRPL6 negative, the 
 
110 
 
 "block must be expanded and the remaining insert data moved in. MNNIS 
 is called for this; after expanding the "block allocation with a call to 
 MNREAL, MNMVX is used to move the end of the block down to accommodate 
 the rest of the insert data. The block length and entry length are 
 increased appropriately, MNM0V is called to bring in the data, and MNNIS 
 returns to MNRPL. MNRPL resets P0INTR and exits. 
 
 The only hooker in the above procedure is the call to MNREAL. 
 As will become apparent in the following description, processing in 
 MNREAL may be extremely lengthly and might involve a great amount of disk 
 accessing. Keep in mind that MNRPL, even more so than MNL0DR, may be 
 entered via a large variety of paths. MNINE, MNNNE, MNILE, and MNNEN, amon^ 
 others, all call MNRPL. One of the potentially worst cases occurs when 
 MNRPL is called by MNBTB ; both blocks must be in-core and fixed during the 
 entire procedure. In fact, as the two blocks in question approach 
 maximum size (l/2 bank each), the likelihood of a lockout increases 
 rapidly, since even a small fixed block from any other terminal could 
 fragment core . 
 
 To expand the allocation of a block, MNREAL first tries to add 
 free core pages to the end of the block. MNREAL calculates the page 
 number of the core page just after the block; MNTALC is called, and if 
 the page is FREE, MNREAL calls MNSALC to set the page N0T FREE. The 
 block allocation in the PCB entry is incremented by one, and the number 
 of extra pages needed is decremented by one. If more pages are still 
 needed, the above process is repeated. If enough pages can be added in 
 this way, MNREAL will take a quick return to MNNIS. However, if MNTALC 
 finds that the requested page is already marked N0T FREE, the block cannot 
 be sufficiently expanded in this simple way. So MNREAL saves the 
 displacements of P0INTR, ENT0RG, SHDPTR, and SHDERG from BLK0RG. When 
 the block is relocated in core, these displacements are used to reset 
 the pointers to their original positions within the block. 
 
 To relocate the block, MNREAL first calls MNST0R to write the 
 block into an IR temporary. The first word of the PCB entry is then 
 altered to contain the entire block allocation needed plus bits indicating 
 not-in-core and initialized. MNL0DR is then called to bring the block in 
 
Ill 
 
 with the new space allocation. Note that the MNST0E freed the space 
 currently used by the block as well as caused its entry in MNLDDA to 
 be removed.- If MNL0DR is lucky, MNGET will find enough contiguous core 
 in some other part of DSBANK for the new block. Otherwise, MNLDST 
 will be called to start swapping -out unfixed blocks. Obviously, 
 overhead for this particular MNKPL operation has become quite high at 
 this point ! 
 
 When MNL0DR successfully loads the block, MNREAL resets the 
 pointers using the stored displacements and calls PCBXT to copy these 
 new values into the PCB entry. A return is then made to MNNIS. If 
 MNL0DR was NOT successful, this unfortunate event must be filtered all 
 the way back to the routine(s) that initiated the operation. 
 
 For working internally with IR temporary files, DSMNG0 and 
 DSMNGU call DSMNG6 to set up an IR parameter list; DSMNG3 is then 
 called to perform the actual IR linkage. Note that if DSMNGij- -was called 
 by MNLDST after a call to MNL0DR from MNREAL during MNRPL processing of 
 a MNBTB operation. . .things are really tied up! And they will get worse! 
 Not only is core held by fixed blocks and DSMN as a service is busy, but 
 IR as a service will also be tied up during DSMNG3 processing. 
 Fortunately, the CPU and disk are quicker than the terminal users (usually). 
 
 DSMNG3 saves the terminal's status within its own save areas 
 during IR processing; since DSMN as a service is busy, DSMNG3 cannot be 
 re-entered, so this saved information will not be wiped out. Unfortunately, 
 DSMNG3 cannot possibly save all of the intermediate routine returns and 
 temporary locations; hence, there is no alternative to DSMN remaining 
 busy as a service. The areas saved are: 
 
 1. Current block pointers (via PCBXST) 
 
 2. UTBANK SVPRM1-8 
 
 3. Console vector SVPRM1t8 
 
 h. Console vector R0UTX return data 
 
 A call to DSMNIR in GLASP is then made; DSMNIR issues a priority WAIT 
 request (GETIR) and returns when IR is free. DSMNG3 moves the IR 
 parameter list formed by DSMNG6 into SVPRM1-8 in GLBANK and calls IR 
 
112 
 
 via R0UTX. Areas 3 and h saved above would obviously be wiped out by the 
 R0UTX call to IR; while IR is in operation, DPU servicing or other direct 
 routine calls could easily wipe out the information in areas 1 and 2. 
 
 When IR processing is complete, 0PD0NE will return to DSMNG3; 
 the R0UTX call is, for all external appearances, quite normal. DSMNG3 
 resets the current console (INTC0N) in GLBANK and restores all four 
 areas previously saved. The complete status of the terminal and DSMN is 
 now the same as before the IR call. DSMNG3 returns and DSMN processing 
 continues . 
 
 Creating the initial form of a mnemonic storage block (MSB) 
 from the current picture is the tedious task performed by MWMNEM. The 
 only input to this routine is the Y, X values needed to position the 
 parameter model list, plus, of course, the current picture. MEMNEM first 
 allocates (via MNIBA) a two page work area in block 12 q and initializes 
 this new block via MNIBD as follows: 
 
 +0 
 
 2h 
 
 +1 
 
 11 
 
 +2 
 
 
 
 +3 
 
 
 
 +k 
 
 
 
 +5 
 
 UoUo 
 
 +6 
 
 
 
 +7 
 
 
 
 +10 
 
 
 
 +11 
 
 
 
 +12 
 
 3 
 
 +13 
 
 Y 
 
 +lk 
 
 X 
 
 +15 
 
 3 
 
 +16 
 
 13HU 
 
 +17 
 
 
 
 +20 
 
 1 
 
 +21 
 
 3 
 
 +22 
 
 
 
 +23 
 
 
 
 Total block length 
 
 First entry length (control entry) 
 
 Space for six character name 
 
 Default type word (name.O) 
 
 Space for Y and X when used as 
 
 an instance 
 
 Space for instance sequence number 
 
 when used 
 
 Space for creator's ID 
 
 Second entry length (param model entry) 
 
 Position of the parameter model list 
 
 as specified by input 
 
 Third entry length (type-name entry) 
 
 Y, X of top menu line 
 
 Fourth entry length (terminal list entry) 
 Fifth entry length (line entry) 
 Line entry displacements 
 
113 
 
 The above is functionally complete. If the current picture has an empty 
 type-name list , no external terminals , an empty line clock and an 
 empty text .block, saving the above data — even if the calling program does 
 not insert the six character name, the ID, or call the text editor to fill 
 in the parameter model entry — will result in a usuable (though very 
 uninteresting) mnemonic. Note that when an MSB is used to create an 
 instance in a picture (e.g. "integrated" by MNMHIN), the first three MSB 
 entries are copied bodily into the picture's instance block; the terminals 
 in entry four are inserted into the picture's terminal block. In both 
 these cases, MNMNIN modifies certain Y, X values in the copied data; 
 these modifications are described in the discussion of MNMNIN below. 
 Whenever a picture's instance block is displayed, the line and text 
 portions of each referenced constituent instance are recreated from the 
 respective MSB. In this case, certain displacements are added to the 
 Y, X values in the line (entry 5) and text (any subsequent) entries as 
 display file formatting is performed. This is also discussed in 
 MNMNIW below. 
 
 Consult Figure 11; after forming the above "empty" mnemonic, 
 MNMNEM proceeds to fill in data whenever available from the current 
 picture. If certain data is not available, the corresponding entry in 
 the MSB remains empty but functionally complete. Entry one is already 
 complete; the calling program is responsible for filling in the name, the 
 type word, and the creator's ID before calling SVENMN to add the MSB to 
 the library. The Y, X and instance sequence number locations are not 
 used until MNMNIU integrates the MSB as an instance. Entry two is also 
 already complete; the calling program is responsible for calling the text 
 editor so that the terminal user may enter the desired parameters. If no 
 such call is made , entry two is just a text entry with no lines . Setting 
 the third entry is a good demonstration of the block-to-block facility; 
 MNMNEM proceeds as follows. 
 
 The MSB (block 12) is the current block; it is in-core and 
 fixed. MNPEEG is called to position ENT0RG and P0INTR to the third entry; 
 
nh 
 
 MNBSV is then called to save the current status (e.g. ENT0RG and P0INTR) 
 of the current "block (No. 12) in the appropriate PCB entry (PCB+60). 
 MNL0DR is called to load the terminal block (block k) ; this makes block h 
 the current block. If lockout occurred during MNL0DR, a quick exit is 
 taken and the calling routines must check for this return code; the 
 terminal user should simply try the operation again. If "block k is not 
 initialized, there can be no type name list, so entry three of the MSB 
 will remain as it is. Block k is set unfixed, block 12 is left in its 
 "saved" condition, and MNMNEM proceeds to load the line block (No. 0); 
 see below. If block k is_ loaded successfully (e.g., it is initialized), 
 MNBSV is called to save its status, as was done for block 12. Note that 
 MNL0DR always sets ENT0RG and P0INTR to the first entry in the loaded 
 block; since the first entry in the terminal block contains the type name 
 list , this is the entry that will be used to set the third entry in the 
 MSB. Hence, MNPERG was NOT called before MNBSV, since the desired 
 entry was already pointed to. MNBRS is now called to make the MSB, 
 block 12, the current block again; the appropriate pointers are reset from 
 ENT0RG and P0INTR in the PCB+60 entry. The MSB with its pointers set to 
 the third entry, is the T0 block, while block k with its "saved" pointers 
 set to the first entry is the FR0M block. MNBTB is now called to "replace" 
 the data in the current T0 block location with a copy of the data at the 
 FR0M block location. Obviously, since the MSB may be expanded by 
 subsequent calls to MNREAL from MNRPL, the lockout condition must be 
 tested when MNBTB returns to MNMNEM. If lockout occurred, a quick exit is 
 taken, as above. If the operation completed normally , MNMNEM proceeds to 
 work on MSB entry k t the terminals. Note that even in the case of 
 normal completion, the MSB might now be in a different core location; the 
 pointers, ENT0RG and P0INTR, were properly reset to the necessary 
 relative locations within the block by MNREAL. 
 
 Processing the other entries in the MSB is handled in the same 
 fashion. The pointers to the desired MSB entry are set, and the MSB is 
 "saved" with MNBSV. Then the desired picture block is loaded, its 
 pointers set, and its status saved with MNBSV. The MSB is made the current 
 block with MNBRS, and MNBTB is called to transfer the data. At all 
 
115 
 
 appropriate points, lockout is tested. Uninitialized "blocks are checked 
 for, and all "blocks are unfixed as soon as possible. 
 
 After successfully setting the type name entry in the MSB, 
 MNMNEM calls MNNXTE to set the pointers to the fourth (terminal's) 
 entry; the MSB status is then saved with MNBSV. Since the terminal 
 block, No. 4, is already loaded, MNBRS is called to make it the current 
 block. Its pointers are then moved to the first terminal entry, and 
 MNMNEM proceeds to extract each external terminal and insert the 
 appropriate terminal data, if any, into the MSB. Finally, all terminals 
 are checked, MSB entry four is complete, and the terminal block is 
 unfixed. MNMNEM is now ready to process the picture's line and text blocks. 
 
 The first (only) entry in the line block (No. 0) is copied into 
 the MSB's fifth entry in a manner directly similar to the processing of the 
 type name entry described previously. Then each entry, if any, in the 
 text block (No. l) is added as a new entry at the end of the MSB. In this 
 case, MNBTB is called so that MNNNE is used instead of MNKPL. 
 
 The MSB is complete ; MNMNEM processing terminates . 
 
 As mentioned in MNMNEM, the MSB is used (l) to form an instance 
 in the current picture's instance and terminal blocks, and (.2) for 
 displaying the line and text portions of the instance during REGEN. 
 When MNMNIN is entered, it assumes that the MSB to be integrated into the 
 current picture is already loaded in block 12 ft ; processing is essentially 
 carried out as in MNMNEM. That is, MNBSV, MNBRS , and MNBTB are used to 
 copy information from the MSB to the instance and terminal blocks; the 
 same type of error checking (lockout, not-initialized, etc.) is also used. 
 The only input to MNMNIN is the Y, X position of the instance center. Note 
 that when the MSB was constructed, the locations of the terminals, the 
 parameter model list, the lines, and the text entries were all stored 
 as absolute screen coordinates. However, when displayed as an instance, 
 this information must be displayed relative to the instance center. To 
 facilitate this adjustment, the MSB is assumed to have been created with 
 its center at (1000, 1000). The adjustment, then, consists of setting 
 
116 
 
 YD = Y + (YN-1000) 
 XD = X + (XN-1000) 
 
 where YD and XD are the adjusted coordinates for the instance, Y and X 
 are the coordinates stored in the MSB, and YN and XN are the input 
 coordinates of the instance center. Consult Figures 9 and 12. 
 
 MNMNIN builds the control entry (first of three entries to 
 be added to the instance block) from the data in the first MSB entry, 
 the input Y, X, and the instance sequence number (INST). INST is 
 obtained by adding one to the INST found in the last instance (call to 
 MNDRVE followed by call to MNPERG plus a call to MNPL0D). If the 
 instance block has not previously been initialized, it is initialized, 
 and zero is used for INST. The control entry is added to the instance 
 block with MNNNE. 
 
 The parameter model entry is added to the instance block next ; 
 then the entry's Y, X is adjusted to YD, XD. The type name entry is the 
 last of the three entries to be added to the instance block; its Y, X is 
 not altered since it is always displayed in the menu area if used. The 
 instance block is now set to unfixed, and the terminal block is loaded. 
 
 If the terminal block was not initialized, it is initialized 
 now; zero is used for the first terminal sequence number (TRM). Each 
 terminal in the MSB's fourth entry is extracted; the Y, X is altered to 
 YD, XD; the next TRM is obtained with a call to MNHTN; and the resulting 
 entry is added to the terminal block. This continues until all terminals 
 are extracted. Then the terminal block is marked unfixed; block 12 is 
 left as the current block; and MNMNIN processing is at an end. 
 
 During display of the line and text entries of an MSB, DPUM 
 uses the YN, XN obtained from the instance control entry for the instance 
 to modify the appropriate Y, X fields. Consult DPUM in the listing. 
 The terminals and parameter model list, of course, are already set to the 
 proper locations due to MNMNIN 's manner of integration. 
 
117 
 
 2. DPU Routines 
 
 Entries 
 
 DPUENQ 
 DPUPDC 
 
 R0UTX call entry 
 Direct call entry 
 
 R0UTX Calls 
 DPUENQ 
 
 Immediate operations ; enqueue DPU 
 
 Direct Calls ("Add data to the current display file" = AD) 
 
 DPUA - 
 DPUB - 
 DPUC - 
 
 DPUDI - 
 
 DPUDP - 
 DPUDV - 
 DPUE - 
 
 DPUF - 
 DPUG - 
 DPUH - 
 DPUI - 
 
 DPUJ - 
 
 DPUK - 
 
 DPUL - 
 
 DPULY - 
 DPUM - 
 
 DPUNL - 
 
 Display a text -line 
 Display a line 
 
 Display an arbitrary preformed file or display 
 the current display file just built 
 AD to move the "beam invisibly (blanked) 
 with a vector 
 
 AD to move the beam visibly or invisibly ■with a point 
 AD to move the beam visibly with a vector 
 AD to display the specified text-line at a 
 specified Y, X 
 
 AD from <_ five words from SVPRMU-8 
 AD of any arbitrary length 
 AD consisting of a specified vector block 
 AD formatted from the text-lines of the 
 current (assumed text) entry 
 
 AD formatted from the text-lines of all entries 
 in the current (assumed text) block 
 Uses DPUKA and DPUKB to send the specified text- 
 line to the terminal's character line buffer 
 AD formatted from the terminals and terminal 
 connections of the current (assumed terminal) block 
 AD formatted from the specified terminal entry 
 AD formatted from the current (assumed mnemonic 
 storage) block 
 
 AD formatted from the point groups of the current 
 (assumed line) block 
 
118 
 
 Internal Routines 
 
 DPUDQ - 
 
 DPUFER - 
 DPUHBN - 
 DPUHL - 
 
 DPULEN - 
 
 DPULW - 
 
 DPULX - 
 
 DPUMl+X - 
 
 DPU0NE - 
 DPUPNT - 
 
 DPUQ - 
 
 DPURAD - 
 
 DPUREF - 
 
 After display file complete (and being 
 
 transferred by DPU) , link to DPUDQ1 in 
 
 GLASP to await DPU completion. DPUDQ1 sets 
 
 WAIT priority call GTDPU; then returns 
 
 control to segment via XCTL2 (immediate 
 
 command) or XCTLS (direct call) as appropriate 
 
 Save specified reference center input 
 
 Turn high (bit 0) ACC bit on (=l) 
 
 Add an exit mode sequence (0000, U000) to 
 
 the display file 
 
 Check that enough space is left in the 
 
 display file buffer for the next insert 
 
 Display terminal connections ; all or just 
 
 visible connections can be specified 
 
 Display terminal symbols and/or characters 
 
 as specified 
 
 Called from DPUM to display the line entry of 
 
 a mnemonic storage block 
 
 Add the single word in the ACC to the display file 
 
 Increment P0INTR by 1 and load the ACC from the 
 
 word at that location 
 
 Increment or decrement the display file pointer 
 
 by the ACC amount 
 
 Reset the display file pointer to the beginning 
 
 of the buffer and set an initial command (if 
 
 SVPRM8 not zero) 
 
 Reset the reference center with the saved data 
 
 (see DPUFER) 
 
 All DPU routines perform well-defined functions in a straight- 
 forware manner. The necessary parameter list and a short description 
 precede each routine in the listings. 
 
119 
 
 APPENDIX E 
 
 
 
 CALR (CALRl) :0 
 
 P- 
 
 120 
 
 GSAM ( GSAMV1 ) : 1 
 
 P- 
 
 123 
 
 GUT1 (TEXTHN) : 30 
 
 I>- 
 
 125 
 
 GUT2 : 31 
 
 P- 
 
 129 
 
 GUT3 (REACT): 32 
 
 P. 
 
 133 
 
 DEX1 (DEXCHK) :33 
 
 P- 
 
 138 
 
 PSIR (IRINIT) :3T 
 
 P. 
 
 139 
 
CALR (CALRl) ;0 
 
 120 
 
 CALRl (*U000) 
 System Entry 
 
 CLEAR CONSOLE 
 VECTOR AND PCB 
 TO ZERO. SET 
 DEVICE ENTRIES. 
 SET FIRST DISPLAY 
 
 SEND DISPLAY^O 
 Iterminal (CAL0UT) 
 
 RELE3E 
 (Await Input) 
 
 DPU TIMER (Program Pick) 
 aboard (Loggon) 
 ( Logon ) 
 
 B ) CALTM1 
 
 /SAVE MENU B 
 \INIR (SVNMB, 
 
 CALTM3 V 
 
 ERASE SCREEN DPU) 
 DELETE CORE COPY 
 OF MENU BLK (fNDEB) 
 SET TERMINAL 
 INACTIVE 
 
 PRINT LOGO 
 TTY MSG (L0G) 
 
 I 
 
 RELESE 
 (Exit from CALR) 
 
 CALR2 (*l+200) 
 
 Called Program Return 
 
 CLEAR CONSOLE 
 VECTOR AND SAFETY 
 DELETE (MNDEB) 
 OF ALL BLOCKS. 
 CLEAR PCB 
 
 A ) CALDP1 
 
 SAVE FIRST 
 SIX KEYBOARD 
 WORDS (FREDPUJ 
 
 3all dex1 to 
 :heck logon spring 
 
 CALSRX 
 
 CALSRX 
 
 /print THREAT 
 \^TY MSG (L0G1 
 
 CALN0N 
 
 SET NOT 
 FOUND MESSAGE 
 
121 
 
 
 
 i 
 
 Sprint logon\ 
 
 (tTY MSG (L0GW 
 
 CALGKX' 
 
 READ MENU 
 BLOCK (LDNMBkI) 
 
 CORRECT THE 
 
 ALLOCATION IP 
 
 EXISTED (MNRED) 
 
 OR INITIALIZE 
 
 A NEW BLOCK IF 
 PIP NOT EXTST 
 
 CALDP3 
 
 RESET DEVICE 
 INPUTS AND 
 TIMER. SET 
 PROGRAM PICK 
 DISPLAY 
 
 (Program Pick) 
 
 2701 (MSG) 
 C2 ) Timer (CALTM2) 
 
 Keyboard ( CALTM U) 
 
 ch ) Menu (CALMEN) 
 Logout (CALTM) 
 
 CALTM2 
 
 SET TIME DEVIDE 
 
 ADDRESS FOR 
 
 LOGOUT (CALTmL) 
 SET AUTO- 
 LOGOUT MSG 
 
 MSG 
 
 'SEND 2701 
 TEXT LINE 
 TO TERMINAL 
 (GLMSGA) 
 
 RELESE 
 
 © 
 
 CALTM 
 
 FREDPU 
 
'PURGE ALL 
 ^ILES LISTED 
 CN MENU BLOCK 
 FROM LOCAL I J 
 JjLEJPJ 
 
 FREDTM., SET 
 "what?" MSG 
 
 122 
 
 CALMEN 
 
 ALLOCATE STND 
 BLOCKS . CLEAR 
 DEVICE ENTRIE$ 
 SET LEVEL 1 
 RETURN FOR 
 CALR2 
 
 I 
 
 XCTL TO PROGRJM 
 
 AS PER TABLE (AVAIL) 
 
123 
 
 GSAM (GSAMVl):! 
 
 GSAMVl (*U000) 
 Level X Entry 
 
 ET CONSOLE 
 VECTOR (ST0P) 
 FOR MAIN MODE 
 ENQUE DPU.ADD 
 MIS MODE TEXT! 
 EN MENU AND 
 
 KOMPT ATffiAS 
 
 GSAM3 
 
 ADD FRAME, 
 SYSTEM LINE, 
 USER LINE, 
 RETURN, PANIC 
 
 GSAM2 
 
 SEND TO 
 TERMINAL 
 (GREGP2, DPUPtC) 
 
 t 
 
 RELESE 
 
 (Await Input) 
 
 Timer DPU DFU 
 (main (sub 
 mode ) mode ) 
 
 A ) G2TIN 
 
 /DISPLAY LINEN 
 
 RELESE 
 (Await Input) 
 
 
 
 B I GTMRIN 
 
 RESET TIMER TV 
 2 MEN. RESET 
 TIMER INPUT 
 
 ADDR TO 
 BEJnifflIg2j 
 
 ENQUE DPU, ADD 
 "AUTO RETURN"! MSG 
 
 ( mainmode ) 
 
 Menu (GJSMNH) 
 
 C2 ) Return (GJSREH) 
 
 (submode) 
 
 Menu (GSPECY) 
 
 D2 ) Return (GSPECX) 
 

 ^■RELESE 
 (Await Input) 
 
 GC0NS, GC0MU 
 
 SET LEVEL 2 
 
 RETURN TO 
 
 GSAMV1. XCTL 
 
 TO GNDR OR TO 
 REACT 
 
 GSPEC \ 
 
 1 
 
 RESET DPU 
 RETURN AND 
 MENU INPUT 
 FOR SUBMODE 
 
 1 
 
 ' 
 
 ENQUE DPU. 
 ADD ERASE, 
 "SPECIFY" ! 
 MENU, PROMPT 
 
 124 
 
 Dl ) GSPECY 
 
 »RELESE 
 (Await Input 
 
 SET BLOCK NO, 
 AND ENTRY NO, 
 FOR TEXT 
 ENTRY EDITOR 
 
 LOAD REQUESTED 
 BLOCK (5 OR 6) 
 INITIALIZE IF 
 NOT-INITIALIZED 
 
 GSPEC A il 
 
 SET APPROP- 
 RIATE MSG INTO; 
 PCW0RK FOR 
 TEXT EDITOR 
 
 SET LEVEL 3 
 RETURN TO 
 GSPEC5 (D3) 
 XCTL TO GUT1 
 
 C2 
 
 GJSREH 
 
 D2 GSPECX 
 
 FREDTM 
 
 RLV1 TO CALR 
 
 FREDTM 
 
 (Exit GSM) 
 
 GSAMV1 
 
 D3 
 
 GSPEC5 
 
 RESET CONSOLE 
 VECTOR (ST0P) 
 
125 
 
 GUT1 (TEXTHN):30 
 
 TEXTHN (*l+000) 
 Level 3 Entry 
 
 Dl APPEND 
 
 CLEAR 
 GREGEN FLAG 
 
 REGENT 
 
 PASS APPEND MOID 
 KEYBOARD ADDR 
 
 LOAD INDICATEI 
 BLOCK TO BE 
 MODIFIED. ENQUI 
 DPU.ADD ALL 
 FRAME TEXT. 
 ADD INDICATED 
 ENTRY FROM BLE 
 
 SET KEYBOARD 
 INPUT ADDRESS 
 CLEAR HITS 
 FLAG 
 
 UNFIX BLOCK, 
 
 ADD MSG FROM 
 
 PCW0RK.SEND 
 DISPLAY TO 
 TERMINAL 
 
 RELESE 
 (Await Input) 
 
 DO REGEN 
 
 A J I B J f C 
 
 Timer 2701 DPU 
 
 A J P0PT 
 
 (Exit GUT1) 
 
 RESET CONSOLE 
 VECTOR (ST0P) 
 
 
 £ 
 
 C0MIN 
 
 DISPLAY LIN$, 
 [ CLEAR 2701 
 I VTA GLMSGA 
 
 7 
 
 RELESE 
 ( Await Input ) 
 
126 
 
 
 Answer (REGEN) 
 
 C2 ) Eeturn (P0PX) 
 C3 ) Draw (PICK) 
 
 Light Button (FUNKY) 
 C5 ) Keyboard Append (APPL) 
 
 Keyboard Insert (INSRTL) 
 
 CI ^ REGEN 
 
 FEE DIM 
 
 PASS FLAG FOR 
 TOTAL REGEN 
 OR JUST 
 TEXT 
 
 XTHI 
 
 TEXTHN 
 
 INSRTL 
 
 BUFFER KEY- 
 BOARD LINE IN 
 PC¥0RK,FREDTM, 
 LOAD BLK, 
 BUMP LINE NO. 
 IN HIT1 
 
 MOVE P0INTR 
 TO INDICATED 
 LINE (MNLTH) , 
 SET FOR 
 INSERT (MNRPlJ) 
 
 APPL 
 
 BUFFER KEYBOAID 
 LINE IN PCW0RI 
 FREDTM.LOAD 
 BLOCK, SET POL 
 INSERT AT END 
 OF ENTRY (MNI1E) 
 
 R0UTX CALL FOR 
 LINE INSERT 
 
 C2 ) P0PX 
 
 RELESE 
 (Await Input) 
 
 FREDTM 
 
127 
 
 LOAD BLOCK, 
 GET LINE NO, 
 HIT (MNYNM) 
 
 
 SET "MISSED" 
 MESSAGE 
 
 (UMISTX) SEND 
 TO TERMINAL 
 
 SET LINE NO, 
 INTO HIT1 
 
 
 
 SET LINE NO. 
 INTO HIT2 (IF 
 WAS 1ST HIT, 
 THEN HIT1=HIT$ 
 IF WAS 2TO 
 NOW CORRECT) 
 
 SET HITSNOT 
 
 V 
 
 rvELESE 
 (Await Input) 
 
 CALCULATE 
 WHICH FUNCTION 
 AND GO TO ROUriNE: 
 
 Dl 
 D2 
 D3 
 ■Dk 
 
 APPEND 
 DELETE 
 CHANGE 
 INSERT 
 
128 
 
 D2 A DELETE 
 
 1 
 
 LOAD BLOCK 
 
 (PERFORM ^ 
 DELETE (D5)y 
 
 CALL MNDIX 
 WITH HIT1 AND 
 HIT2 LINE 
 NUMBERS 
 
 f RETURN ) 
 
 
 
 CHANGE 
 
 LOAD BLOCK, 
 ENQUE DPU 
 
 PASS LINE NO. 
 
 FROM HIT1 TO 
 
 DPUK TO SEND 
 
 LINE TO TERMlJLAi 
 
 (DPUK IGNORES 
 
 OPERATION IF, 
 HIT1 INVALID) 
 
 /PERFORM ~*\ 
 VDELETE (D5) J 
 
 POSITION P0INTR 
 
 AT HIT1 LINE ^MNLTH) 
 
 DU > INSERT 
 
 PASS INSERT 
 
 MODE KEYBOARD! ADDR 
 
GUT2 : 31 (only the less obvious routines are included) 
 
 RGINST (*U000) 
 REGEN Entry 
 
 129 
 
 SAVE THE 
 INSTANCE BLK 
 
 NO, 
 
 RGINST V 
 
 EXTRACT CONTRCjL 
 ENTRY FOR 
 CURRENT (1ST) 
 INSTANCE. SAVE 
 INSTANCE BLK 
 STATUS 
 
 SET WORK BLK 
 AS CURRENT 
 
 BIK 
 
 TEST NAME AL- 
 READY IN WK 
 CONTROL ENTRY 
 WITH EXTRACTED 
 NAME, 
 
 RGJ1SA 
 
 LOAD NAMED 
 4SB INTO WORK', 
 
 Iblk (LDNMBK 
 ^GINSX.CALL) 
 
 EGINSU 
 
 EKQUE DPU.ADD 
 LINES. AND TEX^ 
 (DPUM).SEND TC 
 TERMINAL (DPUC) 
 
 RESET INSTANCE] 
 BLK AS CURRENT 
 MOVE P0INTR TQ 
 NEXT INSTANCE | 
 
 BLCS 
 
 UNFIX BOTH 
 RETURN TO GREi 
 
 (Ignore) 
 
130 
 
 LDNMHP (*U633) 
 Level 3 Entry 
 
 LDNPC6\ 
 
 DELETE COKE 
 AND IR TEMP- 
 ORARY FOR EACH 
 CURRENT 
 [PICTURE BLOCK 
 
 TiCTMmy 
 
 READ NEW FCB 
 FROM IR 
 ( LDNMH2 ) 
 
 LDNPC5 
 
 LDNPCT 
 
 NO SUCH PIC- 
 TURE, SO 
 INITIALLY ALLOCATE 
 STANDARD BLKS 
 
 AS CATlR WOULD 
 
 FCB NOW REPRESENTS 
 BLKS FOR NEW PICTURE, 
 BUT BLKS STILL ON 
 DISK EVEN IF PCB 
 ENTRIES INDICATE 
 OTHERWISE (SOME BLKS 
 MIGHT STILL HAVE BEEN 
 IN CORE WHEN FCB WAS 
 SAVED DURING SVNMHP). 
 SO: EACH IN-USE BLK 
 IS MARKED NOT-IN- 
 CORE TO PREVENT 
 ILLEGAL CORE PURGE 
 BY LDNMBK IN SUB- 
 SEQUENT PROCESSING 
 
 © 
 
 LDNMHX 
 
 rSET UP AND 
 2ALL PIC0PS TC 
 jOAD EACH BLK 
 <FROM IR (PS)/ 
 
 PS ) PIC0PS 
 
 SET INTERVAL 
 CALL RETURN 
 FOR WITHIN 
 PIC0PS, ZERO 
 BLK COUNTER 
 
 CALL INDICATED 
 ROUTINE IN- 
 TERNALLY FOR 
 EACH PICTURE 
 
 LK (0-9) 
 
 LDMNBKjSVNMBk: 
 
 MMBKJL 
 
 Pk ) PIC0PY 
 
 RESET 
 PWRK+1 = -1 
 
 I 
 
 RLV3 
 
131 
 
 LDNMBK (*UUOO) 
 
 Entry (Level 3 or Internal) 
 
 GET ALLOCATION 
 FROM PCB 
 
 ESTABLISH 
 INPUT BLOCK 
 VIA MNIBA 
 
 SET DUMMY 
 DATA TO 
 INITIALIZE 
 BLOCK 
 
 
 
 7 J LDNMBT 
 
 
 
 LDNMB2 
 
 SET SVPRM8= 
 (RETURN CODE 
 
 u 
 
 » RLV3 
 
 RGINSX 
 
 USE PWRK FOR 
 ADDRESS, WAS 
 OTHER INTERNAL 
 CALL. RETURN 
 
 RESET SVPRM6 
 AND SVPRM2 
 
 -0 
 
132 
 
 
 1 
 
 [call ir to read 
 {in named file 
 
 RESET AND 
 
 USE RETURNED 
 
 LENGTH TO 
 ALLOCATE 
 PROPER SPACE 
 
 Routines NOT Included 
 
 SVNMBK 
 DLNMBK 
 
 SVNBHP 
 DLNMHP 
 
 SNDPC 
 
 SNDBLK 
 
 SNDHDR 
 
 SVENMN 
 DELNMN 
 
 MENUD 
 MENUA 
 MENUX 
 DIMENN 
 
133 
 
 GUT3 (REACT): ^2 
 
 REACT (*k600) 
 Level 2 Entry 
 
 SET CONSOLE 
 VECTOR (ST0P; 
 SET AUTO- 
 SAVE 0FF (0) 
 
 C0MUN1 
 
 SET NEW 
 DISPLAY FILE 
 (DPUNQ, 
 GREGPl) 
 
 SEND NEW 
 DISPLAY (GREGP 2) 
 
 RELESE 
 (Await Input 
 
 A )) i B J i C 
 
 2'? J DPU TIMER 
 
 Segment V_^/ Segment 1-9 
 Keyboard 
 
 REACL1 (*5000) 
 Level 1 Entry 
 
 COPY RETURN D\TA 
 TO LEVEL 2 AR3A 
 
 REACT 
 
 © 
 
 A 1 2701 Interrupt 
 (C0MIN) 
 
 RESET TIMER 
 (RETIME) 
 
 VVIA GLMSGA J 
 
 RELESE 
 (Await Input) 
 
 Timer Interrupt 
 
 RLV2 
 (Exit to caller 
 on level 2) 
 
13k 
 
 & 
 
 P0PY 
 
 CLEAR DPU AND 
 TIMER (FREDTM 
 
 RLV2 
 
 B3 ] C0MJSn 
 
 SET SEGMENT 
 NUMBER TO n, 
 FREDTM 
 
 SET 2701 
 OUTPUT RECORD: 
 Y, X, n 
 
 2701 SEND 
 (R0UTX) 
 
 RELESE 
 
 B2 } C0MKB 
 
 EXTRACT FIRST 
 WORDS FROM BTJ 
 
 FIVE 
 rpER 
 
 COPY LINE TO 
 PCW0RK, FREDTM 
 SEND TO 2701 
 (R0UTX) 
 
 RELESE 
 
 RELESE 
 
135 
 
 EXTRACT SIX 
 WORDS FROM 2701 
 BUFFER. CLEAR 270] 
 (R0UTX NO. U) 
 
 MOVE IN NEW 
 NAME 
 
 SAVE ECHO; 
 RESET SEG 1-S 
 FILTER AND 
 KEYBRD FILTER 
 
 
 
 A5 ) C0MBTS 
 
 SET ERASE AND 
 FRAME BITS 
 
 RELESE 
 
 DO IMMEDIATE 
 DPU COMMAND 
 
 GREGEN 
 
 RELESE 
 
 ) 
 
 ». RELESE 
 
136 
 
 FREDTM 
 
 Execute Command: 
 
 ! ! (EXIT) -*- RLV2 
 
 !" (XCTL to GNDR, level 1 and 2 returns remain as set) 
 
 ## (Load/Send named picture) ■*■ \B6) 
 
 && (Load/Send named mnemonic) -*■ (b6) 
 
 C# (Send current picture as is or renamed) ^"(b6) 
 
 C& (Send current mnemonic as is or renamed) ■*■ (b6) 
 
 
 
 SEND "DONE" 
 OR "ERROR" TO 
 THE DISPLAY 
 
 REDESE 
 
 DELETE EACH P 
 BLOCK (MNDEB) 
 
 [CTURE 
 
 RELESE 
 
 JAVE CURRENT 
 
 5 i cture (svm$p) 
 
 5VNMHI 
 
 JES^/dAVE MNEMON] 
 
 BLK 12 (SVEN^N) 
 
137 
 
 © 
 
 C0MTBL 
 
 DISPLAY THE 
 INPUT BLOCK 
 AS 
 APPROPRIATE 
 
 RELESE 
 
 
 
 C0MNTH 
 
 ALLOCATE A BLK AT WORK BLK 
 (12) OR SPECIFIED BLK (0-l(.) 
 WITH MNIBA. USE MN2TB TO 
 SET FIRST PART OF NEW BLK 
 
 CALL 2701 
 (R0UTX3) TO 
 FINISH INPUTTING 
 INTO NEW BLOC: 
 
DEX1 (DEXCHK) ;33 
 
 DEXCHK (*^000) 
 Level 3 Entry 
 
 138 
 
 MATCH INPUT 
 STRING TO 
 LOGON 
 DIRECTORY 
 
 
 \ 
 
 ZES 
 
 
 
 y 
 
 ,NO 
 
 
 RETURN ID, 
 
 RETURN 
 
 PROTECTION 
 
 
 PASS 1 
 
 
 
 
 
 
 
 _J 
 
 ' 
 
 
 
 _J 
 
 ' 
 
 
 .PASS 
 
 
 SET CODE 
 
 INTO 
 
 SUPRM8 
 
 
 
 
 
 
 
 
 \ 
 
 ' 
 
 
 RLV3 
 (Exit DEX1) 
 
 DEXCHK 
 
PSIR(IRINIT):3T 
 
 139 
 
 IRINIT (*U600) 
 G LASP Ent ry 
 f 
 
 INITIALIZE IK -CORE- 
 POINTERS (SBUFSZ, 
 SBLKDN, ERRCNT 
 DIRCUR) 
 
 IRINI2 
 
 LOCK ONTO CPU, SWAP 
 BANKS 0,1 INTO SLOT 
 2. ZERO BANK 1 AND 
 WRITE ZEROES INTO 
 IR DISK DIRECTORY. 
 
 WRITE LIST OF BLOCK 
 NUMBERS INTO DISK 
 FREE LIST AND SET 
 UNSORTED POINTERS 
 
 REQUEST A BLOCK: 
 SINCE NO BLOCKS IN 
 SORTED LIST, IR DOES 
 A SORT! (VIA GETBLK) 
 
 FREE THE REQUESTED 
 BLOCK. RELOAD BANKS 0, 
 1 FROM SLOT 2. 
 RELEASE CPU 
 
 REFILL (*U000) 
 GETBLK Entry 
 
 LOCK ONTO CPU;READ IN 
 REST OF SORTED LIST 
 AND ADD TO IN- CORE LIST 
 
 ADD ALL SORTED BLOCKS FROM 
 IN- CORE LIST TO DISK UN- 
 SORTED LIST VIA FREBUF 
 
 SWAP BANKS 0, 1 INTO SLOT 
 1. READ UNSORTED LIST 
 INTO BANK 0. 
 
 SORT LIST INTO "POCKETS" 
 (M0D 60) INTO BANK 1. 
 COLLECT AND WRITE ONTO 
 DISK SORTED LIST 
 
 RELOAD BANKS 0, 1 FROM 
 SLOT 1. RESET BLOCK 
 POINTERS 
 
 Exit to GETBLK 
 
 Exit to GLASP 
 
Form AEC-427 
 
 (6/68) 
 
 AECM 3201 
 
 U.S. ATOMIC ENERGY COMMISSION 
 
 UNIVERSITY-TYPE CONTRACTOR'S RECOMMENDATION FOR 
 
 DISPOSITION OF SCIENTIFIC AND TECHNICAL DOCUMENT 
 
 ( See Instructions on Reverse Side ) 
 
 1. AEC REPORT NO. 
 
 COO-1U69-0190 
 
 2. TITLE 
 
 GRASS: System Software Description 
 
 3. TYPE OF DOCUMENT (Check one): 
 
 E3 a. Scientific and technical report 
 
 I I 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) 
 
 4. RECOMMENDED ANNOUNCEMENT AND DISTRIBUTION (Check one): 
 
 [3 a. AEC's normal announcement and distribution procedures may be followed. 
 
 Q b. Make available only within AEC and to AEC contractors and other U.S. Government agencies and their contractors. 
 
 1] c. Make no announcement or distrubution. 
 
 5. REASON FOR RECOMMENDED RESTRICTIONS: 
 
 6. SUBMITTED BY: NAME AND POSITION (Please print or type) 
 
 C. W. Gear, Professor 
 
 and Principal Investigator 
 
 Organization 
 
 Department of Computer Science 
 university of Illinois 
 Urbana, Illinois 6l801 
 
 Signature 
 
 ^^htMlki^a^-' 
 
 Date 
 
 August 1971 
 
 FOR AEC USE ONLY 
 
 7. AEC CONTRACT ADMINISTRATOR'S COMMENTS, IF ANY, ON ABOVE ANNOUNCEMENT AND DISTRIBUTION 
 RECOMMENDATION: 
 
 8. PATENT CLEARANCE: 
 
 I I a. AEC patent clearance has been granted by responsible AEC patent group. 
 I I b. Report has been sent to responsible AEC patent group for clearance. 
 I I c. Patent clearance not required. 
 
jND&>