Preserved source text


This historic material accessible via this webpage is only presented as available for academic study, and it should only be used for this purpose. All of the material is many decades old, and surely no longer of any commercial value. Sometimes the ownership of copyright is unclear. Some of the authors are dead.

Anyone who believes that they own copyright in something which is here and believes that it should not be here, please get in touch, and we will take it down at the earliest opportunity. Equally if it is felt that the material can stay, but should be accompanied by a more comprehensive statement of ownership, we would be glad to oblige.


This is an embryo archive of material acquired by the CCS, with particular stress on the preservation and presentation of material that pre-dates the ASCII, ISO and EBCDIC character codes. The very best form of presentation provides the means to execute the code, and also to see it represented on screen or on paper looking as it would have done to the people who wrote it in the first place. As regards preservation, we need a representation that permits electronic analysis. Where this analysis is carried out using original software (such as compiling old software with a contemporaneous compiler), there is a need to present the original character code.

Where source text survives in electronic form, there is a great deal to be said for preserving the original byte stream as a master copy. From this it is then possible (even quite easy) to generate other more convenient forms. We have found it convenient to have a 1:1 mapping between characters of the original alphabet and something in wide use today. We have found that the subset of UTF-8 that is represented in a single bye allows transfer between different platforms without corruption. This does mean the £ is not allowed, whereas $ is.

Where source text only survives in the form of hard copy, we can readily keep images of the listing, but if we are to achieve our ambitions of execution we need to use OCR and copy-typing to make a form suitable for further processing.

Further processing is much facilitated by the availability of documentation, the preservation of which is also an ambition.

With these considerations in mind the next sections look at several examples.


The English Electric (EE) KDF9 had two operating systems in production use: the original EE system, which was developed by Leeds University and NPL into Eldon2, and EGDON which was developed from scratch by Culham Laboratories and resembled the system on an IBM 7090. We have not been able to preserve any of the EGDON system.

The original EE system had different representations for characters on paper tape and on line-printer. Paper tape was prepared on electric typewriters called Flexowriters, which had a richer set of characters than did the line-printer. Underneath this much of the software used an 8-bit code of Algol Basic Symbols. Here is a table showing the 8-bit codes (in octal) and the KDF9 paper tape representations of the set of Algol Basic Symbols. The character manipulation facilities of the machine were not very extensive, but such as existed (e.g. binary to decimal conversion) were based on 6-bit characters. Although the paper tape was 8-track, it was used in a curious way such that each paper tape character produced 6 bits when read into the store. There was a two shift system that allowed the representation of around 100 different characters.

We have the source text of the Paper Tape Whetstone Algol system, the Paper Tape Usercode Compiler, and the Kidsgrove Algol Compiler which operated within a magnetic tape file system (POST) using the 8-bit Algol Basic Symbol code. All three were products of English Electric. A later version of the Kidsgrove Algol Compiler operated on EE's PROMPT filing system, which used the same 8-bit code and a file format with many similarities to that of PROMPT.

We also have the author’s listing of KAL4, (KDF9 Assembly Language number 4).

Listings for browsing

We have developed an assembler for KDF9 Usercode (the machine's assembly language) which processes source code in the UTF-8 subset, and produces a printer-style listing, which we then process into HTML so as to show all the characters of the KDF9 Flexowriter. In addition, all references to subroutines contain a hot link to the subroutine.

In some cases there are links to the original printer listings (e.g. Paper Tape Usercode) and in one case we have links to the original authors' flow diagrams (viz: Kidsgrove Algol brick 22).

1:1 mapping for processing

These are the versions that are used as input to our KDF9 assembler (kal3.c and kal3.y).


We have scans of some key pages of various manuals, and a system description which has been processed and can be seen here. The KDF9 Service Routine Library Manual (4 volumes) can be seen in part here.

Execution — Algol and assembly languages

We have an on-line facilities for execution of the KDF9 compilers and assemblers, where you can try your hand at Algol60 programming, or venture into KDF9 assembly languages.

KDF9 Time-Sharing Director

We have a few surviving examples of the KDF9 Time-Sharing Director which are not yet in a state for easy study:

Leo III software — surviving as printer listings

NameNumberCSV filePaper
Master Routine09001 CSV file tape click
Master Routine
Generator Program
08004 CSV file tape click
Intercode Translator 08000 CSV file tape click

The Leo III computer was a direct descendent of the original Lyons Electronic Office, the world's first business computer. We have 3 of the original systems programs, the master routine, its generator program and the Intercode translator. All 3 of these are written in Intercode, which is a language composed almost entirely of numbers. Fortunately it has a comment convention which is quite liberally used.

Listings for browsing

These listings are the output from the Intercode translator, which have then been processed to include links to subroutines and representation of the Leo III character set. The characters that we have used for the 10 and 11 characters are somewhat approximate.

Leo IIItypescript 
£ppound sign
>gright arrow

1:1 mapping for processing

There is only one case of letters in the Leo III character set, normally shown as upper case. In order to have just one 8-bit character for each character, the non-ISO characters from the Leo III are represented as per the table on the right.

The original surviving listings were copy-typed on a spreadsheet, and then saved as .csv files. These were then processed to make them into representation of the original paper tapes that would have created the surviving listing.


We have Leo III documentation processed into searchable HTML. Acces is via this page.


We have an on-line facility for execution of the Leo III Intercode system, where you can try your hand at Intercode programming.

Additionally, you can download a demonstration to your own machine and run the Leo III Master Routine, load the Intercode Translator, and then translate all three program sources. It then runs the generator program to create a new Master Routine on an emulatoed magnetic tape, and also lots of printer output in a file.

Leo III software — surviving as paper tape

We also received a fairly mysterious box of paper tapes which are described here.

ICL 1900 software — surviving electronically

Much of the ICL material is better held elsewhere, but the ICL 1900 machines represented source text in both 6-bit code and ISO 8-bit code, and this provide us with the opportunity to address some of the issues.

We have the source code of George3, which this website serves up as plain text, looking very much as it would have done when listed on an ICL1900 line-printer. Internally the 1900 used a 6-bit code with only a single case of letters, and this code was used for representing the source text shown here. Assembly language such as this was commonly represented in upper case. There was a curious 3-shift version of this code which was capable of representing all the 8-bit ISO characters.

We also have source text of the Belfast Pascal compiler. In this case one might suspect that the writers would have used mostly lowercase if it had been available. Certainly the effect of converting it all to lowercase improves the appearance somewhat.


We have facilities for execution of George3 which can be accessed via this page. The Belfast Pascal compiler is written in its own language and poses similar questions to those encountered in dealing with the LeoIII Intercode software.