Although it is possible to run the Atlas emulator without a simulated supervisor tape, in that condition the system is only able to run programs written in Atlas Basic Language (ABL). To extend the reach of the emulator a supervisor tape (or disc – everything here applies equally to discs) is needed.

Should the issued Supervisor tape (or the fixed store) be lost or corrupted, a set of jobs is provided to reconstruct the missing elements. In the absence of a Supervisor tape, the only languages available are ABL and FABL. But if the fixed store is missing or corrupt, most extracodes are unavailable and programs which call them will fail.

Jobs to create the missing elelemts are present in the Windows directory compilers. The procedure is somewhat convoluted because it is essentially a bootstrap — one in which the later steps depend on completion of the earlier ones and also because the Supervisor tape cannot be written to while it is in use.

But first we should ensure that the file holding the simulated Atlas “fixed store” is present. The fixed store is held in a Windows file fixedstore.fxd which is present in the same directory as the emulator binary file atlas.exe. fixedstore.fxd can be constructed using a job compile fixedstore.rtf using the FABL compiler – a slightly modified version of the built-in ABL compiler which can be used without a Supervisor tape being present. The FABL compiler has no other use.

The next step is to create some empty Supervisor tapes. Normally this would be achieved using the MAGUTILS “compiler” but since we are constructing the Supervisor tape from scratch a job create new supervisor tape.txt is provided. The program therein will mark any tapes declared in the job description as Supervisor tapes. It is set up for SUPERVISORTAPE0, SUPERVISORTAPE1 and SPECIALTAPE. These names will be assumed through this procedure description, though the user is free to change them.

We can now make a start on creating a few compilers. The jobs compile abl and fabl compilers.txt, compile octal compiler.rtf and compile restart compiler.rtf should be run to create four new compilers on SUPERVISORTAPE0.

Before we can proceed further, we need a copy of this tape. As before normally we would use facilities within the MAGUTILS compiler, but it does not yet exist so a job copy supervisor tape and number cc.txt should be run to copy our four new compilers to SUPERVISORTAPE10. Once this has been achieved we can nominate SUPERVISORTAPE1 as the active Supervisor tape. This gives us access to the OCTAL compiler which we need for the next stage.

Next the job compile compiler compiler compiler.rtf may be run to create the CC compiler on SUPERVISORTAPE0. Note that this is a very long job which may give the erroneous impression that nothing is happening.

Once again, we need run the system without a current Supervisor tape and then copy the contents of SUPERVISORTAPE0 to SUPERVISORTAPE1 using copy supervisor tape and number cc.txt. This time the program will also renumber the new CC compiler to 6 (both copies) which we need for next step.

After again nominating SUPERVISORTAPE1 as the current Supervisor tape to give access to th CC compiler, we can run compile magutils.rtf to create the MAGUTILS system on SUPERVISORTAPE0.

Next we can add the SPECIAL compiler and the two offline spooling programs with the compile special compiler.txt and define offline spoolers as compilers.txt jobs.

The final step in creating the new SUPERVISORTAPE0 is to renumber all the compilers using the renumber compilers.txt job following which, copy supervisor tape and number cc.txt can be run yet again (without a current Supervisor Tape) to replicate everything to SUPERVISORTAPE1. After which either copy should be used as the Supervisor tape.

Two further jobs compile corrected cc compiler.rtf and compile service compiler.txt should be run to create a “corrected” copy of CC and the SERVICE compiler on SPECIALTAPE. At the time of writing SERVICE is still under development so it is most convenient to invoke it using the SPECIAL compiler created earlier. Note that compiler numbers on specialtape are irrelevant.

The ABL and FABL compilers do not really exist on the Supervisor tape, being “built-in” to the emulator. But nonetheless, there are entries for these two items on the Supervisor tape. In practice these compilers are “stubs”, containing but a single instruction a special (inauthentic) form of the CALL COMPILER (1147) extracode. When ABL or FABL is requested in a job description, the stubs are loaded from the Supervisor tape in the normal way and the special form of CALL COMPILER is detected by the emulator causing the built-in compiler to be invoked.

In the absence of a nominated Supervisor tape, a different mechanism is employed which causes direct entry to the built-in compiler.

