The Atlas Computer Laboratory became part of the Rutherford Laboratory on September 1 1975. This progress report was, therefore, from the Basic Software Group of the Atlas Computing Division of the Rutherford Laboratory.
Two sandwich students, Ahcene Idris-Bey and Madhu Kashap, left the Group during the quarter to return to college. They have been replaced by Tim Peart (FR80 Project Branch) and Martin Evans (Communications and Systems Branch).
Irene Buchanan arrived on 28 July and Dale Sutcliffe on 30 September, both to take up permanent posts, While at the end of September John Rushby left to take up a lecturing post at the University of Manchester and Wade Shaw left to return to the USA.
The current Group structure is:
A number of projects have been reaching some form of conclusion. This will allow some redeployment of effort on the proposed Engineering Board interactive facility towards the end of the year should this materialise. In particular the TASK and NUTS projects need little further work, documentation and tidying up are the main directions of effort. The development of GEORGE is now less necessary. The vast majority of enhancements thought necessary are now complete moreover many of them have been adopted by ICL thus reducing maintenance effort. However further developments are certainly useful but not urgent, and will proceed at a reduced level if the interactive machine appears.
Current GEORGE Mark 8.32 is in use and will be developed by ICL through 8.40, 8.50 to 8.60, which should be the final version and should appear towards the middle or end of 1976. It is important to adopt each of the versions as they appear to ensure ICL support and to improve performance. With the Mark 8 series, moving to new versions is proving fairly easy and no longer requires the rewriting and long testing that typified earlier marks.
Mends which had been awaiting a stable 8.22 (see last progress report) were finally implemented. The most annoying bug which caused the date to be occasionally overwritten was traced to a combination of a bug in the error path of our GIVE6 and a particular use of it by GERONIMO.
The most common ICL software break Geoerr: QUOTA has still not entirely disappeared (nor from 8.32), despite a GEORGE mend and Exec mend. A diagnostic to trap it is awaited from ICL. The last month of 8.22 gave an average of two software breaks per week.
There were no major problems implementing 8.32 but a host of minor ones, mostly arising from ICL bugs or changes in interface. The worst area, where nothing worked at all, was block reads in filehandlers. With compatible jobwells, the transition from 8.22 was very smooth. The software break rate rose considerably at first, mainly due to repeated occurrence of certain bugs. It is hoped to achieve the performance of 8.22 by the beginning of November, and continue to improve from there.
Unfortunately there has been no improvement in hardware reliability.
The following enhancements have now been implemented in Mark 8.32:
Amendments were made for the 8.32 change of interface. Other changes have been made at the request of Operations (LONGJOBZTIME parameter, and never more than two jobs under same username started, unless instructed otherwise). It is also now possible to EXPRESS MOP jobs which are waiting to log in. Thus there is now the possibility of HLS always starting certain categories of MOP user if such a facility is required.
An investigation using the ICL DATAPASS system was begun in 8.22 and will continue when there is a stable 8.32. Only the snapshot facility which monitors use of system resources has been tried. There is another facility in the package which monitors time spent in various parts of GEORGE, but an Executive mend, still awaited, is required for this.
A technical notice on the core unjammer algorithm was produced and then part of the algorithm was considerably simplified (run only on 8.22 as yet). A fixed chapter quota was used, and chapters were only thrown out off the end of the chain (ie least recently used). DATAPASS then showed that with 15 MOP jobs in prime shift, core unjammer was coming in no more than twice a minute. The MOP limit could thus probably be raised without much effect on response. However for most of prime shift, the system is processor bound, so background throughput would probably suffer from any increase in activity.
One long period of poor performance, particularly MOP response, was finally traced to a hardware fault whereby the end of seek interrupt from the EDS 30 to the disc controller was not being picked up. Reasonably enough, the engineers were not easily convinced that generally slow running of the system could be attributed to hardware. The performance lists showed that mean queue lengths on one particular disc were much greater than normal.
A mystery which has always surrounded the performance of the PDP15/1906A interface has been removed. The collapse of the 1906A performance when the engineer's BSI test program is run is simply due to a very high Executive processor overhead in servicing the PERIs (the test program issues large numbers of very short transfers), and a brief examination of Executive confirmed that these could well be about 1 msec overhead per transfer. Obviously buffers used in transfers should be as large as possible. There were also no problems in running the BSI handler at a priority higher than GEORGE. In fact the only factor preventing very high rates of data transfer seems to be the interruption of the program calculating the data, by any GEORGE activity.
With the impending demise of the SD4020 it was necessary to update and correct the graphical performance depiction program that had been running in weekly production for some time. It has been converted to use the FR80 {via SPROGS) on manyup hardcopy, with some minor graphical format changes but otherwise, so far, retaining features of the original output. Further work on this program is planned for the future, but effort on it has temporarily stopped whilst the BSI evaluation is in progress.
The final work in implementing the new accounting programs and database structure to deal with the 3-level urgency system was completed early in this period, bringing to an end the planned development of this system. Its working was carefully monitored for a few weeks to establish correct functioning, and a new database utility program was produced to enable operational production resetting of database periodic accounting locations. When these tasks had proved the system to be routinely usable, the accounting and budgeting system was formally handed over to Operations Branch for production running. Only minor systems maintenance effort has been needed on it since then.
The Accounting and Database Working Group continued to meet for a few times early in this period, mainly to review the working of urgency budgeting, to tidy up past database utilities and documentation and to consider further database application enhancements. Eventually the group decided that its main purposes had been achieved and that it was therefore appropriate to disband until/unless it was called on in the future. Any further documentation that may be necessary will continue to appear under the heading of working group papers.
An accounting summary program - a single page listing all salient features produced at weekly accounting - was produced. Information about the amount of time used during the week at the various priority levels is included in the output together with the amounts of time allocated at these levels. A breakdown by status is given of time used and allocated together with one by the amount of time used by users. Also included is a list of the weeks and years top six users.
The journal analysis program JOBS has been amended. It now details jobs finished (rather than jobs started) within the period, in order to coincide with period accounting. A listing of total jobtime used at each RJE site is also produced.
During this period the last scheduled enhancements to TASK have been implemented and many loose ends tidied up. This resulted in version 49 which is documented in :NEWS.TASK.
Efforts to prevent jobs failing JOBTIME EXCEEDED (scheduled in the last QPR) resulted in a rethink of the entire time control of a job and, in conjunction with Resource Management Branch, a suitable scheme was devised. Thanks are due for their valuable assistance.
The SPROGSF and SMOG graphics systems were successfully incorporated into TASK thus making the separate macros for these systems redundant. This enhancement necessitated the implementation of the ENP parameter to add parameters to the ENTER command of a binary program.
A lot of work has also been done to improve TASK's handling of large binary programs (>98K). TASK will now attempt to carry on with the loading and running of a binary program when the virtual core requested is greater than that given via the MZ parameter or default. Hence runs which only use a subset of a large program's array space need only to specify the virtual core required and TASK will attempt a run in that space. As the requested and allocated core are indicated by TASK in such cases, should the program require more core then a user is better able to estimate the increase required.
The major effort of this period has been directed towards documentation. The new TASK manual is almost written and full system documentation has been finished. Completion of the latter and the successful introduction of version 49 allowed TASK to be released to Brunswick University, W Germany.
In addition to keeping in step with the JOBTIME EXCEEDED enhancements to TASK, the NUTS kernel has also acquired paper tape handling facilities and can thus do conversions between ALLCHAR, NORMAL and GRAPHIC files. New specifiers are ABSOLUTE which corrects for ICL 7-track magnetic tape bit inversion on both reading and writing tapes, and TO which complements the FROM and BLOCKS/BUCKETS/RECORDS parameters. NUTS also writes statistics to :SYSTEM.JOURNAL.
A new utility SORT is currently being evaluated. It sorts basic peripheral files into ICL internal character code sequence on a series of up to ten keys. Sorting can be localised to one or more areas of a file using specifiers FROM, TO and RECORDS the former being allowed in all formats defined by the GEORGE LISTFILE command except character strings within a record. While SORT is intended for alphabetic listings of magnetic tape subfile summaries or LSTR output it can be used on files of up to ten thousand records. Documentation will be appearing shortly in :NEWS.NUTS.DOC.
After a lengthy design exercise, the design for a new utility to copy subfiles from tape to tape has been agreed (TN 118) together with a design for changes to the operation of subfile generation numbers with the COPYIN and COPYOUT utilities. Implementation of these is now in hand.
A utility has been written to copy Executive post mortems from disc file to magnetic tape. The utility has been handed to Operations Branch for final testing and incorporation into the system.
The advent of GEORGE Mk 8.32 required all system macros to be checked to see that parameters for ENTER, OBEY and similar commands were enclosed in brackets preceded by PARAM.
The CORRECT editing macro also required changes to overcome a new 8.32 feature which erased output workfiles when a Q editing instruction was given.
The system :MANAGER.STARTER to run work under :MANAGER has been superseded by new techniques and was thus withdrawn.
Some diagnostic work done this quarter has revealed the cause of two bugs which have been occurring at rare intervals for quite some time. Both are now cured, and there are now no outstanding bugs.
A scheme for automatic generation of the Tape-to-Tape Processor (TTTP) driving parameters is well in hand. A draft specification has been produced and issued as TN 117. This specification is based upon the Algorithm for Tape-to-Tape Processing issued as TN 112.
The system decides upon the best runs of the TTTP and outputs the information for the operators and the necessary driving parameters to filestore. The operators then have the option to run TTTP manually or allow the control system to issue the TTTP runs automatically. Live running of the system is now in progress although the automatic issuing of TTTP runs has yet to be implemented.
This was briefly examined and a minute test program written. It was ascertained that it would be quite possible, without using fully interactive facilities, to develop a system to use DRIVER. This examination was made to forestall any request by a user for such facilities.
An investigation into the possibilities of mounting a document production system has commenced. It is thought that the KDF9 Text Output System written by NPL and a program written by D C Toll offer the best command structures for further development. The latter produces text documents and draws flowcharts on the FR80 and was originally written to document the 7903 Emulator in the 4080. It is however sufficiently flexible to be of wide application. The problems of document production were discussed at a recent group talk, and firm proposals for a document production system are to be worked out.
The microfiche production system is now capable of outputting erased filestore or workfiles. In addition it is now possible to list files context to context as long as only the initial characters of a record are checked. The final enhancement of the system will be the listing of context to context where the context has the initial spaces suppressed or the context is anywhere in the file.
The secretaryship of this Group has consumed a considerable amount of time. The final report has now been produced and no further effort is envisaged.
A demonstration of interactive computing was mounted by P E Bryant and D C Toll. A FORTRAN program supplied by J E Crow was demonstrated to illustrate the difference between batch job entry from a terminal and direct interaction with a compiler.
The GEC 4080 front end system is now a major project. Progress has been less than expected and the resignation of M D Fowler will further reduce effort. The code required in the 360/195 is now scheduled for release at the end of the year and the delays are therefore less serious as the timescales of C and A Division, Daresbury and Atlas are now roughly in step.
The interface to the 1906A is working although one or two faults are still outstanding but the interface has been used for passing files between the machines. The design of the Mark 2 version will now include the full facilities of the ICL interface mainly so that it can be used to connect a GEC 4080 to an ICL 2900. The Mark 2 interface will be on two 4080 boards.
The reliability of the 4080 has been marred by the disc which has had three major failures each resulting in a few days downtime. This downtime averages at about one day a week which is not acceptable. In each case GEC have called in DRICO who have been less than ready to turn out in a reasonable time. Pressure is being put on GEC to improve the situation. Should this problem persist in real use the image of the host machine will be poor. The rest of the machine's performance has been good. There is now on-site maintenance of the 4080s which will undoubtedly pay dividends in the future.
The 96 character chain and CRC board due in August have still not been delivered and again GEC have been made aware of Atlas displeasure. The lack of the chain is particularly unfortunate with M D Fowler's resignation as there may possibly be modifications to the 7020 emulator required.
Some development of DOS has been performed, the major change being swapping the Teletype and the VDU, so that the much faster VDU (4800 baud) is now the main console for the system. This provides a problem, in that the VDU normally supplies lower case letters (unless the shift key is held down, which is frequently inconvenient), and GEC software only accepts upper case letters. At the moment, the driver for the VDU has to be patched dynamically after every loading of the system (IPL), so that lower case letters are converted to upper case. It is hoped to cure this problem shortly, by including a new driver in the IPL file.
The process PRIN has been enhanced to use a file corresponding in function to the GEORGE file :SYSTEM.OUTPUT. Entries to this file are made by a process which is kept in .P.SPUL. Process SPUL must be run in a utility shell, and will read a record from Stream 1, inserting it in the file.
Various facilities have been added to the process MAC, notably the conditionals:
Coding of this project is proceeding as fast as possible, and should be completed by the end of this year; it then only remains to make it work!
Work was started this quarter on a process to communicate with HASP workstations via a Binary Synchronous line driver. The project has proved bigger than was anticipated, but a large quantity of code has been produced, and there is hope of having sufficient code written to begin testing this year.
The 4080 HASP Handler process has undergone a major redesign, due to a redefinition of the Handler-Buffer Assembler interface. This has lead to a simplification of the Handler code.
Some experiments have been performed between the 4080 and 2050, and the 4080 and 360/195 to determine the rules for retransmissions after error conditions. This has shown a lack of symmetry between a HASP RJE station and a HASP Host machine.
This new information has been encoded into the Handler. Testing the software has been accomplished by connecting both the 2050 and the 360/195 to Handlers in the 4080. The two Handler processes are connected via two dummy Buffer Assemblers and a dummy Kernel. In this way the 2050 has been connected to the 360/195 and run successfully as an RJE.
The Handler is now being documented and the last few bugs are being removed.
The experimental EPSS driver is now complete and works well except that it will impose a heavy load on the processor but not as great as a binary synchronous interface at the same speed (2400 bits/sec). It is hoped to test the driver in conjunction with Harwell to enable more rigorous tests to be applied prior to tests with the GPO. The next step is to implement the next level of protocol which involves call set up procedures and network information packets. This still leaves the large area of bridging and high level protocols which in any case need some agreements with C and A Division and other EPSS participants. It is unlikely that Atlas will be a vigorous participant when the exchange opens.
Some effort has been expended in investigating the use of micro processors in interfaces. N M Parker has built an interface to drive, in conjunction with a Motorola M6800 Chip, two mini magnetic tape decks on the 4080. It is hoped to obtain and mount a cross assembler for the chip on the 1906A to ease development work.
Some modifications were made to the hardware of the FR80 in August to improve the stability of the beam positioning immediately after drawing had commenced on a frame. This had some effect on the image sizes which needed to be remeasured. The exact cine and abut images are needed by the packages and some of the users.
Some effort was put into getting a standardised method of measuring and presenting results so that any future modifications to the FR80 affecting image size can now refer to the agreed standard.
Whilst predictable and reproducible results can be obtained with primary and secondary colours, the production of the more subtle tertiaries and less saturated hues remains a problem. Consultation with the film supplier indicated that we may be exceeding some upper limit of time-in-exposure. Experiments with an externally processed film stock (Eastmancolor) necessitating the generation of rigid controls on internally processed film stock (Ektrachrome HS) are under way. The coding for the subtler colours is completed but in view of the poor reproducibility of tertiary colours, it has not been included in the graphics packages.
Some initial tests have been carried out with external processing and copying of colour films produced on the FR80. Currently, most of the colour output is produced using multiple hits and a 8-millisecond vector speed. Using a 4-millisecond vector speed and forced processing, the film seems to give as good, if not better, results. This could be a way of saving time on the FR80. Unfortunately, due to FR80 software not being able to cope with colour and double buffering, no time saving is currently experienced. However, once DRIVER is working, this may well be the most economical method of producing colour output.
The colour tests done so far have been marred on almost every occasion by relative movements of the different colours in parts of the frame. The reason for this is as yet unknown. Either the filters are not at the same angle each time they are entered or there could be movement of the filter itself within the holder. Neither seems very likely to explain the size of movement experienced.
On one or two occasions, objectionable overall sideways movement of the image (weave) when projected has possibly pointed at incorrect threading of the film through the camera. Again, no firm conclusions have been reached so far.
The simplest method of producing grey-level output is to plot points at different intensity levels throughout the frame. The major objection to this is the high cost in FR80 time. The beam has to be repositioned after each point.
The fast character printing option on the FR80 suggests that this could be used for the production of high-quality half-tone prints. Defining a suitable character set is the main problem. To this end a set of routines is being completed for the generation of:
This package would seem to be in demand among our medical, chemical, astronomical and engineering users. The first reproducible tertiary colour system will probably use this method since it is fast and the well-established techniques of half-tone colour printing should be easily adopted.
There is still a need for a linear set of intensity levels to be abstracted from the 256 level set. This has been delayed due to noticeable variation in density, probably due to both chemical processing defects and pressure marks arising from the rollers in the processor.
Work from the 1906A has been building up gradually throughout the quarter. No real problems with the FR80 itself have been encountered, although a number of minor ones have resulted in a loss of valuable time.
The 5010 film processor has had some trunking installed to extract heat from the drying box.
The Oscillogram processor for hardcopy is to be refurbished in the New Year.
Work on the FR80 basic software has been hit by the loss of both Wade Shaw and John Rushby during the quarter. Eric Thomas has taken over direct charge of the software maintenance on the FR80 while Rob Witty is responsible for the DRIVER program.
Coding of the FR80 Logging System, SYSLOG, was finished by the end of September, since which time it has been included with the production software for long-term testing. So far, no problems have arisen. The system can now collect logging information from each job and, at suitable intervals, dump the information to tape. This will eventually mean that the operators will no longer have to do the time-consuming punching of logging information on to cards for accounting purposes.
A 1906A program has been written to analyse the data on the log dump tape and produce a lineprinter listing, together with the necessary cards for the accounting program. At the same time, the raw data from tape is saved in a file, from which repeat runs can be made. Considerable data checking is incorporated to force only good records to be accepted. It is necessary, therefore, to check the lineprinter output carefully for error indications.
It is hoped to install the system permanently in the next quarter. The only modification to be made as a result of the preliminary tests is to differentiate between spool jobs and tape jobs so that a different rate for tape mounting can be used in the two instances.
New software to ease current maintenance problems and provide new facilities is being designed. Initially, a subset of the existing III Displayer's drawing commands will be implemented. The terms of reference and subset definition were issued as FR80 Discussion Paper 15. The new software system is called FR80 DRIVER.
An examination of graphical jobs being processed on the FR80 was performed by modifying FRVIEW to record the frequency and type of all the drawing orders in the jobs. FR80 Technical Paper 11 is the users' guide to FRVIEW. Several small programs have been produced to time and check various FR80 hardware features.
Encouraging experience with structured programming during the development of SYSLOG has meant that DRIVER will be built with similar techniques. To relieve the tedium of hand-compiling high level control constructs (the FR80 only has an assembler) a simple language has been created from whose programs a TREE-META-produced preprocessor outputs FR80 Assembler. This system runs on the 1906A and is operational. The cross-compilation system has a secondary advantage in that program input, editing and compilation can take place in the 1906A without affecting FR80 production turnround. File interchange programs have been written to enable source files to be moved both ways around the circle of PDP15, FR80, 1906A.
All program listings and documentation for DRIVER will be developed on microfiche. This will allow a project history to be built up which is physically manageable. To this end some work has gone into FILMER, a III program to list FR80 source files to fiche. D C Toll's package will be used to generate documentation.
The overall layout and composition of the DRIVER system has been determined at the top level. No doubt snags will appear before refinement is complete.
Thanks are due to those people who have put forward their ideas on FR80 developments. All future contributions still gratefully received!
Version 3-AA of III software has been received and a number of modifications made. The current Mark in use is 3.4 which includes:
It is no longer necessary to retain a separate set of displayers for 7- and 9-track tapes. A small modification has enabled the tape type to be preserved between programs.
Changes to the current Displayer should now be few. The only major alterations under consideration are the change to the multiple hits code to speed up the overstriking and the introduction of a monitor command to change vector speed. The last modification would remove the need for a separate Displayer for the hardcopy camera.
The current state of the Print Programs is not so healthy. There are still problems with running both the 1906A and 360 versions. It is hoped that source listings of these can be obtained from III so that the outstanding bugs can be corrected.
A program has been written on the 1906A to create an FR80 Dump Tape from a 1906A source file. The source file can contain a number of FRBO files separated by START directives and headed by a comment line giving filename and date created. Multiple spaces are converted to single tabs.
It is now possible to input and edit FR80 programs on the 1906A and copy them to tape for running on the FR80. Using this program and the Listing Program described in the previous Progress Report, it is now possible to transfer files between the two machines in both directions, a feature essential to the successful construction of DRIVER.
A COPY program has been added to the FR80 Operators' macro on the 1906A. Previously, 9-track tapes could be copied to 9-track using NUTS. However, 7-track tapes, which are odd parity with even-parity filemarks, could only be copied on the PDP15.
This COPY program allows both 7- and 9-track LOADGO FR80 tapes to be copied to either type of tape. This means that not only can suspect tapes be rescued, but continuity of service can be maintained if one of the FR80 tape decks goes down.
The SMOG package has had several additions made to it during this quarter but no major changes. The 3-D routines are now working and have been included. The bug holding up the inclusion of these routines was found to be in the original SPROGS implementation and was not one that had been inserted in the transliteration.
High-level routines have been added to generate FR80 vector family commands and also to allow multiple hits to be specified for both black-and-white and colour recording. This is to avoid having to define overstriking on the 1906A by outputting the same vector several times.
Minor changes have been made as a result of changes in the Displayer format. Also, one of the ICL routines in the FORTRAN error package has had to be modified and included in the SMOG library. Prior to this change, if an error occurred in a program compiled under TRACE0, the job did not terminate correctly. The SMOG macro has now been converted by Graham Robinson to be an integral part of TASK; the parameter SMG is used to indicate a SMOG job.
A binary copy of the SMOG package has been given to Reading University for running on their 1900. Some output has been generated and successfully plotted on the FR80. The immediate outstanding problem concerns the inclusion of the username and jobname for the ID frame and accounting records. Consideration is being given to implementing the 1906A spooling system at Reading in order to minimise the number of tapes being sent to Atlas It is likely that the same system will be used at Oxford University.
Little new work has been done on the spooling system during the quarter. The option which allows 9-track tapes to be generated instead of 7-track has been successfully tested. This is provided as a back-up against the 7-track deck being inoperable. This work had to wait until the main graphics packages were altered to produce Monitor commands that were independent of the type of tape.
One or two minor problems have arisen. One job encountered a temporary hardware error on the disc which was later diagnosed as a faulty disc drive. One other job was found to be corrupting control blocks on the spool. The job in question was run twice before the problem was traced. It was due to attempting to overlay the SMOG initialising routines.
A potential source of problems is that the spool area can only be written to by one job at a time. As the spool can accommodate a large amount of graphical data per job, it is not unusual for a job to control the spool for 15 to 30 minutes (although this does not happen often in prime shift). Any other job trying to access the spool has to wait while occupying a core image. An analysis of this situation is being carried out using System Journal and the logging file generated by the spool system. Some thought has already gone into possible solutions if this turns out to be a real problem.
The basic system has been stable during this period apart from changes to the data format needed to bring the system into line with the proposed implementation of DRIVER (the Atlas version of the FR80 Displayer, which initially will incorporate a subset of the III data format). The regeneration system has been altered to produce compiled listings on microfiche, thus saving a considerable amount of little-used lineprinter output. The SD4020 version of SPROGS has been withdrawn.
A number of new high-level routines have been defined as a result of discussions with Colin Emmett of the Royal College of Art who is generating some animation sequences for a film sponsored by the Arts Council. Routines for holding a picture and in-betweening from one picture to another have now been implemented. It has been necessary to define a special type of index variable which is local to the film sequence in which it is being used. These index variables will be useful in a number of applications. They make the user program easier and quicker to write and understand. Routines to deal with scanned areas are being implemented.
SMOG has been successfully incorporated into the XRAY links ORTEP, CONTRS and PROJCT. The first of these is so large that a special version containing just ORTEP and the nucleus has been constructed. The other two links are included in a system containing the more generally used XRAY links.
The only alteration to SMOG was the replacement of one routine which provided a buffer rather than requesting one (XRAY is a dense overlaid program). The main problem encountered was the large size of Lower Data, in particular the non-overlaid section of Lower Variable. The cause of this was the use of nested DO loops in a number of the links. Replacing the outer DO loop by a corresponding IF saved a considerable amount of store. The size of a given routine was determined from the semicompiled (this can be written to a *CP file and listed).
Some slight alterations in the steering parameters were required and a new CAMERA card used to select the desired output device. The TITLE card has been altered to put the title on to fiche.
The Utah software for drawing surfaces as line drawings or grey-level shaded output has been implemented and will be made available to users in the near future. It contains a number of high-level routines for defining simple surfaces and multi-valued ones. In addition, low level routines allow pictures to be constructed from a number of 3-dimensional objects made up of polygonal faces.
A number of features will not be documented - these may be made available later if there is a likely demand.
The SD4020 was withdrawn from service for 1906A users on 1 September. The publicity encouraging users to change to the FR80 had been very successful and very few problems were encountered. The user with the greatest problem is the Naval Construction Research Establishment. They use SCFOR and considerable help has been given to them to convert their programs so that they will run on the FR80.
Users of GROATS and SPROGS have moved to the FR80 with very few problems.
A large blocked font for film titles has been designed for the upper case alphabet. This will be extended if there is a demand.
An attempt is being made to improve the high-level graphics facilities provided on the 1906A. Attention is being paid to various means of displaying data which are samples of a function of two variables, z=f(x,y). These include contouring, projections of the surface f(x,y) and projections of tower-blocks representing the function f(x,y). The strategy at the moment is to obtain and adapt algorithms from elsewhere or already existing on the 1906A; these can be used to respond to individual user demands and anticipate future needs.
Surface projection routines are being obtained from Dr Barlow of HEP Division and Dr Rhind of Durham University. Both of these will have to be converted to run on the 1906A and to use SMOG.
During the last month a review of the various contouring algorithms available at Atlas (namely those used by SMOG/SPROGS, SCFOR/SCSIM and the XRAY system), together with a number of others (those of Heap (NPL), Barlow (Rutherford Laboratory) and Powell (AERE) has been commenced. Once this has been completed, it is intended to design and implement a selection of algorithms to fulfil the various needs of users. This is felt to be preferable to implementing a slower multi-purpose algorithm. In addition, it is hoped to examine and implement further algorithms for tasks not covered by any of the above.
So far, a modified version of the SMOG/SPROGS algorithm has been prepared to accept larger grids. Any suggestions about user contouring requirements will be gratefully received.
After a somewhat protracted initiation period (due mainly to a chronic shortage of staff at the Rutherford Laboratory), the routines required to employ HASP to handle spooled graphics data were written and tested. The key output routine, SP$PUT (incorporated in the lowest level of SMOG) now writes successfully to HASP spool and to private disc data sets, controlled by JCL. Writing to 7- or 9-track standard IBM-labelled tapes through SP$PUT should be available by 10 November. Further alterations, if required, should be transparent to users since SP$PUT consists mainly of dynamically loaded code that is not part of a user's load module.
Using a modified version of a key routine (LGJCL) provided by A E Stormer (RL), the despooling system was implemented quite rapidly.
By incorporating features of Chris Osland's tape library maintenance program, the despooler now handles much of the fairly complicated process of keeping track of FR80 9-track tapes. Although some tidying up of the program needs to be done, the remaining problems are mainly logistic (synchronising the despooling process with courier times and FR80 camera schedules).
A number of problems remain to be ironed out on the 360/]95 systems side. These include:
Items (2) and (3) should be relatively easy to cure; item (1) requires modifications to HASP.
The possibility of using the spooling system to handle print program data is under investigation.
Reaction to the FR80 by RL 360/195 users has been most enthusiastic, especially since spooling has become available (this enables users to produce FR80 graphics in CLASS=X jobs with turnround times of 10 minutes or less for the computing part of the process). Virtually every facility has been tried so that we have been made painfully aware of the few outstanding bugs in the packages. T G Pett's MUGWUMP FR80 package, ELFR80 (replacing HRMUG) is in use, mainly to hardcopy. One or two users who have developed graphics packages and are interfacing them to SMOG have offered them for general use. (These include more sophisticated histogramming routines and various 3-D surface plotters.)
Documentation is in the process of being written. Some has already been circulated by Chris Osland (that required by users, operators and receptionists for handling spooled data). A section for the CIGAR manual that includes FR80 graphics, interactive graphical systems and graphics facilities in ELECTRIC, is in the course of preparation.
Although small modifications have been made to this package from time to time, SMOG has remained essentially the same since the last report. The number of users of the package on the 360/195 has grown steadily and now stands between 30 and 40. Hardcopy has been the most popular medium although many users are also experimenting with microfiche.
Apart from the correction of occasional bugs, the basic package has required little maintenance. The changeover to HASP spool has required changes to the routines, FRIGN, FR80ST, FRINIT and FREND and the revised versions will be made standard on 10 November. The additional subroutines for contouring and drawing histograms have been brought across from the 1906A and, together with the required Assembler routines, are in the process of being checked out. The final changes to SMOG to bring it into line with the revised FR80 order code will be completed in the near future.
Repeated requests have been made for a routine to allow selection of FR80 camera by DD card; the feasibility of this is being studied.
Quite heavy use of this package by several external users has brought to light a number of bugs which were tackled as they were encountered. The dashed-line option has been restored by popular request, heavy plotting points supplied and the facility provided to select the FR80 camera through the JCL EXEC card.
The only complaint from users is that the TSP routine does not position a character in the same place as the old system (ie the specified point defines the bottom left-hand corner of the character and not the centre). SCFOR now works through the spool and will stop calling itself SMOG (in the accounting information) on 10 November.
Implementation of the FR80 version of SPROGS has been delayed due to a number of problems. At the moment, it will not use the spool system correctly due mainly to misalignment of COMMON blocks between the two systems.
VIEW$ has changed little over this quarter. It has been modified to accept both the new and old FR80 orders where these have changed (for example, the second word of the vector family command). Its dependence on STARTJOB and ENDJOB orders has been removed and a bug which caused NOP to give unpredictable results has been cured.
The possibility of allowing VIEW$ to inspect HASP spooled jobs is being investigated; if this facility is included, users may tend to let development output find its way (unnecessarily) to the FR80. It would also mean that HASP would have to compete with VIEW$ users for control of the read/write heads on the spool disc.
SPOOLJOB has been modified to take account of the new FR80 orders. The code has been tidied up in some of the more heavily used areas. Throughout the period, SPOOLJOB has been fairly stable and has required little effort.
Although the FR80 graphics on the 360/195 is not yet available to the general user, many people are using the system on an experimental basis. The number has risen rapidly during the latter part of the period and a significant amount of time is being taken up in support effort. Most users are happy with the new facilities and many are changing from SCFOR to SMOG in order to avail themselves of the greater facilities.
The latest update to DOS was received from DEC and installed on the PDP15 - its version number is V3B. No system errors have been reported. Most of the changes between V3A and V3B were to correct obscure bugs which have not caused Atlas any trouble. However, the EDITOR has been enhanced.
Modifications have been made to PIP to remove the built-in assumption that all files with an extension whose third character is a digit are ASCII files. It is now possible to transfer (T) overlay files built by XCHAIN.
Software for transmitting character information across the link was completed and two internal people have made use of it. The current limited documentation is being enhanced. On the PDP15, a device handler (called BSI) is provided which is compatible with DOS. On the 1906A, a real-time program is provided which can read/write GEORGE files, write workfiles to be output and read/write communication files. Communication between a 1906A program and one on the PDP15 is via communication files. Character conversion is provided so that programs can use FORTRAN-formatted READ/WRITE commands. An additional advantage is that programs can be tested without the link.
Experience and performance measurement have shown that optimisation of link software would be productive in two ways:
The first change has been made and FORTRAN programs on both computers can now use FORMAT statements of the form:
FORMAT (620A1)
A paper describing PIGS was presented at EUROCOMP in September. The system was also demonstrated on the PDP15/76 at the DEC stand in the exhibition. This worked, but not too smoothly. The PDP15 kept crashing in a temperature of 90°F. The PIGS system was cumbersome to use without our fast overlay system.
A PIGS demonstration was developed for the Engineering Board visit. This used some existing routines for displaying 3-D objects with hidden line removal. The purpose was to demonstrate how quickly an interactive program could be developed. As a demonstration of PIGS, it is quite realistic. It does not allow, for instance, lightpen hits on the object itself; PIGS leaves the application package to call an appropriate subroutine.
The 3-D routines themselves are not reliable. The perspective does not look right and, occasionally, a non-hidden line is removed! After experimentation, a square-based pyramid was found to be satisfactory for a demonstration. No further work on these hidden line. routines is planned.
Changes have been made to the PIGS error facility. Although it is possible for both the system and applications programs to generate error messages in a special area of the display, it is easier to use the simple system which just outputs error numbers. The main problem is that the application programmer must arrange to store and index the error messages which is extremely awkward in PDP15 FORTRAN. A number of the commonly occurring error numbers will now cause understandable messages to be displayed.
Following the implementation of the PIGLET simple command parser on the 1906A, a set of subroutines was written which cause a data file consisting of SMOG commands in a PIGLET-compatible format to be interpreted as calls on the appropriate SMOG commands. Although the code for this system has been written, it has not yet been fully tested. It is intended that one use of the system would occur in the processing of data files produced by other programs, eg, the DMAC digitising program on the PDP15.
Of the 64K of core store connected to the PDPI5, only 32K can be accessed in the normal manner under the DOS operating system. Routines have been written in MACR015 which allow this area to be accessed for data storage.
A free storage scheme using FORTRAN subroutines has been altered to provide a mechanism for the allocation of variable sized blocks of upper core. Freed blocks are returned to the free storage ring.
The above routines are more fully documented in Sections 1.7 and 1.8 of the PDP15 Routine Library.
This program is still in the development stage, although quite a lot of progress has been made. The eventual aim is to provide a system which will run under PIGS and which will accept input and editing commands from either the DMAC, the spark pen or the lightpen. At present, the program runs under the simple command parser, PIGLET. Size appears to be the largest obstacle in the way of an easy conversion to PIGS.
Currently, the program allows for the definition of an area on the DMAC table as the drawing region, upon which the user may superimpose the particular coordinate system needed by the application. The drawing region may be at any orientation within the DMAC's digitising area and need not be lined up with that device's own axes.
Using the DMAC cursor and keyboard, single points and chains of connected line segments may be entered into the data structure contained within the program and, at the same time, displayed on the VT04 screen. Simple line editing facilities are provided at this stage to delete the last point, last line segment, or last chain of lines entered.
A windowing facility, with software clipping of lines, is provided for the viewing of the picture in greater detail on the VT04. Editing routines are in the process of being written and tested to allow the user to correct any errors or inaccuracies in the picture.
By interpreting the data structure, a file consisting of SMOG commands may be produced which describe the picture. Any file of SMOG commands may be read and used to construct the data structure and picture displayed on VT04. This data file may be passed to the 1906A using the BSI and interpreted using the DOGS system. Eventually, the picture may be viewed as FR80 output.
Further facilities have been included in the program to produce cine films of molecular structures. These include the ability to display and manipulate independently many molecules, thus allowing one to draw different orientations of the same molecule simultaneously or to illustrate enzyme mechanisms. Commands have also been included to allow one to have full control over the colour of each bond, titles and captions when using the colour cameras on the FR80.
Most of the work in this quarter has involved setting up and testing interactive systems involving the PDP15 and the 1906A. The molecule program on the 1906A was chosen as a suitable example for conversion to an interactive program. Commands are typed on the PDP15 console and the molecule appears on the VT04 screen.
Data structures were defined for communicating between the 1906A and the PDP15. The formal data structure first suggested was found to involve too much data transfer between the two machines and response was bad. It was found necessary to buffer data transfer to minimise the EXECUTIVE overhead on PERls. The subroutine to read data from the 1906A on the PDP15 was originally written in FORTRAN but this was found to be a limiting factor in the response of the system and was thus rewritten in MACRO with a consequent 10-fold increase in speed.
Work is in progress to convert the molecule program to transfer binary information as opposed to ASCII characters to the PDP15. This should minimise computation as no number to string conversion is required on either machine, nor any code conversion from internal code on the 1906A to 5/7 ASCII on the PDP15.
The synthesizer interface developed an intermittent fault early in this quarter. This was eventually found to be due to a loose circuit board. Work is now progressing on a software package to simplify the generation of commands for the synthesizer. This is a peculiar realtime package in that calculations show that the computer is not fast enough to deal with the worst case situations. As a result, the FORTRAN I/O has been replaced with fast double-buffered macro routines to enable large amounts of data generated to be processed. A set of headphones has been purchased for use with the synthesizer so the 1906A operators should not be disturbed by strange noises any longer.
To facilitate fast presentation of data points (bubble coordinates in R3) in a pseudo-three-dimensional display, it was necessary to compress a sequence of orthogonal transformations and a projection into its most compact form.
An experimental projection was used in which two parameters were fixed after a period of aesthetic appraisal. Tracker-ball transducers now feed either translational or rotational information into the system (a complete description is given in the Proceedings of the Electronic Displays 75 Conference, Session 2, pages 23-50). Translation and rotation are effected in the bubble-coordinate domain and projection on to the CRT face follows. The resultant transformation, Φ: R3 -> R2 , (ie X = P * R * (I + T) * x, x in R3, X in R2) is a six-element matrix which has been realised in hard-wired arithmetic. The necessary six parameters Tx,Ty,Tz, θ, φ, ψ for the mapping are present continuously as integrated (summed) tracker-ball displacements. The transformation is fast - thousands of triples can be processed in 5 msecs, leaving ample time in each 20 msec refresh period to deal with lightpen input, etc. (This last dispenses with the need for hidden line removal since points can be immediately separated by translation (zoom) and rotation, then individually addressed by the lightpen - their initial coordinates are thus uniquely recoverable.)
The PAG equipment, which records and replays soundtracks on sprocketed 16mm magnetic film has been installed and came in very useful for the Engineering Board visit. It enabled the separate picture and sound films to be run in synchronisation, as a combined print was not available in time. A number of connections are being assembled so that various recording and replay paths may be used with the different equipment available.
An extensive amount of time was spent by a large proportion of the group in organising the Engineering Board Visit. The main graphics demonstrations were the PDP15 being used interactively, the FR80 and spooled output to the Tektronix.
Two demonstrations were set up to run under PIGS and the molecule display program was enhanced so that a better read time response was obtained from the 1906A. As a back-up to these demonstrations, the Imperial College MINNIE system for design and analysis of electrical circuits was mounted and also a GIFTS package which does Finite Element analyses was obtained from the University of Arizona. The latter did not arrive in time but work is being carried out to see how useful it will be.
Several files containing graphics data were set up in the spool for the Tektronix display. In order to get suitable graphics, not too long to list and reasonably technical, the spool was monitored for two weeks; the first few frames of jobs which looked interesting were kept in files. A final selection was made just before the visit.
A selection of FR80 output was produced for hand-out purposes and a representation set was made up into a display board. Additional display boards were made which described the FR80 facilities and the PDP15-1906A connection.
PIGS - A command system for interactive graphics (EUROCOMP 75 Proceedings), J R Gallop
Computer Animation used as a tool in teaching computer science (The Best Computer Papers of 1975, ed Auerbach), F R A Hopgood
Visit to USA, R Brandwood
