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 Pi Factory
Stored 5^2n 239^2n
DP Pi Digits Terms Terms
0 000000003 2 1
0 000000032 3 1
0 000000315 3 2
0 000003143 4 2
0 000031417 5 2
0 000314161 5 2
0 003141593 6 2
0 031415927 7 3
0 314159267 8 3
0 3 141592655 8 3
1 1 415926538 9 3
2 4 159265360 10 3
3 1 592653592 10 4
4 5 926535899 11 4
5 9 265358979 12 4
6 2 653589794 13 4
7 6 535897933 13 4
8 5 358979324 14 5
9 3 589793237 15 5
10 5 897932387 15 5
11 8 979323847 16 5
12 9 793238464 17 6
13 7 932384625 18 6
14 9 323846264 18 6
15 3 238462644 19 6
16 2 384626435 20 6
17 3 846264338 20 7
18 8 462643383 21 7
19 4 626433832 22 7
20 6 264338328 23 7
21 2 643383280 23 7
22 6 433832797 24 8
23 4 338327952 25 8
24 3 383279505 25 8
25 3 832795028 26 8
26 8 327950289 27 8
27 3 279502885 28 9
28 2 795028840 28 9
29 7 950288420 29 9
30 9 502884197 30 9
31 5 028841972 30 10
32 0 288419717 31 10
33 2 884197167 32 10
34 8 841971692 33 10
35 8 419716940 33 10
36 4 197169400 34 11
37 1 971693990 35 11
38 9 716939938 35 11
39 7 169399377 36 11
40 1 693993749 37 11
41 6 939937509 38 12
42 9 399375105 38 12
43 3 993751059 39 12
44 9 937510585 40 12
45 9 375105823 40 12
46 3 751058211 41 13
47 7 510582098 42 13
48 5 105820978 43 13
49 1 058209752 43 13
50 0 582097493 44 14
Sorry, no more pi's left.
Final remainders stored
Term 5^2 239^2 2n-1
Rem Rem Rem
1 0 42064 0
2 0 25890 1
3 0 32666 0
4 0 24874 1
5 0 42482 6
6 0 27560 2
7 0 33220 10
8 0 53799 0
9 0 28957 5
10 0 46437 8
11 0 42129 19
12 0 22609 18
13 0 22112 24
14 0 1 20
15 0 0 10
16 0 0 9
17 0 0 29
18 0 0 15
19 0 0 24
20 0 0 8
21 0 0 20
22 0 0 3
23 0 0 20
24 0 0 37
25 0 0 23
26 0 0 8
27 0 0 31
28 0 0 50
29 0 0 32
30 0 0 32
31 8 0 0
32 7 0 35
33 16 0 35
34 5 0 25
35 23 0 63
36 23 0 61
37 12 0 42
38 24 0 40
39 15 0 51
40 1 0 18
41 14 0 61
42 18 0 71
43 4 0 6
44 6 0 0
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.