Hello, Elliott 900 Users; - past, present & future.

I've recently been gathering information about the Elliott 900 Series (920A, 920B/903, 920M, 920C/905, etc) for the "Our Computer Heritage Pilot Study" project, of the Computer Conservation Society. You may be interested to take a look at what I've managed so far, and you may be able to help me in at least the three areas marked in blue italics below.

I've written most of my contribution using MicroSoft Word 97, but the project standard is PDF. Consequently I have both formats available, complete with ZIP versions. The Word files download faster (especially the ZIP version) and they scroll slightly faster than the PDF files; the Word text is slightly clearer than the PDF text, and the line thickness (in tables & diagrams) is more consistent. The Word & PDF files differ slightly in their pagination.

The Pilot Study's own web-site only gives access to the files in PDF format. So here is a full set of links to all 5 chapters (and the ZIP versions) in Word format & in PDF format:


WORD Format

PDF Format

Chapter 1: Delivery List and Applications



Chapter 2: Systems Architecture



Chapter 3: Instruction Set and Times



Chapter 4: Software and Sample Programs



Chapter 5: List of References



(Total size of five individual files)



Single ZIP file of all five Chapters




The pilot study is only intended to cover up to 1970, which was around the mid-point of the 900-series. But I've tried to establish a framework covering the whole series. I've concentrated on the 920B/903, treating the 920A & 920M as small minus & plus deltas, and the 920C/905 as a more substantial plus delta. I mention the 18-bit spin-offs (920ATC & MC1800) and the cut-down derivatives (like the 12-bit 902, 102C, or 12/12) briefly.

The Chapter breakdown was stipulated by the project organisers. I realise that I haven't quite stuck to it, because I've put the register diagram in Chapter 3 rather than Chapter 2, leaving Chapter 2 quite sparse on "System Architecture". Chapter 3 is quite thorough on the "Instruction Set and Times": including a single table comparing instruction times across the range. Neither chapter says much about peripherals yet: (none of the peripherals described in the facts cards ever found their way into the embedded systems that I worked on). Chapter 4 on "Software and Sample Programs" covers the main software tools but I'm very aware that there's lots more that I could add: like the BOWDLER editor and the RADOS disk operating system.

I've still got my Elliott 920B/903, complete with shelves of manuals and boxes of tapes, so I'm not short of material for Chapters 2,3,4. Time has been the limiting factor: I still do have a full-time day job! So, as I said, I've concentrated on providing a framework for the pilot study. Also I've stuck to published facts: indeed, I've quoted vast tracts of documents verbatim, to meet the project's requirement "to allow subsequent researchers to check the facts in the pilot study".

Of course, not everything that is published is fact. A brochure which optimistically describes the 920B as three times faster than the 920A is just as wrong today as it was then (maybe just the logic was that much faster). And a facts card which makes the 920M appear to have twice as many instructions as a 920B has clearly been "sexed up": (they have the same number of instructions, and only slightly differing side effects). Equally, after 30 years, memories can get hazy.

The italic blue bits of text in my chapters are issues that I'm not too sure about (that maybe you can put me right on); or are in the first person which might be better recast in the third person or be removed in due course. For example, on all 18-bit machines capable of having more than 8192 words of store (namely, 920B/903 onwards), the "Store SCR" instruction (Function 11) stores the lower 13 bits (= the module-relative address) into the designated store location and the remaining upper bits (= the module number) into the Q-register. I always assumed that the module number was stored in the Q-register to facilitate returning from a "far" subroutine call in another module, but I've never seen any code which uses this; certainly MASIR's CALLG does not. Remember that jumping to another module needs /-modification, which corrupts Q.

Clearly I've had to concentrate initially on stating what the 900-series does do. A major area that I've not covered is what the 900-series does not do, which, from a modern perspective, is perhaps much more interesting. Most 900s had no floating-point hardware. The fixed-point hardware is optimised for pure fractional working rather than integer working. Division always gives an "odd" answer, never gives a remainder, and is not symmetric about zero. There are no condition codes to indicate "overflow" or "carry". There is no single "call subroutine" instruction. But there are assorted side-effects to watch out for. Generally, there is no way of finding out if there is more tape in the paper-tape reader, or if another character has been typed on the TeleType: without "hanging" the program if there isn't. Also there is no way for a program to find out how much store is on the machine without "hanging" when it reads past the end.

Chapter 1 presents me with quite a problem, because there were probably more 900s made than any other machine in the pilot study. Many of these listed were for undisclosed projects. So, even if I find out about some projects, or use the information in the ECUA membership list (DPA permitting), I still don't know which undisclosed projects to cross off from the list in Chapter 1. Often, 920s were supplied in bulk by Borehamwood to an application division, who added an interface unit and shipped them on to, say, the aircraft manufacturer, who delivered them to Boscombe Down for acceptance, thence into the RAF. Many 903s were owned by Research Institutes initially, and then by nearby Schools.

So, any information you can supply to help me out would be appreciated. What organisations do you know of that had a 900? What variant (and serial number) of 900 did they have? When did they get it, and from whom; when did they dispose of it, and to whom? How much store did it have, and what peripherals? What was it used for, and which languages did the organisation use on it?

Finally, I wasted a lot of time researching conversion into PDF: time which would have been better spent on doing the pilot study itself. I'm looking for a conversion utility which can produce PDF files from DOC or RTF files, including embedded pictures and embedded PowerPoint diagrams (like the register diagram in Chapter 3), which preserves the line-thicknesses that I've used (both in the register diagram and in the various tables), which can cope with miscellaneous symbols like: , , m, p, q, , , , Ö, (both upright & italic), gives the same pagination as MicroSoft Word, and can include "clickable" hyperlinks to the Internet. Of course I'd like it to be free, produce compact output files, and to run on an Elliott 920B/903 (or, at a pinch, under Win95 in 48Mb of memory or WinNT 4.0 in 64Mb, or under Linux). Do you have any experience of PDF conversion? (For the record, I was given a rather nifty "printer driver" which can intercept the output from a Word print command and produce a PDF file, but that deleted a chunk of text whenever it saw symbols like m, and could not cope with embedded PowerPoint; PDF995 is another "printer driver" which can cope with embedded PowerPoint but still has some trouble with symbols. I've used OpenOffice to convert most of my chapters, but that made quite a mess of the register diagram. None of these seems to translate hyperlinks).

Best Wishes,

Terry Froggatt


+441252 - 613996/676361