In future this section will produce a progress report once a quarter. Its major purpose is to keep members of the Laboratory informed of what this Section is doing. The literary standard will not be high. It may well be disjoint. It is not intended that this document will have any distribution outside the Laboratory. Initially distribution will be to individual members of the group plus a few others. Anybody wishing to have their name added to the distribution list should contact me. At the time of writing, the members of this section are as follows:
Although P M Nelson is formally a member of the Support Group, his work places him in close contact with the above section.
We have two new software packages nearly in a state where they can be released to the public.
D-MAC Package (GAE) The D-MAC Pencil Follower allows a user to input graphical information. The D-MAC has a pencil which can be moved over a piece of graphical information (for example, a map or engineering drawing). As it moves a continuous stream of X and Y coordinates can be output on paper tape. Alternatively another mode exists where selected X and Y positions are output under user control.
The above package has mainly been designed to try and ease the input of this paper tape to Atlas. The punch does make errors occasionally. The D-MAC package attempts to correct errors of this kind by having a formalised way of outputting the data. Under the continuous mode of operation, any hesitation on the part of the D-MAC operator will generate a stream of X and Y's all with the same values. Redundant information of this kind is deleted by the package. One of the major problems with using D-MAC is the breaking down of a stream of X and Y's into meaningful units. The X and Y's could be a continuous track, a set of pairs representing lines or even a set of distinct points. The package allows a user to define the type of input that will be following and name it. It is possible to update subsets of the data at a later time.
CAMP and CAMPER (FRAH) Sherwood Anderson of Syracuse University has produced two very simple packages for the production of two and three dimensional films. We managed to obtain a 360 version of these programs which we were able to get working on the 360 at the Rutherford Laboratory with little trouble. The programs have now been converted to run on Atlas and it is hoped to issue a user's manual in the near future. There was a certain amount of work to be done on the output side as a number of 360 Fortran conventions had been used. In addition our standard output which identifies the information to the SD4020 operator had to be added. Even so the amount of work required was only about one-man month. Comparison of times for one long run on Atlas and the 360/75 were 7 minutes compared with 3 minutes (using Fortran level H).
We hope that these packages may be of value to the person not wishing to get involved in the details necessary to understand our larger and more sophisticated packages. Both CAMP and CAMPER provide a small character set and a basic set of objects which can be displayed and manipulated. Additional objects can be defined by the user. The 3-D Package, CAMPER, fills a gap in the facilities we offer at the moment.
It is likely that these packages will also be made available on the 1906A so that programs can be run on any of our three main machines next year (Atlas, 1906A, 360/195). We may well attempt to get the package working on the PDP15. It is small enough that it may just be feasible. The user inputs data cards to the basic package. There is, therefore, no need for him to know any programming language at all.
The PDP 15 arrived in October about one month late. The VT15 display however did not arrive with the PDP 15 and it has still not arrived although we are expecting it any day now. DEC seem to have had a number of problems with the display which has been the reason for the delay. Some of these are local to the 50 cycle version of the display. REDAC Ltd have installed the first VT15 in this country and I think they have uncovered a number of faults which we hope will have been ironed out by the time our display arrives.
As the display has not arrived, we have been unable to get to grips with the basic graphics work on the PDP 15. In some ways this has been a good thing. It means that we have spent more time getting familiar with the basic software. Our intention is to attempt to produce a number of useful but distinct programs using the display and basic software provided by DEC before commencing the display package that will be used in conjunction with the 1906A. The main reason for doing this is to get familiar with the DEC software and also explore the ergonomics of using the display. None of us have much experience in interactive graphics and I feel we shall make a number of mistakes if we attempt to produce the basic software immediately. Also there is no immediate hurry as it is unlikely that the actual interface to the 1906A will be completed and working before the last quarter of 1971.
The work done on the PDP 15 can be itemised as follows:
Listing Program for Atlas (PMN) As we have no lineprinter on the PDP 15, obtaining a listing of any sizeable file of information is nearly out of the question using the teletype. The basic PDP 15/30 software uses the DECtapes as backing store to hold source files. However the software does allow the 7-track industry compatible magnetic tapes to be used in place of the DEC tapes. Thus it is possible to store a program in source form either on DECtape or magnetic tape. Similarly the listing produced by a compiler can be directed to the magnetic tape if the user desires. We therefore decided to write a program which would list a set of files which had been stored on magnetic tape using the basic PDP 15 software. This is now just about working correctly. The user can select individual files to be listed on Atlas or alternatively the complete tape can be listed.
A number of problems have been encountered during this work. The basic software generates the magnetic tape at 800 bpi. It was therefore necessary to modify the basic magnetic tape handler to change its standard output to 556 bpi. A bigger problem was that the format of the file on the magnetic tape differed depending on where the file came from. Listings from different compilers had different formats. This is not defined in the manuals and it has taken us a while to sort this out.
VTPRIM. The Display Software Package (FRAH) We managed to get a listing of the basic software package to be provided by DEC for the display. It has not been released so far. In order to get some experience of using it before the display arrived, this has been punched up and modified so that, although it produces display files, no attempt is made to process them using the non-existent display. We have uncovered a number of bugs and also we have been able to make some evaluation of it. It is not very impressive and we must make a decision soon whether to go ahead and use it or alternatively to generate a new package of our own. To some extent this will depend on how much additional software (which depends on this) we can expect from DEC. The display package provides a number of facilities for generating both main and sub-files. There is so little difference between the two that a lot of this duplication could be avoided. It is especially annoying as some facilities available for one type of file is not available for the other and vice versa. The method of editing files is also very crude. Recently a later version of the package has been obtained. A number of bugs have been corrected (some still remain) while others have been introduced. The two types of files differ even less now than they did before.
To aid us in examining display files, a dump routine has been written which lists the display file in octal with mnemonics for the display instructions.
SD4020 Output of Display Files (FRAH) Instead of photographing the display screen, a program has been written which will generate the necessary SD4020 instructions on magnetic tape to produce an equivalent display. This will enable the user to get snapshots of particular displays on hardcopy or microfilm using the SD4020. This program, at the moment, does not simulate all the display orders and also assumes the display file was generated using the standard FORTRAN software, VTPRIM.
Analysis of Fortran Object Code (GAE) So far, most of the programs written have been either in FORTRAN or the assembly language. Most of the basic software assumes that programs have been written in this form and there is considerable savings to be gained if we stay within the basic framework of the LOADER. However, if the code produced by the FORTRAN compiler is inefficient either in time of execution or storage required, it may be necessary to write in a lower-level language. We have been making a detailed study of the code produced so that an estimate of the efficiency can be made. It is possible that we produce a PL language compiler that fits into the basic system.
The basic loader and chain system is quite flexible and does allow the user to overlay chain links in a reasonably sophisticated manner. It tends to be rather slow, when changing links, if the individual chains are stored on DEC tape. These system overheads would not be too noticeable if a disk rather than DEC tape was the backing store.
Display of SD 4020 Tapes (JRG) There is a considerable bottleneck on the SD 4020 in getting test runs done. At the most two runs of a program are possible per day and this frequently is only one. We are therefore generating a program for reading magnetic tapes produced on Atlas for the SD 4020 and displaying this output frame by frame on the VT15 display. This allows us an immediate viewing of SD 4020 output and also provides us with a means of verifying that an SD 4020 tape has been produced correctly. This work has, of course, been held up by the late arrival of the display. It is intended to extend the program to allow a certain amount of editing of the information on the SD 4020 tape.
Fortran SD 4020 Package (PMN) The current Atlas FORTRAN package for the SD 4020 is being implemented on the PDP 15. This will give us some estimate of how fast the PDP 15 is compared with Atlas. If the difference is not too great we may be able to get some genuine work done on the PDP 15 in its stand-alone mode.
Basic Systems Work Everyone has had to do a certain amount of evaluation and generation of the basic software. GAE has been in charge of generating and updating both the Basic Monitor System and also the Foreground/Background System. His experiments show that the Foreground/Background System is unusable with the 16K of core we have available. Consequently, unless we obtain at least another 8K of store, it is unlikely that we will use this system at all. This does, of course, mean that we shall continue with only one person using the PDP 15 at a time. This would cause problems once the work has built up. We feel that with additional core it would be quite feasible to have two people using the PDP 15 at the same time assuming one of the jobs did not use too many of the machine's resources.
We have made very few changes to the basic system. The MTA magnetic tape handler has been modified to have odd parity, 556 bpi as its standard. We are trying to get a handler from DEC for the second teletype. It is strange but true that the second teletype can only be used with the Foreground/ Background system. Consequently we have made virtually no use of it at all.
The D-MAC interface arrived recently and PMN has been overseeing its installation. The interface makes the D-MAC look much the same as a paper tape reader to the PDP 15. We had a number of problems when installing this. The major problem was ensuring that the interface would run at the maximum speed of the D-MAC. This is now working correctly. To allow us to use the D-MAC with the basic software it is necessary to write a handler for it which honours all the possible signals. This is similar to the basic paper tape reader handler and GAE is making the necessary modifications at the moment.
Maintenance of the PDP 15 system has been split up with GAE looking after the software, PMN the hardware, while JRG is ensuring that the set of manuals resident in the PDP 15 room incorporates all the Change Notices.
So far we have not had many hardware problems with the PDP 15. The paper tape reader and punch do not appear to be very robust however. The DEC tapes have given little trouble apart from a module having to be replaced in one and a second requiring sane adjustment. The only problem with the basic machine has been an intermittent fault on the automatic priority interrupt which only appeared when the temperature rose above 75°F. This was found by the engineers when they were adding the D-MAC interface with the air-conditioner off.
We feel that apart from producing software for other people to use it is important that we continue to use the software ourselves. Consequently we have attempted to produce some more films on the SD 4020. It will take us a long while to convince our University users that they are quite capable of making films themselves and that it will improve their teaching in certain areas. Any films which stimulate them to use the equipment is therefore useful. The user who produces a film to demonstrate the time dependence of his results sees the use of the SD 4020 much more clearly. It is the educational use of the SD 4020 film which is difficult to get across.
We are attempting to generate a number of films to aid the teaching of Computer Science. We chose Computer Science as that is our profession assuming we have one. Our first efforts consist of two films on Syntactic Analysis. The first one illustrates the different methods of Syntax analysis in an informal manner. The second gives, in more detail, the formal algorithms for the Top-Down methods. Most of the programming for the first film was done by Mary Stapsley in the summer. The second film is under construction by JRG.
However we have not been able to get a single copy of the first film even though we have been trying continuously since August. The generation of films using Atlas and the SD 4020 has been at a standstill during the whole of this period due to faults on both Atlas and the SD 4020. We have had a number of minor faults on the SD 4020 which has made it difficult to get any long running piece of film produced by the SD 4020 with any confidence. However, these have come and gone. They are annoying but not insurmountable. They include random unscheduled forms flash operations, the magnetic tape dropping out of ready and losing information, misaligned vectors and camera jitter.
However the major problem has been that during the whole of the last four months the AR (advance repeat) option on the SD 4020 has not been working. Basically, if a sequence of operations on the SD 4020 are to be repeated a number of times, it is possible to generate only one copy of the orders on the magnetic tape and conclude with the AR order. This indicates to the SD 4020 that the tape must be backspaced (once the information has been read the first time) to the start of the sequence (indicated by an earlier AR order) and the information reread. This sequence can be repeated up to 31 times. This allows a considerable saving in magnetic tape used and also some saving in computer time. The computing time saved could, for example, be of the order of 10% while a job having a number of static film sequences might require only 5 magnetic tapes using AR instead of 15 or 20 without AR.
Some progress towards solving the fault has been made but there is still little chance that it will be solved in the near future. Initially both the magnetic tapes on Atlas and the SD 4020 were not set up correctly and this made it difficult to get any clear indication what the fault could be. A variety of faults have appeared and, so far, all have been attributed to the tape deck. The basic problem is that when the magnetic tape is backspaced it either goes back too far or not far enough. In addition the SD 4020 sometimes gets in a state where the tape is being oscillated backwards and forwards at a fast speed over a short section of tape. This usually ends up by ruining the tape. Consequently the current fault is often aggravated by not having complete confidence in the reliability of the tape. No doubt there is a number of faulty tapes in the system which will have to be removed.
Initially tests on Atlas showed that both decks were set up badly. It was impossible to backspace tapes with any degree of confidence at all. For example a program was written in Algol to exercise the tape in a random manner. One backspace of 250 blocks ended up with the tape 34 blocks away from the position it should be. Another time a request to move the tape back 9 records caused it to advance the tape by 8 records! Some progress has been made. The engineers have been able to get both decks into a state where the rather limited tests that can be done from a user program work correctly. However, as the Atlas supervisor is between the user program and the tape deck, it is difficult to produce a test in a higher level language that will simulate the real time functioning of the deck on the SD 4020.
At the time of writing both decks on the SD 4020 are consistently bad but different. Both perform correctly on Atlas. One deck will always backspace too far on the SD 4020 while the other does not backspace far enough.
During the last three months both FRAH and PMN have spent a large amount of time modifying the basic display packages and writing test programs in attempts to get round these errors but without much success. We have attempted to prove or disprove a number of theories put forward by the engineers. For example it was thought initially that short records on the tape were being missed. We therefore changed the software to make all records the same length by padding out short records with NOP's. Later it was thought that the tape was being worn out due to the large amount of movement over short lengths of tape when the AR facility was being used over one or two blocks. This was removed by changing the software so that the tape was never backspaced the maximum number of 31 times. Instead the maximum allowed was reduced initially to 20 and later 10 times without curing the basic fault. Also the number of records that the AR backspaced was set at a minimum of 10 records. This again had no effect. One of the latest suggestions is that backspacing over large distances is the problem!
Due to the way the AR facility works, if the tape goes back too far it will get stuck in an endless processing loop and there is nothing the software can do to remedy this. If the tape does not go back far enough, it is still possible to get correct output if the first few records at the start of an AR sequence contain only NOP's . We have attempted to run with the software generating one and later two dummy records at the start of each AR sequence. However this has not been sufficient and more than two records usually get missed eventually when backspacing 10 times in an AR sequence.
The current state is that neither the ICL engineers, who maintain the tape decks nor the SD 4020 engineer can find anything wrong with their equipment. There is little hope of any immediate progress therefore. The Operations Group are, however, getting both decks completely overhauled by IBM. If the decks still produce the same results on the SD 4020, it is hoped that an SD 4020 engineer more familiar with the AR option will be flown in from Paris.
If neither of these actions solve the problem then we shall have no choice but to abandon using the AR facility. It is unfortunate especially as it worked without any trouble for over a year prior to this.
If we have to do this, it will mean that we shall have to increase the number of magnetic tapes in circulation by possibly 50%.
The number of tapes required is aggravated by the inability of our own photographic processor to produce reasonable output without overstriking every line at least once. This increases the amount of tape used by a factor of 2 and also increases the computer time used considerably.
A number of projects of low priority are being followed up in addition to those outlined above. GAE is attempting to get the SPACE WAR game working on the display when it arrives. We have a copy of a program written for the PDP 9 and a 340 display. This will be useful for Open days and showing visitors. GAE is also interested in the hidden line problem. Basically all our software at the moment does not eliminate hidden lines. A number of algorithms do exist and we did manage to obtain a PDP 10 program. However, it appears to be so machine dependent that we have abandoned an attempt to get it working. Instead we are attempting to get debugged software from other sources.
It looks as though the SD 4020 will again require a considerable amount of our time. Our hope is that the service will be back to normal by the end of the quarter even if it means abandoning the advance repeat option. We should have completed a number of minor programs on the display by the end of the quarter and be in a position to define the PDP15 side of the combined 1906A-PDP15 system. This has been named SPROGS (SD 4020-PDP 15 Rapid Output of Graphics System).
These are mainly for information in the Section itself and are not intended for any wider distribution.
