This paper is an amendment to SPROGS paper 15 about the basic graphics package on the PDP15. It will assume a knowledge of that paper and of VTPRIM.
It outlines another system I've come across and sets out one or two ideas that ought to be included in the Atlas system.
A package for the PDP15 has been written by Lasse Leiro of the Electrical Engineering department of the University of Massachusetts and includes the following features:
1.1 A routine corresponding to DINIT starts up a display file which contains a standard sequence of display orders for setting certain picture parameters and which finally calls the picture which the user thinks is the main picture, The effect is that all the parameter setting orders are obeyed at the start of every cycle of the whole display file structure. SPROGS paper 15 does not discuss ways of automatically including parameter settings in a main file; I think the idea above is a good solution.
1.2The SYNC order is normally included in the standard main file (1.1). There is a routine SYNCOF to remove this order if the user wants the picture out of sync.
1.3 There are no REPLACE-type routines. Each picture routine can either replace or append depending only on an input variable KTYP. The idea is that the user does not need to use different routines depending on where his display item goes. My feeling is that replace and append are entirely different situations anyway and it's not worth amalgamating them in one routine.
1.4 The system does not turn the display off when a file is to be altered. This ignores a problem discussed in section 2.4.
1.5 SETPT or POINT allows visible dots, SPROGS 15 allows this already.
1.6 There are routines for inhibiting the visibility of a display item. In the case of lines and points a visibility bit is set to zero. In the case of text or display call, a jump-around-item order is inserted.
1.7 PAR1,PAR2,DASH routines correspond to the VTPRIM PRAMTR routine. Our idea in contrast is to use a separate routine for each feature. This latter WOt1ld be more convenient to use at the cost of occupying more space but we can assume that parameter setting orders are not required many times in a display file.
1.8 LTORPB sets a flag specifying whether lightpen hit was received in the offset or main portion of the screen.
1.9 Their system is to include an ingenious method of using several name registers in parallel. It uses the fact the VT15 can change the contents of a location in store with a DJMS order.
1.10 There are some simple integral zooms.
2.1 The routines DINIT and DCHOOS will identify a file header by array name and array element. Whenever a file is updated, its length will be checked to ensure that the array is not overflowed. A check will also be made for the bank boundary.
2.2 In order to blank and unblank a file without turning off the display, an extra word is included in the file header. The file header in the 2 cases will look like:-
UNBLANKED BLANKED
FILE (1) length length
FILE (2) return address return address
DNOP DJMP* FILE(2)
display orders display orders
. .
. .
. .
. .
. .
DJMP* FILE(2) DJMP* FILE(2)
The disadvantage is that 4 words of non-display information are required per file instead of 3.
2.3 The following points from section 1 seem to be useful to us and are not troublesome to include:-
1,2,5 (we already have this); 6 (maybe); 8 we also want to detect a stop flag).
2.4The problem of replacing items in the middle of a display file without turning off the VT15 and without corrupting the display file was not cleared up in SPROGS 15. It seems that the possible display items must be classified by number. A routine, which appends an item to a file, will assign to CNAME an address and class number. In writing routines which REPLACE other items, we have a choice of policy. In choice 1, no item can replace another of a different class. In choice 2, certain replacements will be regarded as potentially corrupting and will not be carried out until the display processor has reached the beginning of the main file. This can be detected by the display sequence:-
DJMS .+1
0
further display orders
.............
The system will detect when the entry point contains non-zero. We are in effect forcing the program to idle until it is known that the display file can be safely updated.
2.5 In discussion at the meeting following the issue of SPROGS 15, the following changes were made:-
(a) PRAMTR as replaced by one routine name for each possible feature (for instance BRITE, BLINK, LTPEN etc).
(b) GRAPH will only ever produce one display order.
(c) CALL was renamed DRAW.
(d) DOT was merged with SETPT to make SETPT analogous to LINE,
2.6 R-type routines at present need to be declared integer or logical, if they are used as functions. If they are not so declared, the compiler makes no complaint if a real is used in a logical or integer context. It is suggested therefore that R-type (REPLACE) routines should begin with I (INSERT).
2.2 A routine SCHOOS (<integer>) will save a reference to the currently chosen file in a location identified by <integer>. A file saved in this way can be re-chosen by RCHOOS (<integer>). This will be useful for a person writing a routine which constructs a new display file and before exit reselects the previously selected display file. It will also be useful in referring to one display file from more than one subroutine. The possibility of 16 stored references should be sufficient.
Graphic 15 programming manual (the DEC manual on VTPRIM)
SPROGS paper 15: A new basic graphics package for the PDP15
Graphic 15 - The UMASS version by Lasse Leiro, University of Massachusetts (a manual - I have a copy)
Improved routines for the PDP 15/VT15 by Leiro and Taylor (proceedings of DECUS, May 1972) (copy obtainable from me).