It was decided that the proposals for more equipment on the PDP15 should be presented at the next Atlas Committee meeting. JRG will prepare the case for 32K extra core and two more disc surfaces. AHF's paper on the synthesiser will be added.
The BSI link between the PDP15 and 19O6A now works. GAE will shortly produce a paper outlining his plans for the software to drive the link, emphasising how this will appear to the user.
GAE has seen a manual describing the new DEC operating system which will allow two users to access the PDP15 together. This system has not yet appeared in this country and is unbundled. From the limited information available, it seems that there are a considerable number of facilities available under DOS which are not available under RSX. Also there may have to be a considerable rewrite of user software. GAE will try to get DEC to give a formal presentation of the software so that more details can be obtained.
FRAH stated that, at RHEL, it had been found advantageous to install a bleeper on the DMAC so that there was an audible signal every time a fresh coordinate was output. He will obtain more details of the cost and ease of the mod.
DGH will discover more details about this contract, in particular the time of reaction to an on-call request, and whether the VT15 is still under warranty.
GAE has arranged with PB to prepare some instructions and an annotated diagram prior to the User Services Group taking over responsibility for the cleaning of the PDP15 tape deck (SPROGS Technical Paper 3).
The following ideas have been put forward:
The suggestion involves adding an extra parameter to line drawing to include text. The text would then be printed along the line specified by the other parameters.
It was felt that this was really a special case of region rotation.
Instead of using RGPRM to specify individual visibility settings (MI, MO, see manual), there could be a 'language' to specify visibility relationships between regions,
eg Lines in R1 invisible in R2, visible in R3; lines in R2 invisible in R1 and R3. Such a language could be provided at the pre-processor stage.
Instead of defining regions, etc, it would be possible to think in film-maker's terms, eg
eg CAMERA (I) aim camera at cell I
CENTRE (X, Y) centre it
PAN (TH,NF,M, F) pan camera in direction TH for NF frames,
M and F define motion.
This method of approach could be translated into the basic regions, etc, used by SPROGS. Hence, high level routines could be written to perform this.
It would be possible to treat an SD4020 tape as input to SPROGS, with the commands being converted back to SPROGS file form. Then tapes prepared on other computers could be modified.
There should be a diagnostic message every time a blank frame is output.
There is no point in plotting anything on any device when only X,Y co-ordinates are altered. Hence SETXY will not need to perform any reduction through regions.
The GROATS hardware character number system has been adopted, with the re-ordering of some Greek letters.
There was considerable discussion as to how colour should be implemented on the SD4020. Eventually it was decided that only one tape should be used. Thus a user wishing to make use of the colour facility would, after defining his sequence setting local colour variables, call the sequence three times, changing the global colour setting each time. WDS was in favour of a more sophisticated system which would output to, possibly, three separate tapes at one go. However, there are problems concerned with the mounting and running of these extra tapes. He also suggested that colour could be defined by specifying the three primaries and three intensity levels. This would allow a 'colour chart' to be prepared where one colour number specified one shade, which would be translated into the correct primary mix. Special facilities would be required to specify a total black and white output. It was felt that such a scheme could be implemented at the pre-processor level.
RET presented his proposals for implementing STDF and FIDF. The default global priority set must be high so that all calls are stored unless otherwise stated. The routines stored would be placed in the file store area, with space for the largest possible header. The file would be stored in normal mode initially. A record would be kept of
(a) maximum size of routine number
(b) maximum size of PRMINF
(c) whether any PRMINF was non-zero.
On executing FIDF, the user's mode requirements would be considered. Modes , 16 and 32 would only be honoured if the file had been found to obey the rules. Modes 2, 4 and 8 would be obeyed anyway, the specified parameters being translated without any check. The file would then be re-written, overwriting the existing form (all mode settings reduce record size). If the file store overflows, it will be extended (using GIVE).
Initially, however, only normal mode will be considered.
Some alteration to the file types was proposed. ABS/REL is really only another form of type, so a new type for TODXY, etc, will be defined. Also a new type for files consisting solely of NULL commands will be added.
An extra word in each display name table will specify to which file type that display routine gives rise.
It was pointed out that the PDP15 system may require more information about a file, eg whether the first order was a REGION call. Extra header entries could be made at a later date if necessary.
There was some doubt as to how error messages might be transmitted from 1906A programs to the PDP15. It should be possible to list the error file over the BSI if the PDP15 is selected (?using switch word). GEORGE error messages should also be written to a print file.
WDS and JRG are writing a control system which can be driven by SPROGS commands entered at the keyboard. Some means must be found, however, whereby the spark pen and light pen can be used, since the basic SPROGS system has no means of accessing strange input devices.