1. We have decided to ask for the following additions to the PDP15.
(a) 16K core store from DEC, £12,221;
(b) 260K disc surface, £4,500;
JRG and WDS will make the technical case for these.
(c) Sound box, £350 + interface;
AHF will make the technical case and get a quote from RHEL for the interface.
2. The PDP15 will be maintained regularly every 3 months, starting May 1972. The tape decks appear to require more frequent maintenance than that provided at the moment. GAE will write a cleaning schedule which can be used by members of Operations Section.
3. BSI is still giving trouble when data is being transferred from PDP15 to 1906A. The transfer from 1906A to PDP15 works. More detail about Executive is required.
4. SPROGS SYSTEM
4.1 Card copies of routines will be kept. These need not necessarily be kept continually up to date, but will be a useful back-up in case of catastrophe.
4.2 The use of the 'bracketing' routines BEGINS, ENDS will be considered as creating a temporary file of the intervening routine calls and inserting a DRAW in the main body.
4.3 It is possible that a more general system of region numbering may be required later.
4.4 SD4020 microfilm and SD4020 hardcopy will be considered as separate devices. Thus a request for output to both devices will involve duplication of orders on the 4020 tape.
4.5 A Display Routine name table (NMDSTB) has been created, separate from NAMETB. Thus NAMETB only needs 3 words per entry, display routine numbers are the position of the appropriate entry in NMDSTB, and NMDSTB requires to words per entry.
4.6 Initially, the string table, ISTBLS, will be accessed by word, since only routine and file names are implemented, each of which is two words long. Later, string counts and character-by-character access will be required to accommodate TEXT.
4.7 Basic output routines for each device will perform modification on the coordinates. Thus separate regions will be needed for each output device. This will allow the easy inclusion of devices which have rectangular plotting areas, and will also allow a user to work within a part of the plotting area without the need to perform an extra region reduction. However, it does give the user scope to define ridiculous regions and to produce strange effects. Some useful diagnostic aids will be needed; eg a monitor print of all points outside the frame, together with a back trace showing what regions have been traversed.
4.9 Line Printer Graphical output will be provided on a 120 x 120 grid. It will, of necessity, be crude. * will be used as a plotting character, changed to + if overstruck.
4.9 Region definition in terms of the current region will be allowed.
4.10 SPROCS paper 14 details a system to generalise DOTTED. However, there are considerable problems. If more than one output device is specified, 'raster length' in general is undefined (being particular to a device). Also the calculation of 'raster length' in a rotated region requires the use of cos and sin theta. General discussions on all these points seem to suggest that, after all, it is not sensible to apply properties such as STROKE, DOTTED etc until the lowest level. In this case, the idea specified in Note 2 (the saving of the original XY start and end coordinates with each segment) seems to be necessary. In this way, the correct portion of the stroke, relative to the original line, can be used for the segment. Does this mean that region rotation is not required?
4.11 Some form of monitor trace may be useful. Depending on a Global switch, each routine could output details of itself as it is obeyed to a monitor file.
5. It will be necessary to provide some form of picture file editing so that corrections can be made. There are two distinct problems; editing in batch mode and editing interactively. The following are some possible ideas.
5.1 Batch editing
As picture files are stored as a series of records consisting of routine names and arguments, it should be possible to provide a simple line by line editing scheme. The source file will be sequentially edited into a new file, either with a distinct name, or with the same name and different numbers. Renaming of files should also be allowed.
Users will be able to get a listing of a file, change and insert lines.
5.2 Interactive editing
A PDP15 user will want to interactively edit a picture, using a light pen etc. It would be possible to send just a modified picture file across from the 1906A, when displaying a picture, containing routine numbers and actual arguments in PDP15 raster coordinates. However, it will be quicker if the 1906A also provides the basic display code.
Some way must be found of interpreting the light pen hit, say, as a pointer to the Command line in the original picture file. It should be possible to intersperse the file with the display code, so that the file can be temporarily stored on disc with pointers to the assembled display code. A light pen hit in the display code can then be linked to the source line. Actual editing will be done by the PDP15 user using batch edit commands. He will have to know the file-sub file structure of his picture, (a command to print the original source file should be provided) and will use this knowledge to perform the editing he requires. For example, file A might contain references to files B, C and D. A given frame may display A. If the user wishes to change the effect of file C in this picture, he can edit C into C', and then edit A to refer to C'.
