On September 1 1975, the Rutherford Laboratory took over the running of the Atlas Computer Laboratory with the Atlas Computing Division becoming part of the Rutherford Laboratory. Dr Manning, Deputy Director of the Rutherford Laboratory, was in charge of the Division from September 1, 1975 on an interim basis. At the end of February 1976, it was announced that the Atlas Computing Division would be merged with the C and A Division of the Rutherford Laboratory. Thus the demise of the Basic Software Group. The Engineering Board had approved the setting up of the Engineering Computing Facility (ECF) in the Autumn of 1975. Some of the Basic Software Group staff continued to support the installed equipment. The FR80 Project was run down. The majority of the Basic Software Group staff moved to provide support for the new Engineering Computing Facility installing interactive computing systems for research engineers in UK academia for the next six years. Work on the ICL 1906A was run down and the PDP15 was replaced by the newer facilities provided by the ECF. The FR80 continued to provide a specialist graphics facility for a number of years into the future. The GEC 4080 front-end processor to the ICL 1906A and 360/195 provided a basis for the communications software for the new GEC multi-user systems installed as part of the ECF.
The Basic Software Group was formed just under four years ago as a result of changes to the Atlas Laboratory's internal structure. It has been responsible for all systems software development at the Laboratory during this period.
Probably the main area of work has been the systems software on the 1906A. The paging hardware arrived soon after the Group was formed and a service was started soon afterwards. There has been a continual development of the operating system over the period going from Mark 6.2 of GEORGE 3 to Mark 8.32 of GEORGE 4. The enhancements to the operating system , utilities and compilers during the life of the Group has greatly increased the efficiency of the machine and improved the user's view.
The other two main areas of work have been graphics and communications. Initially, the graphics work was mainly connected with the PDP15 and the 1906A but more recently it has also included the 360/195. Significant developments have been made in the areas of interactive graphics and computer animation. The Laboratory is fortunate in having hardware and software as good as anywhere in the UK. The communications work has been mainly concerned with providing remote job entry facilities to users via the 1130, 2050 and 4080 computers.
Major changes have been made to the structure of the Group during the last few months. The FR80 Project Branch ceased to exist and seconded members returned to their own groups. System development work on the 1906A has stopped. Maintenance of the 1906A systems software and operating the FR80 is now the responsibility or User Services Group. Most of the Group are now employed on the tendering exercise and benchmark definition for the Interactive Engineering Facility and associated equipment.
The current Group membership is:
The intention is to amalgamate Atlas and C & A Divisions on 1 April into a single Division providing computer support for the Rutherford Laboratory and its users. The Basic Software Group is likely to cease to exist in its current form as from that date.
M D Fowler has left the Laboratory during the quarter. M J Evans and T R Peart returned to college.
Mark 8.32 took slightly longer than expected to settle down to the level of 2 software breaks a week. It seems to be difficult to get below this. It was decided not to miss out Mark 8.42, mainly because of the advantages the Variable Object Program Area would offer GEORGE 4. In Mark 8.42, ICL's jobwell becomes secure and more of the Oxford jobwell coding could be removed. (In Mark 8.50, the ICL jobwell becomes complete - it recognises the JD parameter and allows HLS to start jobs.) Testing of Mark 8.42 was just beginning when responsibility for GEORGE 4 system maintenance was handed over to Operations Branch in December.
A project to measure performance aspects of the PDP15/BSI/1906A interactive system was carried out with the joint intention of measuring the degree to which the 1906A was degraded by use of the BSI and to identify those areas of the system which could be most usefully tuned in order to improve the response time seen by the PDP15. Three main areas of analysis were concentrated on:
The results of this study were published in Technical Notice 125. The most notable one was a measured 1.05 millisecs EXECUTIVE overhead per BSI transfer.
The ICL DATAPASS system, mentioned in the last progress report, was implemented in full during the last period. ICL supply a number of data analysis utility programs and associated macros with this system, but these were found to be disjointed and cumbersome to use, and, therefore, a general-purpose macro was produced to provide a new interface to those analysis programs that were likely to be required (Technical Notice 126). It is interesting that the original ICL macros each required at least 5 mandatory parameters when used, whereas the new Atlas macro requires just 1 mandatory parameter but may have 22 optional ones.
The Order Number Register facility of DATAPASS was finally made to work. This allows monitoring of exactly where in GEORGE all the processor time is spent (both on a chapter basis and instructions within a chapter). In prime shift, up to 25% of the time was spent in a few instructions of the core allocator and another large proportion in the chapter that reads from the communication processor. In view of this, changes were made to the core allocator in an attempt to speed up the location of free blocks for small requests. These (together with core unjammer mends reported previously in Mark 8.22) have been in Mark 8.32 for several weeks and there has been a significant decrease in GEORGE overhead. However, more DATAPASS results show that the new allocator gives bottlenecks in handling the LONGLOCK area and. further work is certainly required. Operations Branch hope to do this if time is available.
The GRESTORE macro has been written which allows GEORGE restores to be halted and saved (to be continued later on). This has made the system of producing new GEORGE versions very much more efficient since the phase of restoring from tape-to-disc is avoided on most runs.
Work was begun on a film to demonstrate internal workings of GEORGE, to be driven by DATAPASS output. This is now postponed indefinitely.
A study was made of the problem involved in converting the GEORGE editor to work correctly with 3-shift files, and a paper was produced. It would be a project of several weeks, full time, to implement. Again, work has ceased as part of the embargo on 1906A system development.
The run down of 1906A work prevented any investigation into the efficiency of TASK but the tools are now available in the form of programs to analyse and summarise the information output to :SYSTEM.JOURNAL. This work involved enhancing programs originally written by S R Perkins to access the various timing information output and also to give a breakdown on the basis of internal and external users. The new programs also give out the various sum totals to enable statistics for several periods to be hand calculated.
The major effort of the period has been the completion of the revised TASK manual which is now at the printers. This would not have been achieved without the efforts of V M Boulton, M E Claringbold, K Robinson, I Vollmer and A M Walter who took on the arduous job of proof reading and correcting it. Thanks are due for all their hard work and also to J B Chamberlain for her contribution.
The implementation of changes to COPYIN and COPYOUT and the new COPYSUB utility is complete with the exception of the complex error handling code. Work in this area has ceased due to other commitments. The parameter NOCOMPARE has been implemented to inhibit comparison after a magnetic tape copy.
The analysis program for the TASK statistics were extended to produce similar statistics on the NUTS system.
An italic font to use with D C Toll's Document Production Program was constructed. This was based on a font designed by Susan Hockey. Further work on a document production system has been suspended.
The work from the 1906A has continued to increase. Most of the jobs arrive via the spool system, average about 650 per month. The 360/195 spool software finally arrived at the beginning of the period and is being used for a significant number of jobs - mainly microfiche and hardcopy.
Three different IBM Print Programs have been set up for 360 users. However, because of problems with the spool, these are still not available to users.
Work from Oxford University has been arriving via the Rutherford courier service. The major use is for microfiche output.
The refurbishing of the hardcopy processor has still to be carried out. Difficulties in obtaining the necessary parts has meant that it will be the end of April before this can be done.
The overall design of the new FR80 displayer program, DRIVER, has been completed. The software construction method described in Technical Paper 21 is being used and is performing well. To date, the prototype's interrupt, instrumentation, task interleaving, operator, clock and teletype handlers are up and running.
Following the initial trial period, the full automatic accounting scheme has been introduced and appears to be working satisfactorily. Virtually no maintenance or development has been required.
Various updates were carried out during this period. It is unlikely that any more changes will be made until after DRIVER has been implemented. The main modifications are:
A data mode order has been provided to enable fonts to be switched from within a run. The fonts are saved in binary form on disc by dumping them out using DEBUG. Use is made of the table reset and disc read code already present in the Displayers to read a new character code from the disc and recalculate pointer tables and proportional spacing limits.
Access to this order, and the method of generating new font files, has been documented.
The latest release of RSX has been implemented. The latest source release of RSX was RSXPLUSII (1A) and it was necessary to update this using the (1B) binary release and correcting all the bugs to this system given in the software performance reports. Once this version had been produced, the modifications made by R E Thomas to the earlier pre-release version were incorporated:
Multi-user capabilities have been built into RSX by generating multiple copies of the EDITOR, one specific to each terminal. FORTRAN and MACRO compilations and task-building can be carried out by submitting BATCH jobs from the terminal. BATCH has been modified to send its output to the 1906A lineprinter.
More work needs to be done on the system but a new release (RSX/XVM) is expected soon Contracts willing!
The BSI link has been used extensively during this period. This is mainly for transferring source files and listings. Some large source files in the RSX operating system are now kept in the 1906A filestore.
The effect of the outstanding intermittent hardware fault has been reduced by altering the PDP15 handler so that a delayed (but correct) reply from the 1906A is not treated as a time-out (for example, reading a 1906A file that has to be retrieved).
Occasionally the handler in the 1906A fails to start correctly. It obeys a PERI to read from the PDP15 and does a SUSIN to wait for the reply. Although a PDP15 program writes to the link, the SUSIN is never satisfied. Connecting a MOP terminal to the 1906A handler and then disconnecting sometimes wakes it up! An EXEC bug is suspected, but the fault is not serious enough at present to take a system post-mortem.
A BSI handler has been written for RSX based on the DOS version and the model provided in the RSX handbook. Since RSX handlers work on the principle of setting event variables and waiting for them to be set, the structure of the DOS handler had, to some extent, to be altered. Thus a READ or WRITE must now be completely finished before the next request can proceed (under DOS, the status of the last request was checked before the new one was serviced). It is now possible to use TDV commands to send files to the BSI and read data into files. These facilities are also available from FORTRAN.
There has been some interest in PIGS by other installations. Requests have been received for copies of the EUROCOMP paper. Electronic Music Studios of Stockholm have a copy of the sources to use on their PDP15 system.
There has been little use of the system at Atlas due to the organisational changes and curtailment of graphics work. However, M Davies is writing an interactive system using PIGS to communicate with PAFEC on the 1906A. This is the first use of PIGS and the BSI together and one or two further bugs have been sorted out.
GIFTS is a suite of programs for finite element structural analysis developed on a PDP15 by the University of Arizona. An interactive graphics phase is used in the formation of the mesh and pictorial results are displayed. Several difficulties were encountered in mounting the package. These were traced to the differences between operating system versions DOS V2A and DOS V3B. The GIFTS suite now appears to be running correctly and is in a useable state.
A working sound generation package is now available on the PDP15. The input data can specify notes or can individually change the value or values of parameters on the synthesizer. A macro expansion facility for repeated sequences of events, with a limited form of parameterisation, is also available. The main program is a 2-pass system. The first pass reads the input data and calculates new values for each active device (for example, a note) every clock pulse (the clock pulses are generated by software). This expanded data is written to magnetic tape and read back in by the second pass and output to the synthesizer under the control of the hardware clock. This 2-pass system ensures that no clock pulses are missed by the program.
The system has been written in a modular form which, although not perhaps the most efficient, will greatly ease the addition of any new features. A manual for the system and a brief description of how to use the synthesizer are under preparation.
A pre-issue coded and documented set of routines for the production of 1000 × 1000 mesh half-tone prints in a scanning mode was completed before the FR80 resource discontinuity occurred. A rudimentary element processor allows linear transformations to be made upon the data stream to adjust cut-off and contrast in the image.
As expected, when used to control colour production, the scanning routines permit faster printing and more predictable results than the conventional drawing routines - an increase in resource allocation might pay dividends here since further work must be done.
The set of scanning routines is closed by the inclusion of a magnetic tape interface from the microdensitometer. Pictures scanned by the microdensitometer may, on a routine basis, be reproduced on microfilm or 12 × 12in hardcopy (currently limited to 32 levels of grey).
The only changes made to the SPOOL software recently are:
Internal documentation was completed as Technical Paper E.
The first version of the de-spooling system was installed at the end of November and has been in heavy use throughout the last four months. Experience with this version indicated that some extra features would be useful:
A new de-spooler has now been written that includes these features as well as the features necessary to de-spool SYSOUT-M data for the IBM Print Program. Although it appears to work well in tests and, in addition, cuts out some of the overheads of the previous version, its issue has been delayed until a remaining difficulty concerned with the interpretation of lineprinter control characters has been sorted out. Once in operation, it is expected that the use of FR80 microfiche will expand considerably.
The major SMOG event of the quarter was the despatch of the manual to the printer (after the careful choice of a colour for the cover!). This occurred after the change something - retype it - check it loop had been reduced to finding one or two minimal errors per day. The bound manuals should be available in April. The main additions to the system have been:
These additional routines caused NULLIB, which is used to generate the SMOG library on the 1906A, to break. It was discovered that NULLIB can only handle up to 100 side (secondary) entry points. After some internal shuffling, the system was reduced to having exactly 100 of these.
A large number of routines which use SMOG have been written by C & A and Atlas staff. It is likely that these will eventually be gathered together into a high-level SMOG library.
Reading and Oxford Universities are now using SMOG as part of an FR80 post-processor for the GHOST graphics system. The post-processor was written at Reading but appears to be being debugged, with some difficulty, at Oxford. Both sites have minor problems - Reading cannot find the username and jobname while Oxford cannot get their picture within the camera limits. Both sites are being assisted remotely.
The main work on SPROGS this quarter has been the development of some routines for shading in closed curves. In order to allow animation of these shaded areas several new features have been introduced. It is now possible to define a picture file whilst using the sequence list and the in-betweening routines can now accept absolute as well as relative linedrawing commands. Thus it is now possible to in-between from one picture to another and then shade in the resultant outlines.
The data describing the closed curve to be scanned can be held in a SPROGS picture file or in a 2-dimensional array. If picture files are used several can be scanned simultaneously and hidden line removal can be achieved. The shading-in is normally performed by drawing lines only a few raster positions apart but a further option allows the scanning to use a set of specially defined text characters to fill in the area. This set of routines will be released within the next month.
Routines to use the vector family and colour facilities of the FR80 are now available in SPROGS, as are the vector speed and raster routines described under SMOG.
The hold-up in implementing SPROGS on the 360/195 is mainly due to the large core requirements for even a simple program which has slowed testing alarmingly. This is due to the size of the character fonts. On a paged machine like the 1906A this does not cause any problems but it can be embarrassing on a machine like the 360/195 with obsolete architecture. However, the end of the road is now in sight and SPROGS should be available before long.
Some changes have been made to this package during the period. These have in general been concerned with the closer simulation of the old SC4020 package. This has been necessitated by the high reliance of users in the past on the old package and particularly with respect to its action in the event of an error.
Modifications to the SCFOR options now prevent wrap-around of both characters and vectors and prevents the production of output outside the region specified in option 2 by SCFOR plotting options 7 and 8. Modification of the text output routines have prevented overprinting caused by HTEXT by storing a current typing position. This was only possible as proportional spacing docs not exist in SCFOR.
The only addition to the system has been the introduction of TOMUG to the library. This is really a SMOG routine and attempts to remove a deficiency in the 360/195 implementations of SMOG, SPROGS and SCFOR. Further details are given in FR80 User Note 15.
A library of high-level graphics routines is being set up in :GSIN00. This library will contain some existing routines which are currently included in both SMOG and SPROGS and a number of new routines. The routines which are already in the SMOG and SPROGS libraries will eventually be deleted from them and will only be available from the Graphics Library. The library will include routines for contouring, plotting 3-D histograms, curve fitting etc.
A 3-D histogram routine, SCAT3D, was obtained from HEP and J R Gallop converted it to run on the 1906A and to use SMOG (instead of MUGWUMP). However, there were faults in the hidden line algorithm which showed up when a coarse grid was being used. After first suspecting that errors had resulted from the transfer to the 1906A, it now appears as though the errors may have been present in the original routine.
The SCFOR map projection program has been implemented by R E Thomas in SMOG to allow various projections of map data to be produced. Currently, the only data file available is the map of the world, but others can easily be constructed from latitude and longitude data.
The Archuleta 3-D package has been mounted on the 360/195 by M F Chiu. After Some initial problems concerned with variables that were not data initialised to zero and a misunderstanding about the alignment of certain arrays in COMMON, the implementation on the 360/195 proved relatively painless. It only remains to add a note concerning the 360/195 implementation to the existing documentation before releasing it for general use. It is proposed that relevant routines be incorporated in the ATMOL3 plotting package for drawing 3-D electron density contours and potential energy maps.
The review of contouring algorithms begun in October was completed in November. It was decided to base a new FORTRAN package on two algorithms by Heap (NPL) with some ideas from various others. This package has now been written and tested and will be available shortly. There are two user level routines available, one for contouring over a regular (possibly skewed) rectangular mesh and the other over an irregular (possibly skewed) rectangular mesh. Within each of the routines a number of options concerning the drawing of the map are available. However, these are available via a COMM0N block, and only those items of data necessary for a contour map are supplied as arguments. These routines are two to three times as fast as the existing SMOG/SPROGS contouring routines.
This package will be added to the new Graphics Algorithms Library and should replace the existing SMOG/SPROGS contouring algorithm (CNTOUR). However, no capability exists for specifying an internal boundary and So the SMOG (SPROGS) contouring algorithm which does (CNTOR1) has been rewritten and will be added to the library.
Documentation is being produced for all these algorithms.
The characters in the 1906A lineprinter set have been designed and implemented in a large blocked font which can be used for film titles, slide generation and eye-readable titles on film. The font is available on both the 360/195 and 1906A. Additional characters, in particular lower case, will be added as time permits. A User Note is being prepared.
FAMULUS output to microfiche has tended to be a mess due to the system outputting page-throws and titles every 50 lines. This has meant that every other page on fiche has been virtually empty. A TITLEFICHE macro has been implemented which allows the user to choose. his own titles, select a suitable page size or select 42X reduction.
The output from Jean Nunn-Price's program to simulate the compression of plasma by laser energy had been used to produce an animated film which was shown to the ABRC when they visited the Laboratory.
A description of how to use the audio equipment in the Projection Room has been written by A H Francis. Many of the existing connecting leads in the Projection Room were felt to be wrong, eg loudspeaker output to a line input, and so a new list of connecting leads was drawn up, attempting to correctly match the inputs and outputs of the various pieces of equipment. This gives rather a large number of leads and makes the centre of the Projection Room resemble black spaghetti! The current suggestion is, therefore, to have a central switching console into which all of the equipment is normally plugged. To interconnect any two pieces of equipment then merely requires the setting of two switches. This should avoid the possibility of operators plugging in the wrong leads and damaging the equipment, or at best obtaining no sound.
J R Gallop has joined the project and is undertaking the task of dealing with the network HASP Protocol.
The 1906A-4080 hardware interface has had a number of minor bugs removed and it is thought that it is now logically correct. The reliability of the device is poor and this seems to be due to edge connectors in the main. These have become worn with the continual removal of boards during development. The device has worked for a complete week without a fault but then becomes unreliable after, for example, moving it slightly. It appears to be particularly sensitive to floor cleaners! The device has been demonstrated to transfer data at a very high rate (0.25 Mchars/sec). In the early design stage, double buffering was incorporated to improve the transfer rate. This was removed to reduce complexity at a later date. This change does not seem to have adversely affected the transfer rate.
The design and coding is complete and debugging is proceeding as rapidly as possible. The timescale of completion by Easter is tight. A separate diagnostic program to run MOP on the 4080 is complete and has been used to check that the 1906A - 4080 hardware interface works reliably. It provides an easy means of determining precisely what GEORGE does when running a 7903. The program monitors all transfers across the interface. A useful side effect is that MOP can be run on the 4080 console at 4800 bits/sec.
A small amount of development work has been done. Modifications have been confined to providing new facilities in the command processor. These include an INPUT and LISTFILE command. A TYPE command has been added which allows a file to be listed on the console. There is also an OBEY command to execute macro files.
It has been found possible to automatically re-enter a process when it fails. This allows automatic post-mortems and automatic restarts. This will be used in the final system to ensure the system continues without operator intervention.
The IPL procedure has been improved so that less typing is required. Facilities are available to load the complete communications system automatically, making it easy for operators to restart the system.
Coding has begun on the process which communicates with the KERNEL and with the 360/195 line handler. The line handler (Section 7.5) was completed last quarter. By agreement with C & A Division and Daresbury, HASP multi-leaving records will be transmitted inside an EPSS-type packet in order to identify the origin and destination of the records. It is hoped that EPSS connection will anticipate future developments. If a line to Daresbury becomes available, another process using the same code can be used to communicate with the 370/165. It is now understood that due to lack of PO plant at Daresbury no date can be given for the delivery of such a line.
The HASP RJE controller has been written and tested up to the point at which it will receive data from a remote card reader and will transmit data to a remote lineprinter. Testing with remote teletypes is held up awaiting a suitable emulator for the 2050.
Use of the HASP line driver has shown it to be workable apart from a couple of minor bugs. The size of the code and the amount of CPU time used, however, both seem unnecessarily large, and some work is in hand to reduce them.
The process to allow the 4080 to participate as a host on the network has been advanced to the same level as the workstation controller for testing purposes. This process is also intended to allow the 4080 to log-in as an RJE station to one of the mainframes on the network.
A preliminary investigation of the DOS overlay system has shown that one process, plus the operating system overheads involved in opening and writing to a disc file, are sufficient to fill the overlay partition. This is a little worrying as it will prevent development of the system while it is running and care will be needed in the use of files by the running system. There is no doubt that the core requirement for running DOS comfortably were underestimated and further data has been collected to show how the space is used.
Part of the bridging protocol has been implemented. Before much more progress can be made access to a PSE will be required. No PSEs are yet in operation. Progress is very slow in line with most other EPSS participants. There is still quite a bit of work to connect the EPSS system through to KERNAL.
Close liaison has been maintained with C&A, Daresbury and ERCC by attending the various progress meetings. There has been considerable interest in the 4080 from other sites investigating front end processors and visits have been made by Glasgow University and Plessey.
The Tendering exercise for the Interactive Engineering Facility has taken up a large proportion of the Group's time since December. Reading manuals, having meetings with manufacturers, defining benchmarks have become routine occupations.
The work has been divided so that each member has been responsible for one manufacturer and one aspect of all systems. This two-way split has been useful in focusing attention on particular aspects.
A major problem is understanding the manufacturer's terminology. A directory for one machine is a catalogue on another and a file on a third. Loaders turn out to be binders. There are numerous examples of spades being called shovels, or even trowels.
A set of five programs have been assembled to form the batch benchmark. Most of these have been used in the past and are known to give a good assessment of the FORTRAN system on a machine.
The interactive benchmark was a greater challenge. There is little relevant literature on the subject. It was decided that this was to be a synthetic benchmark, divided into editing/compiling scripts and interactive program scripts. A program was constructed in FORTRAN which is data-driven to give any desired combination of processor, interactive and filestore behaviour.
A behaviour specification of the workload was produced based on the requirements in the Technical Group's Report. Scripts were then produced, modified, tested and a proportion of the benchmark actually run on the 1906A. The benchmark has had to be produced very quickly and, in some cases, its behaviour depends on rudimentary hypotheses about the projected workload. However, it is felt that it will be a good test of an interactive system.
The communication systems on all machines have been studied with a view to seeing how the machine can be incorporated in a network. RJE terminals are likely to be a problem as no manufacturer offers the HASP facilities required.
The main work has been providing a specification for the multi-user minis and in contacting manufacturers. A total of 26 possible suppliers was found (not counting EEC contenders). However, the software requirements are proving difficult for many and a list of 8 or 10 possible candidates has been produced. A formal Operational Requirement has been produced and will be used in producing a shortlist.
The design of a benchmark is proving troublesome. The important measurements concern the response times for the six interactive users which the minis are designed to support. However, no automatic means of running such a benchmark is available on most machines.
Computer-produced audio-visual materials, chapter in Computer Assisted learning in the United Kingdom - Some Case Studies. ed by R Hooper and I Toye, by A H Francis
Meetings were held with manufacturers concerning the Interactive Engineering Facility as listed below. These were attended by some or all of the following people:
