The FR80 Project Branch was enhanced by the arrival of Len Ford on 21 April. The current Group structure is:
In future, this report will be produced at four-monthly intervals as it is felt this is a more suitable length of time and it means Christmas and Easter holiday times can be avoided.
Mark 8.22 of GEORGE is now in use. The change. from 8.12 to 8.22 was a little more difficult than anticipated due to the large number of chapters altered by ICL and difficulties with the split residence changes. This means that we have now at last caught up with GEORGE releases. Although 8.31 is about to be released it is intended to wait for 8.32 which should be more reliable. It is being debated whether to mount 8.40 and 8.50 at all as they offer little advantage over the 8.30 series. This would give valuable breathing space.
A few minor enhancements to GEORGE have been included but there is still an unending series of suggestions for changes which may or may not be implemented. On the other hand ACL changes are being removed as ICL come up with changes to GEORGE which implement or supersede ACL developments.
Some development to TASK has been made and this system has further entrenched its position as the main mode of access to the machine.
NUTS is developing well and is starting to prove its worth to our users.
The new accounting methods are just being brought into service giving much better control of the users. Its effects have still to be evaluated. There is still quite a bit of effort needed to bring this, the measurement systems and report generators together, but their final form is becoming clearer.
In all, the 1906A software is in a very satisfactory state and although there still remains many pieces of work worth undertaking, their urgency is becoming less as time and developments proceed.
Three new features were added to this version during the quarter.
The CONVERT command was introduced to provide a very simple desk calculator. Its particular virtue is that it works in decimal, octal and hexadecimal and is useful for disentangling post mortems. As it is usable in NOUSER context there is no need to be logged in.
The LISTFILE command was enhanced to allow output to be paged to a terminal to allow output to be more easily examined on a fast terminal. In addition, output to a terminal can be stopped by the string *+*+, this being most useful for examining frames on a Tektronix. Unfortunately it has still not been found possible to make the BREAKIN character work on fast terminals.
The JOBTlME command when used without an argument was enhanced so that it replied with the time remaining to a job as well as the time used.
This was brought into service at the beginning of June. Most of the implementation problems concerned jobwell (with HLS) and split residence. The latter is standard in the next Mark and as the Oxford jobwell is merging into ICL's, these problems should not arise to the same extent again. Since the 8.12 and 8.22 jobwells were not compatible, a very short transition stage was desirable; fortunately this was possible as within a week there were no bugs serious enough to warrant a return to 8.12.
The most serious bugs are:
All are solved but the last one which can be checked for and if necessary restored. Holidays have delayed the incorporation of a new version which will solve all these bugs and should be installed at the beginning of the next quarter.
ICL have solved our most common system breaking bug (GEOERR QUOTA) and the mend will appear in the next version. No random software breaks ever appear to occur now and there is every reason to believe that the software break rate will be virtually zero in a few months. Most breaks are now due to hardware malfunctions and it is disappointing that the hardware is not improving.
Stop Press: the ICL mend to GEOERR QUOTA does not work.
The NR parameter (No Restart) was implemented in response to user concern about automatic job restart after a break: a feature of 8.22. It was also made acceptable in 8.12 (together with IF RESTARTED,...) in order to ease the transition.
Other developments which are complete but await a stable 8.22 are:
This has been studied to see exactly what the algorithm for allocation and unjamming is. This is now well understood. If time is available it is hoped to simplify it and make measurements.
The new urgency system was tested for several weeks by selected individuals and certain bugs were discovered and corrected. The system was finally introduced near the end of June. The first weeks appeared to go well.
The Accounting and Database Working Party has continued to meet and it seems probable that without it the new urgency scheme and allocation of time to users would have taken much longer (if it could have been done at all).
A note describing the state of all accounting reports has been produced.
The major task of this quarter has been in implementing the changes budgeting and period accounting needed for the new budget urgency system.
A special program was produced to do the initial updating of all users' Time(M) and Time(H) budget rations using data supplied by Resource Management Branch. The MUSE macro (for initialising new usernames in the system) was changed to reflect the new budget structure.
The part 1 period account program was changed to extract usage of the new budget types from Dictionary and to update the allowance of each Time budget equal to the ration. Facilities to scale down budgets for short weeks were also added.
The part 3 account program was modified to effect updating of the new budget types.
Changes to the part 2 accounting program which updates the database information was complicated by the need to increase the number of fields in the database to hold the new cumulative totals for each budget type, and to produce special programs to map data from the old structure to the new. All the necessary programs to effect the updating and the new part 2 accounts program are tested but implementation awaits changes to other utility programs dependent on the current database structure.
It is hoped that in the next quarter the long term development of the accounting and budgeting system can be completed and the main programs handed over to Operations as a production system.
The main event of this quarter was the introduction of TASK version 48 containing items documented in the previous QPR plus several new features. These included reduced output from the consolidators (as requested at the Large User Seminar), the new PLAN compiler (8B) with the Mk3 DA Housekeeping and enhanced log and broadcast messages. The implementation of the PR property parameter was considerably improved to improve resilience should the job fail in any way.
To help PAO, instead of the gradual evolvement of TASK previously practised, these major changes (requiring three pages of documentation in :NEWS.TASK) were implemented in one release. The fact that it went in so smoothly and contained so few bugs was a minor miracle. Because TASK is so fundamental to the running of the 1906A and reliability is a most necessary attribute it would seem unwise to continue this practice and more gradual evolvement is planned for the future.
The only scheduled enhancement is the introduction of improved jobtime monitoring using new ACL extracodes. TASK will thus be able to avoid failing JOBTIME EXCEEDED and hence allow the system to tidy up, route monitoring files, log and broadcast back to MOP users. Log and broadcast messages should also soon contain the jobname.
The graphics macros SPROGS, SPROGSF and SMOG were all rewritten so that they interfaced better on to TASK and their users now have the majority of TASK facilities at their disposal. The feasibility of the inclusion of these packages as an option in a TASK call is also under investigation.
The TASK has manual has made little further progress as the time available has been limited and so that TASK can be documented as near to its finished state as possible.
Changes to the NUTS Kernel included the addition of the CONT parameter, modifications to the PR and LIST systems in line with TASK changes and enhanced exofile parity features. Future work will be confined to improved broadcast and logging messages and the use of the jobtime extracode as in TASK.
The enhancements to the PRINT and COPYIN/COPYOUT utilities detailed in the previous QPR are now complete. The subfile printing facilities have been found to be very useful by certain specialised users.
The NUTS utility to print the structure of a magnetic tape has been changed. The old version of the utility is available by specifying the parameter SUMMARY to the PRINT utility, but if the parameter SUBFILE is supplied, and the tape is in standard ICL Housekeeping format, a list of the subfiles on the tape together with their creation dates will be given.
With the advent of a new kernel parameter, CONT, changes have been made to the COPYIN and COPYOUT utilities to make certain errors non fatal if this parameter is supplied.
The major effort this quarter has been in producing documentation of the NUTS system as it stands at this time and this has been released as IUN 111.
Design work for enhancements to the COPY utility to enable magnetic tapes to be copied in terms of subfiles rather than block numbers has commenced.
These ACL macros have been updated during this quarter to incorporate the changes detailed in TNI05. Documentation on these macros has now been released (IUN 110).
The interface and archiving software, various utilities and documentation has been assembled in a form suitable for external distribution. Copies have been sent to UIJPC and other 1900 sites.
This is being examined, principally for a user who needs it, partly for more general interest.
As a result of requests made at the Large User Seminar, the default listing level of the ACL Consolidators has been changed to SHORTLIST, and the listing level directives have been implemented in XPCH. Modifications were also required to make the names of MISSING AND OMITTED segments appear in XPCH.
Little further effort has been expended on examining document production systems on the 1906A. It is clear that the GEORGE editor is not suitable for this work. No suitable terminals have yet been ordered for this purpose.
The 96 character chain for the 2050 should soon be delivered and further work will be appropriate.
The system of outputting fiche on the FR80 directly from a LISTFILE command was finished in time for the commencement of the FR80 service. Due to the delay in the FR80 acceptance it was found possible to implement all the LISTFILE options. It has not been found possible to put headings on FICHE and the FR80 Project Branch hopefully will be able to solve this problem.
Further development will be necessary with GEORGE 4 Mk 8.22 with the LISTFILE context to context facility.
An attempt is being made to alter GEORGE to allow the listing of erased and work files to be listed to fiche.
The GERONIMO program has been converted to GEORGE Mk 8.22 form, and the macro enhanced to detect which issue of GEORGE is in use. The situation where the VDU controller is left in HOLD mode is now detected, and the EXEC looping problem should not recur.
Documentation of various BSG macros used in system macros has been produced (IUN 108) and a standardised means of generating internally issued RUNJOBS has been introduced. It is hoped that this will help toward a standard interface for all system macros.
This was held on 17 April and appeared to be useful to all. User feedback on their various problems proved very helpful and has resulted in several changes to ACL systems. Especial thanks are due to R T Po11ard for giving his views on using the 1906A.
The second volume of the 1906A Reference Manual arrived in time for the large user seminar and the third volume some time later. It is now being distributed to users.
The 4080 front end project has had a number of set-backs. The hardware has had a number of teething problems. It had been hoped to have the 1900-4080 interface operational at about last Christmas, but it is still not usable. The kernel software is virtually complete, but the 1906A and communications petals are not yet so well developed.
Agreement on the interface to the 360/195 has been reached which looks very satisfactory.
After superhuman effort, the additional 32K of store, duplex communications board and disc were installed and paid for. The store has performed well the disc has had a number of failures mainly due to bad packages.
The power supplies have continued to give considerable failures and there appears to be no end to these problems.
The line testing code has been developed and tested. There is now no useful purpose for the Sigma 2 computer.
Unfortunately this interface is still not complete and little development has been made. It is important that this should be compiled in the next month or so if the project is not to suffer serious slippage.
The LOGON and LOGOFF sections have now been incorporated, and work is in hand on the insertion of consistency checks and error recovery routines.
This is now substantially coded. LOGON, LOGOFF and SELECT messages are recognised.
A process named PRIN has been written to copy files from the disc to the lineprinter. It may be used to print and erase spooled output files from the region .SCRATCH, or to print text files from a named region. Documentation is contained in the GEORGE file :DYE.PRIN-DOC.
A process named MAC has been written to expand JCL files for input to CLE. It allows parameter substitution as in GEORGE macros, and a limited amount of macro recursion. Documentation is contained in the GEORGE file :DYE.MAC-DOC.
Following the successful generation of the disc-based operating system (DOS) on the 4080, the core-Based system (COS) is now no longer used.
A new release of DOS (version 2.2) has been received and mounted, although this took much effort. This was partly due to the fact that some of the facilities we use were untried by GEC, and also to the fact that it is impossible to generate a DOS 2.2 system when running under a standard DOS 2.1 system!
Fortunately GEC gave a considerable amount of help with this, including patches to the system generation macros and to DOS 2.1. They have now issued Software Notices warning other sites of the problems we encountered.
All the detailed design work and flowcharting of this process is now complete, and work is currently in hand to amend where necessary those routines already coded so that they agree with the flowcharts. In particular, the process initialisation and post mortem routines will need extending to cater for the extensions to the process data definitions introduced as the process design was completed. When this recoding is completed, the rest of the process (ie most of it) will have to be coded from the flowcharts.
There has been some slippage in the timetable for writing this process, and, although it will be complete by Christmas, there is some doubt as to whether it will be sufficiently well debugged by then to release the system on to unsuspecting (?) users.
In view of RL's proposals towards network design and use of EPSS, it was agreed that the specification for a line handler would change completely. The salient feature is that the interface between the handler and the Buffer Assembler process should carry data of the form of a data field in an EPSS packet, ie the interface would be independent of the transmission protocol actually being used (HASP or EPSS).
A side effect of this is that initial polling, recovery from transmission errors, and ACK and NAK control, etc are all performed within the handler.
The writing of the code for the handler has been completed and testing is just commencing in earnest.
Two more errors have been found in the Emulator and these are concerned with card input. The first was a curious misunderstanding of the 7903 protocol which only manifested itself when continuation cards are used at the start of a card deck. This has now been cured. The second error concerned blank cards which disappeared by the time they should have got to the 1906A filestore. The reason was the severity of blank suppression of card input in the 2050 in that the blank cards were suppressed to no blanks instead of one.
The corrections will soon be sent to the remote sites.
Little or no development has taken place due to lack of staff. In any case the Post Office has put back the opening of the first exchange to the end of the year.
EPSS meetings have been attended. In particular, interest has been taken in the bridging protocols group which recommends the method of bridging between the line protocols and high level protocols.
Discussions have been held with GEC, Harwell and Rutherford which have been very helpful.
There is still considerable effort required to determine the best course of action for the Atlas involvement.
It is hoped that some further implementation may be possible in the next quarter.
The first month was spent continuing with the FR80 Acceptance Tests, 12-hour days being the norm rather than the exception. Work continued over the Easter break.
The main problems were accurate abutting on 35mm and hardcopy. Measuring equipment was sited in RL and inaccessible during the silent hours. This slowed down the turnround. Machine settings needed to be calculated and finding the right intensity and contrast for the 256 intensities proved to be time consuming. The measuring equipment was again sited in RL, but it was accessible to named members of ACL at any time. The CLEAR filter on the colour camera needed to be changed to give an acceptable CLEAR. Advice was sought from RL photographic and PAD before finally settling for a CC30R and a CC50Y.
The tests were finally started on 18 April. The abutment was unsatisfactory and more adjustments were required. The tests were restarted on Monday 28 April, this time running through without any stoppages. The magnetic tape drives required more attention, as did the 5010 film processor. The machine was finally accepted on 19 May - 2 months after arrival.
A more detailed report and figures for the Acceptance Tests are now being compiled.
Following an Operator Training Course, an in-house service was started on 12 May, most jobs being from members of the branch. A user service was started on 1 June. A summary of the month's operation is now being compiled.
Camera schedules are proving to be rather demanding, mainly due to a lack of personnel and variety of tasks they have to do. Loading of hardcopy and microfiche are time consuming, and both have large overheads as far as waste film is concerned.
Hardware faults have occurred in many departments, in particular - MT decks, hardcopy camera, monitor, teletype, 5010 processor and colour filters.
All accounting is done manually at the moment (but see below for details of accounting program).
The replacement colour processor has been installed in Rutherford Photographic Section, and has so far given little trouble. However, one rotor had to be exchanged because it did not fit, and a collar on another worked loose. The processing of colour film produced by the FR80 is also proving very time consuming.
III required the acceptance tests to be done using Dacomatic E film. ACL normally uses Dacomatic A, which is faster. Tests were carried out, therefore, to try and find working parameters for this film, to see whether the required resolution on 105mm could be achieved. This film proved to have savings in all departments, as the following table shows:
| FILM | INTENSITY | VECTOR SPEED | RESOLUTION | PROCESSING SPEED - FT/MIN |
|---|---|---|---|---|
| A | 4×40 | 2 | E-F | 20' |
| E | 8×25 | 8 | D-E | 16' |
Chemicals in the 5010 processor were changed to suit the A type film. This initially gave some trouble with a mottled type of background, but it was overcome by reducing the strength of the first developer, increasing the processing speed from 16' per minute to 20', and increasing the concentrate of the second developer to give a darker background.
The Al darkroom, where the 5010 is sited, has a very poor ventilating system and cannot cope with the heat from the dry box (150°F). This makes the operating conditions very uncomfortable.
The SMOG package is now almost complete. The current outstanding work is the inclusion of some of the high level routines, such as 3-D plotting, from SPROGS, all the 2-D high level routines being available. At the end of the last quarter only a basic package had been implemented. This has now been superseded by a more complete version which is available from :MACROS, the semi-compiled libraries being in : SUBLIB. This new version has accounts, logging jobs and ID frames at the beginning and end of the users data for the FR80. The lineprinter graphical output and the text characters for the Hewlett-Packard pen plotter have also been completed, A facility for reading basic picture files from libraries produced by the SPROGS package has been included. This allows the use the full flexibility of SPROGS to produce complex backgrounds or static pictures while using the simpler and faster features of SMOG to produce the foreground or changing part of the picture. The routine DVALL has been written by merging the output device handlers together. This allows the output device to be selected at run time.
Now that the FR80 has been installed the package has been substantially debugged. Problems were experienced with the FR80's handling of hardware characters but these have now been allowed for or overcome. The character scaling routines were found not to be very easy to use so another simpler routine, which is sufficient for most applications, has been written.
The macro has been converted by the Communications and Systems Branch to use the TASK system more fully. Some problems have been experienced and further development work is in progress to make SMOG a part of TASK. The macro for regenerating the SMOG system has also been converted to use TASK.
The SMOG System manual has had to undergo a variety of changes in draft form to cope with the various abrupt changes in the system being described. This evolutionary exercise has caused it to assume much of the form one has come to expect in an ACL handbook.
The FR80 spooling system (documented in FR80 User Note 3) has been in use for much of the quarter by both internal and external users. Certainly for the hardcopy camera, it has fulfilled an important aim in that the number of magnetic tapes mounted on the 1906A is much smaller than otherwise. For instance, during the 8 working days between 10 and 19 June, 138 hardcopy jobs were sent via the spool to the FR80 on 36 tapes. The other cameras do not show such a clear advantage, mainly because far fewer jobs for these cameras are sent through the spool, For all the non-hardcopy cameras during the same period, 39 jobs were sent to the spool and used 24 tapes. It is almost essential to separate cameras onto different tapes, since the cameras themselves have to be manually replaced with some effort. Otherwise fewer tapes could be used.
Because of the VIEW/ERASE facility (see 903), several more jobs never appeared on tape, because the user was able to inspect output on a Tektronix and realise that plotting was not necessary.
No jobs are lost if tape fails are detected by the 1906A whilst writing. However tapes have failed on the FR80 after apparently being written without problems on the 1906A. This is a potential cause of lost jobs, but the FR80 operators now try to copy a failing tape either on the PDPI5 or on the 1906A. So far this procedure has proved satisfactory in all but one case.
The possibility of a disc failure exists and code is being written to improve the method in which the readout system handles failures in disc control blocks and/or data. The two incidents that have occurred so far, however have resulted in a failure to ONLINE the spool - when a faulty disc drive was used and when Friday 13th June became a zero date, In both cases the contents of the spool were not affected and could be read when the condition was cleared. Any graphics job, however, which attempts and fails to write to the spool is thrown off. It is debatable whether the graphics packages should automatically use an alternative if a failure is detected, for instance a worktape could be used.
Additions to the system this quarter produce 9-track tapes (not tested on the FR80 yet), pass on data for the FR80 accounting system, add some emergency accounting data if the user's job failed, produce an improved printout for the FR80 operators and generate records in a logging file in the filestore (1 record per job and 2 records per tape used) for subsequent analysis.
This is the 1906A Program for viewing FR80 orders on the spool.
Much work during the last quarter has been devoted to tidying up the code and speeding up such things as frame skipping etc.
However, at the request of users several new parameters are now available. These are:
New documentation is waiting to be typed.
The outstanding work on GROATS has been completed this quarter.
The FR80 version of SPROGS has been completed and released to users. It is available under the macro SPROGSF. The SD4020 routines have been replaced by FR80 versions, and extra routines have been added to allow SMOG jobs to run in SPROGS without alteration. In fact, due to the differences in basic philosophy between the two systems, there still remain some minor differences.
In addition, routines have been added to alter the character used to draw vectors on the lineprinter, and to allow more features of SPROGS to be dummied. In particular, considerable lower core saving is possible by dummying all index variable references. Output to the Tektronix and Hewlett-Packard has changed in format slightly to take account of the new LISTFILE ALL feature, which allows a pause during file listing at a line containing *+*+.
The macros SPROGS and SPROGSF have been altered to allow more of the initialisation to be carried out in TASK. The possibility of further alterations to TASK to allow graphics to be incorporated automatically is being considered.
Requests for copies of SPROGS have been received from Manchester and Appleton Laboratory.
The system has been released to users, together with suggestions for changing to other packages. A manual has beer published (FR80 User Note 5). Various minor alterations have been carried out, due either to changes in SMOG, or more complete knowledge of the behaviour of the FR80.
A copy of Mike Archuleta's 3-D Package was obtained from Livermore in April. This is an extension of the University of Utah software which allows a number of objects whose surfaces are polygons to be displayed. with hidden line elimination. It is also possible to shade the surfaces, colour them and to add contours. The package claimed to be machine independent but this was not the case! Considerable time was spent rewriting the system to run on the 1906A. It is now in a state where it handles the hidden line elimination and contour generation. A new version has recently been obtained from Livermore which corrects a number of small bugs. The aim in the next quarter will be to get the shading algorithms to work.
This work has involved meeting various prospective users and helping to convert existing programs. Solving 1906A graphics queries has taken up a considerable amount of time.
A further aspect of the initial FR80 support work has been the proofreading of new manuals, amendments, supplements, etc.
Work on SMOG is now virtually complete, 1906A and 360 versions being more or less compatible, and enough experience has been accumulated for us to feel reasonably confident of its stability on the 360. As it stands, the package will produce data in standard FR80 format on magnetic tape or disc with the appropriate LOADGO header information. SMOG requires about 50K bytes of core, about one third of it having been translated from FORTRAN into 360 Assembler.
It was planned from the first that SMOG should form the basis of any FR80-directed graphical package and it appears that this has been quite satisfactory for SCFOR, HRMUG and SPROGS. It is intended to use SMOG for POLYGRAPHICS as well. One user (Professor R W Hockney) has expressed the wish to direct graphical output to two cameras simultaneously - not a very straightforward process using SMOG, but given the fairly flexible nature of the 360 implementation, not impossible. The best alternative to the simultaneous output to two cameras would be to employ VIEW$ or some similar program to scan the FR80 tapes after production to pick out selected frames.
This program for interpreting FR80 orders from disc or tape has been tidied up and responds to most of the available graphical orders, routing the interpreted pictures through MUGWUMP to the ELECTRIC filestore. It proved invaluable in the early stages of testing SMOG by saving the ferrying of large numbers of tapes backwards and forwards between RL and ACL. The optional monitoring of non-text or -vector orders provided by VIEW$ has also proved useful.
The source code of the latest 1906A version of SPROGS has been transferred to the 360 and conversion work is in progress. Much of the IBM-specific code was written when the earlier version was implemented early last quarter so that the new implementation is not expected to take long.
This package has been moved over and the appropriate changes made to make it run on the 360. It is available for use from a library although testing of some of the logarithm options is still in progress.
Members of C and A Division of RL are working on various aspects of graphics for the FR80. Dr Pett has converted the MUGWUMP output program to produce FR80 output via SMOG (HRMUG) and this system now needs testing on the FR80 itself. A graphics spooling system is proving to be the remaining bottleneck, requiring a routine SP£PUT that will write graphics data not only to disc or tape, but also to the HASP spool. The design and function of SP£PUT and accompanying routines has entailed considerable thought and discussion as well as programming effort on the part of C D Osland of RL. Coding and the necessary modifications to HASP are under way so that graphics spooling should be available early in the next quarter. The despooling program has been largely completed by Dr M J O'Connell at RL and the analogous routine SP£GET has been written and tested.
An automatic accounting system is under construction for the FR80. All graphical jobs run on the FR80 are preceded and followed by logging jobs. These jobs supply statistics concerning the graphical job sandwiched between them to a special logging program which writes the statistics to a disc file. The recording of the statistics supplied by the FR80 logging jobs is now working. The collection of certain data generated by the FR80 itself during the processing of graphical jobs has yet to be implemented. Manual entries may be made to the log via the operators' console to record any exceptional circumstances encountered during the, processing of a job. The contents of the log may be displayed on the operators' monitor display.
Periodically the log file will be transferred to the 1906A, via magnetic tape, where the log will be processed to provide the required accounting data. Transference of files from the FR80 to the 1906A via magnetic tape is now possible. The 1906A log processing program has yet to be written.
A program has been provided on the 1906A to list source files from a 7 or 9-track FR80 Dump Tape. Options include the ability to list all files, specific named files, or all files in a given directory. The program can be started by the 1906A operators, so that source listings of developing programs can be obtained reasonably quickly. Since the output is directed to the GEORGE filestore, the program can be used to transfer files from one machine to the other (for example, the FR80 log file).
During this quarter, a source listing of one of the Displayers was received, and various software updates performed. A £ sign was designed and incorporated, and much work was done in understanding the basic design of the package (if one can use the term design).
Software simulated characters were included in all Displayers. The tape formats for character size, height, etc were extended to allow larger numbers to be input. These large numbers are trapped by the software, which then simulates the characters by reading the hardware definitions and using the vector generator instead. After some difficulty with the Hardcopy camera, and with the surprising way that the program copes with the required inversion of characters, the necessary modifications were made. However, it is noticeable that the fonts are not particularly elegant when viewed at large sizes. DVR has done some experimental font design, trying to produce large characters using the character generator. However, these appear to break up when they are approximately one inch high on the monitor screen.
To avoid the need for repeated re-reading of tape to ascertain density, two parallel systems have been provided - one for 7-track, and one for 9-track. This, of course, has once again multiplied the number of Displayers required, and made the planned re-write that much more necessary. The magnetic tape decks have been giving some odd results recently, and work is in progress to investigate whether more diagnostics are needed, and also how the current Displayer handles tape errors.
A programming course was held at ACL for the FR80, and most of the branch attended. A few problems were fixed, but there are a considerable number of queries still outstanding.
The above has been written in the absence of WDS. A fuller account will appear in the next Progress Report.
The current state of the FR80 software, together with requirements for maintenance and new facilities, suggest that a new FR80 Displayer should be written to handle all cameras, and to incorporate the fonts, both tape drives and all accounting and logging. The design of such a program has been started. It is likely that development can take place on the PDP15, where time is available at present, since the build-up of work on the FR80 will make program development more difficult. It will be necessary to provide support software for such a venture.
It is worth recording that the writing of the logging program has convinced me that the principle of one man writes one module is a bad practice, and that the small programming team approach advocated by Mills (IBM Federal Systems Division) has much to recommend it when combined with good design and construction disciplines.
A system has been set up whereby source files on the PDP15 can be punched on paper tape, and read into the FR80 Editor. Thus source can be prepared on the more sophisticated machine, and only minor corrections performed on the FR80. This is a temporary system, which will be superseded by the magnetic tape transfer system.
Now that the FR80 is providing a service to users, little machine time is available for software development. Such time as is available often occurs at short notice and is of short duration. In addition, the FR80 Editor is unreliable - it sometimes loses files. These factors combine so that the task of making lengthy additions to, or major edits in, FR80 source files has become the major headache in performing software development on the FR80.
In order to alleviate this problem, a program is being written which will run on the PDP15 and which provides for the transfer of information between standard PDP15 files and FR80 dump-format magnetic tapes. In this way, program text preparation may be performed on the PDP15, using the editing facilities available on that machine. The source text thus prepared can then be rapidly transferred to the FR80 for compilation, testing and debugging whenever machine time is available. Changes to the source text may be made in the FR80 and the updated text copied back to the PDP15 for further development. At present, files are being transferred successfully from the FR80 to the PDP15, and transfers in the opposite direction should be possible within the next few days.
Although within acceptance specifications, the FR80 colour system requires evaluation and adjustment before repeatable colour film output can be expected. The physical processes are subtle and their measurement is often subjective but results are encouraging and work continues.
The user-orientated colour control subroutines have been prepared for inclusion in the graphics packages when the FR80 filter adjustments are completed.
Some experiments with film and slides have been carried out.
Work has begun on altering the graphics overlays of XRAY to call SMOG. In addition, the ORTEP system is being changed. The greatest problem is likely to be the organisation of lower data and the distribution of the graphics routines in the overlays.
PIGLET is a set of FORTRAN and MACRO subroutines which accepts five format commands from a teletype or other source device and passes control and arguments to matching applications procedures. Command syntax and argument retrieving procedures are identical to PIGS. No display is maintained however, and the only command source allowed is the peripheral attached to DAT slot 3 (usually the system teletype). Command names are associated with application procedures at run time using special FORTRAN subroutines.
PIGLET is useful for debugging applications procedures to be used with PIGS or for implementing non-graphical interactive applications. Because it is not overlaid (size about 204810 words) DDT may be used to dynamically debug applications procedures. The available command set may be redefined at run time to control interaction and form a primitive menuing facility.
A new PDP15 user (M Stapleton from RCA) has been instructed in the use of PIGS. He is interested in textile design, using interactive graphics.
A program has been written for the PDP15 computer to enable one to view magnetic tapes written by the microdensitometer. The output from the program can be directed either to the VT04 display, the Tektronix display or to the DEC-writer. A coarse view of the original photograph is displayed initially but smaller regions can be defined on the VT04 by positioning two crosses, which define the corners of a rectangle, using the spark tablet.
One problem with the present system is the time taken to read the data from magnetic tape to a scratch, random access file on disc. It is hoped that this process can be speeded up by writing the disc access routines in assembler.
A program has been adapted and enhanced to run on the 1906A computer to generate cine films of molecules. Output from the program can be directed either to the FR80 for the final film or to the Tektronix or lineprinter for debugging purposes. Molecules may be globally rotated about any orthogonal axis or partially rotated about any bond in the structure. Labels may be selectively placed on any atom and display parameters may also be altered by suitable commands.
A film on the biochemistry of vitamin D3 is being made in collaboration with the Endocrine Unit of the Royal Postgraduate Medical School.
Culham have approached ACL with a view to running their workload on the FR80. They are being given sufficient details to alter their software to suit our system and it is hoped that this will lead to further cooperation.
Little effort has been put in this quarter from the ACL side. The hardware fault which has persisted from the last quarter has continued to be investigated by ICL and DEC.
It has been complicated by other faults appearing and going away and it is difficult to detect because of its intermittent nature. The failure rate varies from 1 in 9000 to 1 in 100000 blocks.
Since the fault is intermittent and recoverable it is hoped that more effort will be spent on completing and documenting the software in parallel with the efforts to cure the fault.
Computer Animation at ACL Westfield College. Univ of London, F R A Hopgood
FR80 - given at Image Processing Conference at ACL, F R A Hopgood
Computer Animation at ACL, Simon Fraser Univ. Vancouver, F R A Hopgood
Graphics at ACL at IUCC Workshop, Univ of Cambridge, R E Thomas
Skittles Evening. Hare and Hounds. Chieveley, May 9