Although the ABL manual is an excellent source for much of the detail of Atlas, the nature of the Supervisor tape is less well defined. We know that each compiler occupied a contiguous number of blocks on the tape and that each time a new job was run the tape would wind to the appropriate block and then load the requested compiler. Beyond that, the best source of information is in section 12.9 of the ABL manual, specifically the description of the CALL COMPILER (1141) extracode. Here we learn that the extracode requires the name, start and finish block numbers of where the compiler is “now” and the target starting address. We also learn that the supervisor is, in fact, logical tape number 127. No mention is made of the “entry point” nor of the “compiler number” both of which are used by the CALL COMPILER extracode.

A moment’s thought suggests that the supervisor would need to be able to locate a requested compiler on the tape (using the name as an index) and to know how many blocks it occupies and what addresses to use. The absence of any information concerning the compiler number has forced the invention of an imagined property in the compiler title block. As for the entry point, it seems reasonable to suppose that the default entry point must be one and the same as the starting address

The nature of the index on the tape does not seem to be documented. However, the documentation of the CALL COMPILER extracode (in the 1967 update only) suggests the presence of a “title block” preceding each compiler. This information is confirmed by the source code of a very early (i.e. pre-dating the availability of the the DEFINE COMPILER (1147) extracode) implementation of the COMPILER COMPILER from which the format of the title block has been derived. It seems reasonable to suppose that, when the DEFINE COMPILER extracode was introduced, the format of the Supervisor tape would have remained the same, there being no good reason to change it.

It is assumed that at system startup (a fairly rare event on the real Atlas) the Supervisor had to read all the title blocks on the Supervisor tape to create an index to the compilers.

FORMAT of the title block —

• halfword 0.0 = 0
• halfword 0.4 = first half of compiler name
• halfword 1.0 = second half of compiler name
• halfword 4.0 = compiler number (assumed)
• halfword 9.0 = block count (excluding title block) in bits 1-11 + 0.4
• halfword 9.4 = block count + 1 in bits 0-10
• halfword 10.0 = virtual store address into which to read the next block of tape
• halfword 10.4 = virtual store address into which to read the next but 1 block of tape
• etc.

It is assumed (albeit not positively known) that halfword 9.0 is used to indicate the relative position of the next title block. The purpose of halfword 9.4, on the other hand, is a mystery.

Thus, it will be appreciated that the Supervisor tape contains a chain of title blocks, the intermediate space being occupied by the compilers themselves. The chain must, perforce, be terminated in some way and it seems sensible to suppose that a compiler title block containing a compiler name of octal 00000000 00000000 might have fulfilled this need although there is no evidence to support this.

A further inauthentic embellishment is that a compiler name of eight spaces represents a gap in the supervisor tape from which a compiler has either been deleted or has outgrown its allocated space and has been moved to the end of the tape.

The DEFINE COMPILER extracode is able to add a new compiler on tape and to overwrite an existing compiler (subject to there being sufficient space).

With a built-in ABL compiler, the emulator is, of course, able to function without any Supervisor tape whatsoever. Adding support for the Supervisor tape requires that the emulator user has the ability (from the emulator menu) to nominate a file to be the Supervisor tape, to change it or (by declining to choose a file) to cease to use the Supervisor tape altogether. Similarly, a drop-down list of each the available compilers together with its compiler number is implemented within the menu system.

The DEFINE COMPILER extracode is able to add a new compiler on tape and to overwrite an existing compiler (subject to there being sufficient space). Where possible the existing compiler number is not changed but in the absence of any other information, the DEFINE COMPILER extracode assumes that a new compiler should be given a number one higher than the largest compiler number already present on the tape.

It is not known whether any check is made that a Supervisor tape really is a Supervisor tape. but it is convenient to do so, so the first two words of block 1 of the tape contain the text “SUPERVISOR TAPE ”. Thus the start of the chain of title blocks begins in block 2. In the real Atlas, it is known that a block number of around 1000 was used, but this was different in each installation and, as yet, no attempt has been made to replicate this.

Readers will have noticed that a great deal of (informed?) guesswork has been employed in this area. The author would be grateful to receive any clarification.