When I first envisaged this project I had only enough core memory components to construct a 2K byte memory, the minimum size actually available when the Honeywell 200 was first marketed. In fact this much memory wasn’t even enough to run the smallest assembler for the Easycoder language used to programme the computer, so such a computer would only be able to run programmes already assembled on another machine. Also strangely it appears that the Honeywell 200 memory always came in 4K modules, so maybe the 2K memory never really existed, although the computer did treat the first 4K of memory as two separate banks of 2K to provide for it. Anyway, the smallest machine that I ever used had a 4K memory, so I needed to determine whether a reasonable demonstration programme could fit into just 2K and also whether I could remember how to write Easycoder, so I wrote the “Pi Factory” programme. Subsequently I encountered my present colleague Marcel, who has donated several original Honeywell 200 4K memory modules to the project, so the projected computer can now have more memory, but the Pi Factory programme remains a demonstration of just how much could be done using a tiny amount of memory. My target specification for the programme was as follows.
The resultant programme is called the Pi Factory, not on account of the obvious pun but because it uses a production line approach to the calculations, performing them all together and passing partially completed results from one to the next. Completed digits coming off the end of the production line are sent to the output device and forgotten. It keeps running until the outstanding calculations fill the whole of the available memory and it can’t add more. The method of calculation is Machin’s formula expressed as follows.
When expressed this way it is apparent that calculation of each term of the formula only requires one division by 25 to obtain the next value of Fn, one division by 57121 (i.e. 2392) to obtain the next value of Gn, one final division by 2n-1 and the facility to alternately add and subtract terms to accumulate the value of Pi. In order to produce the final result progressively and continuously the divisions are done long division style, producing only one digit of the quotient at a time and leaving a remainder to be processed later. The digits from one division can be fed into the next part of the calculation immediately even though there are more to come later. The only place where a process has to proceed from right to left is in the carries generated by the final summation, but they don’t propagate far, so it is enough to delay outputting a few digits until these have been resolved. Performing the divisions one digit at a time also solves the problem that the basic Honeywell 200 had no hardware divide instruction, so a software solution involving repeated subtractions had to be provided anyway. With this particular method this is not a significant disadvantage.
To evaluate the method I wrote several test programmes in C++ on a PC. I tried using several other expansions of Pi but none had any clear advantage over Machin’s for my purpose. The source code for one of the Machin programmes is here. PiFACTORY.CPP It may help understanding of the method or, having been written hastily in a disposable form, just add to the confusion but the output below run to just 50 decimal places may be informative.
The output shows the digits of Pi generated including ones temporarily held back to allow for carries. It also shows how many of the terms Fn and Gn are needed at each stage of the calculations. The latter part of the output shows the remainders from all the divisions in progress when the programme stopped. This illustrates a further simplification of the calculations. Once the first few digits have been calculated the terms of the expansion divide into three groups: first those where calculation of Fn has completed, as it only involves division by 25, but calculation of Gn is in progress, second those where neither Fn nor Gn is being calculated and finally those where only Fn is being calculated. Consequently only one or two partial divisions are required at each step, never three except at the very beginning. This outline of the method suggests optimisations that could be applied to suit any computer, even the simplest. The C++ code given is complete and can be modified to produce more decimal places provided that an array of adequate size is used, but it is in no way optimised as it was only used initially to prove that the method worked.
The Easycoder version of the Pi Factory is very different, being so heavily optimised that it substantially obscures the calculation process, but this was necessary to reach the target Feynman point. I wrote a rudimentary PC-based cross-assembler plus emulator to assemble and run it and the results are shown here. MACHIN.PDF Note that the computer used six bit characters, so binary values were always shown in octal rather than hexadecimal. Also the source code was partially fixed format, so the precise positions of entries were significant unlike modern free format languages. At the end of the listing is a primitive dump of the final state of the 2K memory used for diagnostic purposes. The emulator also calculated the equivalent elapsed time on a Honeywell 200 from the published instruction timings, the time being 14 minutes 1.9 seconds to reach 770 decimal places. That isn’t number crunching but just getting there at all would be an achievement. The programme can use up to 4K of memory, in which case it can calculate 1,767 decimal places in 1 hour 9 minutes 48.4 seconds. The fact that in this case memory space is exhausted exactly 1000 places past the Feynman point is definitely spooky. As the programme is written using two character addressing, i.e. 12 bit addresses, it can’t use more than 4k of memory, but I concur with Feynman’s point so well made, that in one sense enough is enough. From the outset the complete range of computers in the 200 series were planned to use two, three or four character addressing, thereby using any amount of memory from 2K to 262k efficiently. The standard model 200, as illustrated on this website, could use two or three characters, the latter mode allowing only 15 bit addresses to leave space for address modifiers, so giving it a maximum memory capacity of 32K.
Looking at the Easycoder listing anyone used to modern programming will see marked differences even if they don't fully understand what the programme does. The Honeywell 200 was a two address machine, so virtually all the register handling was done automatically by the CPU and the programmer seldom needed to worry about it, although they could still take advantage of the register contents by chaining instructions. A single instruction could process a field of any length defined by punctuation marks set in memory, so despite being an assembler language converted directly into machine instructions Easycoder looked like a simple compiled language. Used in the simplest way it really did make coding easy, but it could also be used in other ways to great advantage as is done here. There was no explicit return stack, indeed no stack handling capability at all in the most basic models, and no distinction between executable code and data, so dynamic modification of the code was commonplace. In this particular example there are many code modifications, which make it difficult to understand what is happening, but the only important thing here is that the computer understands it. This style of programming, where the computer is treated as a finite state machine with the entire contents of the memory defining that state, is quite different from modern techniques where process and data are clearly segregated. However, there are no right or wrong ways to design programmes, only appropriate and inappropriate ones. This way was appropriate when the processes that took place in a programmer's mind cost much less to run than the processes in a computer. Nowadays that economic balance has changed and failsafe techniques are more appropriate.
The calculation method used in the Pi Factory is so self-evident that it probably isn’t original (I would be disappointed with mankind if it were.) but the satisfaction comes from personal experience of discovery, not just being the first to do something. When I was very young, probably somewhere around the time of the Festival of Britain to be honest, I pushed a magnet into a coil of wire and was disappointed when it didn’t become demagnetised and generate electricity as I expected. Years later I had the satisfaction of discovering that I had been following in the footsteps of Faraday and might have got further had my apparatus been as sensitive as his. This project is very similar in that we don’t have the precise design or components to reproduce the Honeywell 200 exactly, so we must retrace the steps not just of Dr. Gordon and his design team but also the other people who built and maintained the machines. That way we will appreciate what they achieved. I have in my collection of components a couple of core memory planes which were manufactured in Barbados in 1969. Their appearance and the fact that they were made by an offshore company suggests that they were hand-made, maybe by young girls with keen eyesight and nimble fingers deftly threading the many wires through thousands of tiny ferrite beads. When the Honeywell 200 was being marketed the company used figures of animals modelled out of hundreds of stock electronic components in the campaign. These are now considered to be historic works of art, but I also consider those memory planes to be works of art as fine as any medieval needlework. The computers were made up of thousands of components but so was the organisation that made them, from Dr. Gordon and his team down to those girls in Barbados. In a way that is Feynman’s point, that one can’t draw a line at 768 significant figures and say that the rest are insignificant, even if one feels 99.9999% certain about it. Neither can we be absolutely certain how significant the Honeywell 200 was in the history of computers, but we can try to get some appreciation of it. That is why I have adopted the Pi Factory as the signature demonstration programme for this project and when it actually runs on the replica computer I will consider the project a success.
Apart from its efficient use of memory, the Honeywell 200 was very versatile in its use of peripheral devices, but a programme to demonstrate that feature will have to wait until some suitable devices have been identified much later in the project.
Links and contact
Return to home page