Honeywell 200 resurrection

[RobS]

I noticed that an H200 board showed up on eBay if anyone is interested. My dad thinks it's from a peripheral, maybe a printer or card reader/punch.
https://www.ebay.com/itm/234989466188

Browsing back through recent posts I noticed this item. I see that the seller wanted $20 for the board. Given that I now have maybe 1300 of these boards it looks at though I could try selling off some of the unwanted ones to fund the project, but I'd have to do so a few at a time to keep up the impression that they are actually rare. I wonder whether that chap with the massive stockpile in Pennsylvania still has them or has now sold them to a scrap dealer as he intended.

 

[daver2]

I can see how Booth's Multiplication Algorithm could be implemented using the technique you have suggested if the CPU can loop on the instruction a given number of times (the bit width of the operands). But, in this case, only one level of ADD/SUB is required and an arithmetic shift right per iteration. The bit shift can be accommodated via wiring and gating - so there is only one level of ADD/SUB required still.

Dave

 

[durgadas311]

Rob is, of course, right. I was thinking of the H200/2000 "Scientific Unit" which used a 48-bit fixed-length FP format. But the base machine also had integer multiply and divide instructions, which worked in units of 6-bit characters (iteratively). So, it's easier to imagine this board may have provided necessary functionality for the standard (integer) multiply/divide instructions, rather than being part of the "Scientific Unit".

 

[durgadas311]

At one point, while working to emulate the integer multiply and divide instructions, I had worked out in my head how they implemented them on the original hardware. The instructions have a fairly odd orientation of input and output fields, but that tends to inform you of how the instructions are implemented, combined with the formulas for working out the number of CPU cycles required. I believe they are fairly standard algorithms, and I think could easily be worked out with add and subtract. So, I'm not sure how the 74181s fit in - although they are likely for later model CPUs and probably represent an enhancement of the multiply/divide instructions.

 

[RobS]

I have checked some of the connections on the board and it looks like the most boring arithmetic module on earth. I know that in those days the 74181 was seen as the universal arithmetic workhorse but really. Of the eight 74181s four have B0=B1=B2=B3=S0=S3 with S1=S2=ground, which rather limits what they can do. Also they are in two pairs, each pair using the same B0-etc input line to limit them further. They are also cascaded with each of their four F lines connected to the corresponding four A lines on the next IC, so there are actually only four standard data channels into them so far as I can see although I haven't checked the connections to all the carry lines yet. The F lines from the last one in the chain appear to go to output pins on the board.

The other four 74181s are even more boring as none of their F outputs are used at all and their only used outputs appear to be the A=B lines, so they must form a comparator but the same value of B is fed into all four and the A values just come from stages in the chain formed by the previously mentioned four ICs. Consequently there doesn't seem to be a great need for input/output lines on the board's edge connector for any of the 74181s.

I haven't attempted to draw a diagram to make this clear as I have pretty much lost interest in the board now. As someone who tries to get the maximum functionality out of the hardware I am very disappointed by the use of the ICs here. Sometime I will check my analysis to ensure that I haven't missed something but without knowing what those DKVH1 and DKVH2 ICs do I'm going to be in the dark anyway.

If anyone can make anything interesting out of this messy description please go right ahead but I don't think it adds up at all ... ho ho.

 

[durgadas311]

It sounds like maybe this board was just a replacement for older, more complicated, logic. But with only 4 inputs, perhaps it was for decimal arithmetic? As opposed to binary logic/arithmetic, which would need 6 inputs. H200 decimal arithmetic used 4 bits for the digit and 2 bits for the sign (only on the least significant digit). Perhaps the other set of 74181 were for computing the sign. Of course, without knowing how it was connected to the rest of the machine, we're just guessing.

 

[RobS]

I have already designed an arithmetic unit for my H200 replica using Honeywell's own very primitive ICs with only two simple gates each and I assure you that eight 74181s plus many support ICs really aren't necessary to achieve both binary and signed decimal addition and subtraction in one compact unit. What that board was for is beyond me at present.

 

[Chuck(G)]

A 74181 cannot do multiplication or division. Only addition and subtraction plus a number of logical functions.

See: https://en.wikipedia.org/wiki/74181 for a potted description.

In order to do multiplication and division will require external logic to 'recycle' the output from the 74181s back to a temporary register (i.e. hardware or microcode).

Division, perhaps, but a bunch of adders configured as Wallace or Dadda multiplers do their work in a single cycle--operands in at the top; product out at the bottom. They've been around for donkey's years and don't require clocking.

Division on the other hand, is a tough nut. That's a reason, for example, Seymour Cray decided to leave it out of the Cray I repertoire, substituting the "floating reciprocal approximate" instruction.

 

[durgadas311]

Yeah, that's a mystery. I could imagine that a pair of 74181s could replace most of the logic for addition, subtraction, half-add, extract, etc... But eight is just too many. Of course, we don't know how it was used, or even what machine it was installed in(?)

 

[RobS]

Division on the other hand, is a tough nut. That's a reason, for example, Seymour Cray decided to leave it out of the Cray I repertoire, substituting the "floating reciprocal approximate" instruction.

One of my very first jobs as a programmer involved computing the bonuses on all of our mutual company's with profits life policies, which only happened every three years and the year that our computer was delivered happened to be the year when it had to be done. The rate of bonus was a specified percentage per annum but on some contracts the figure had to be computed to an exact number of months rather than years, so a division by twelve was needed on our simple H200 only capable of addition and subtraction. I used this requirement to try out my own unique way of dividing by nine, which as I recall only involved one subtraction and one addition with the result field overlapping the operand field, processes which gave "unpredictable results" according to the manual. Of course nothing is really unpredictable in any specific computer once one has discovered what it always does. My method also gave the answer to as many decimal places as one wanted simply by making the result field as long as one wanted.

However, the complex logic involved didn't conform to any conventional arithmetic process, so I asked a member of our actuarial department to approve my algorithm and he sent me back a page of algebra involving an endless series of expressions which demonstrated that I was right and that my two simple instructions did always give exactly the right answer.

Once I had a number divided by nine I could use the usual programmer's tricks of doubling, adding and shifting to multiply by 0.75 to give exactly one twelfth of the number I started with to any precision using only a straight sequence of available instructions without any loops. It was very satisfying for me that about half a million customers received bonuses on their contracts computed by my mad looking algorithm instead of conventional but slower and more boring arithmetic.

I can't recall precisely what the two instructions were at the moment but anyone with an H200 emulator or even maybe an IBM 1401 one could probably play with the problem if their emulations exactly match the processes in the hardware. Offhand I think the method was to put the original figure into the right hand end of an initially zero field long enough to hold the answer including all the decimal places required, then subtract the field offset by one character from itself, bearing in mind that the machine would then be subtracting the result from itself as it calculated it because of the overlap, then finally take the left hand half of the field and add it to the right hand end of the same field. I could be wrong but it was something like that. If you are careful you can work it out on paper.

Of course working out what sort of warped mind could come up with such an algorithm in the first place is relatively easy as within a couple of years I was in mental hospital suffering from a surfeit of lateral thinking. When I came out of hospital I was put in an actuarial department specialising in pension funds but was eventually allowed to return to computing when I mentioned that I could program our computer with its little 4k memory to perform within minutes twenty year projections of funding costs for those pension funds that the members of that actuarial department spent most of their day laboriously calculating on hand-cranked desk calculators. They were no doubt given less tedious work to do once my program was put into use.

Several years after that the company bought a much larger machine with tape drives and I was able to take up more relaxing COBOL programming without too much extreme lateral thinking involved. However, that machine still didn't have hardware multiply and divide, so when I was given the full actuarial valuation of all the company's contracts to program I realised that the standard software multiply and divide within the COBOL compiler were very inefficient, so I wrote all the complex calculations in an assembled Easycoder module inside a shell COBOL program ... The program worked perfectly and I recovered eventually and was certified sane again by the hospital ... but now I'm doing this ambitious project here ... Keep watching this thread for occasional signs of sanity.

 

[Chuck(G)]

If you look through CDC 6000 series assembly code you'll often find that instead of dividing by 10, an unnormalized lower double-precision multiply by a scaled 1/10 was used. The same trick didin't work well on systems that used 2's complement normalized floating point, but then the CDC big iron had no integer multiply nor divide.

 

[RobS]

When I wrote my "Pi Factory" demonstration Easycoder program that appears on my website I realised that multiplication by variables, as opposed to by constants that could be constructed by fixed arithmetic, was not needed and conventional division was of no use as the value of Pi was to be printed out with barely any initial delay caused by computations. Also the absence of any limit on the number of decimal places computed made full division inappropriate and simpler integer division with a remainder had to be used instead. Consequently hardware multiplication and division would have made almost no difference to the speed of the program, so it was an ideal demonstration of the capabilities of a machine without these even though one might assume that the calculation of Pi is hefty arithmetic rather than primarily a data manipulation process. Examination of the code shows that most of it handles the storage and retrieval of small variables rather than computation of long numbers. In fact the program doesn't even store the complete value of Pi that it calculates at any time, only the part that it is currently printing.

This approach to the calculation of Pi as a string of digits rather than a very precise number is very much in keeping not only with Alan Turing's idea of his a-machine, later known as a Turing machine, but also the original vision of the late Dr. William L. Gordon, chief designer of the H200, which was a machine containing many delay line memories rather than the then more expensive random access magnetic core memories. The H200 evidently ended up with core memory because the cost problem was overcome. Gordon had realised that the majority of data processing involves handling strings rather than random fragments of data, so totally random access wasn't essential. It is this idea which has resulted in word lengths in memories gradually becoming longer as the demand for the immediate retrieval of whole items of data rather than just fragments has increased. Floating point arithmetic has masked this problem in dedicated number crunchers so that my previously mentioned actuary easily overlooked the fact that division by n! was setting a simple financial computer a relatively big problem to solve. Even now we haven't actually evolved very much beyond punched card processing as the fundamental problem is still whether we process the data vertically or horizontally, serially or in parallel.

 

[durgadas311]

Excellent explanation, Rob. And I do appreciate your PI-factory program - learning how that works is like (what I imagined) going on an acid trip is like.

 

[RobS]

Have you actually tried to unravel the code? Good heavens! I was so desperate to reach the Feynman point that I incorporated some instructions spread across all the unused item mark bits in the rest of the machine code, so one bit to each character, to reduce the program size slightly and fortunately that got me there.

 

[durgadas311]

Yes, I did eventually figure out what you were doing the item marks! I thought that was particularly inspired... or demented... jury's out ;-)

 

[RobS]

Either way the bottom line is that it worked.

 

[RobS]

Regarding the R3MAA board with the eight 74181s, my Honeywell field engineer friend Brian has written to me that:

"The R3MAA is almost certainly from the H3200 series (highboy cabinet) (Also marketed slowed down as variously 2040, 2050, 2060) Many of the 3200 series machines packages were Rxxxx, from memory eg R1FFA. In view of the multiple chips of the same type, it is probably a programmable chip board. There were quite a lot in the 3200."

Well, the 74181s weren't programmable so the programming must have occurred elsewhere. Anyway, as I previously stated, it's boring as it is but perhaps I could adapt it to do something more useful. Adapting boards is likely to be the way forward in my project as most of the value in them is actually the gold plating on the edge connectors rather than the components. Of course those unique Honeywell components are extremely valuable to me but getting new custom boards made for them with that gold plating is getting very expensive. In contrast British computers from that period often had simple wire connections made to boards by directly wrapping or soldering the connecting pins. It made maintenance more difficult, as the conservationists here know well, but kept the costs down. Also the consequent intrinsic scrap value of the American boards and backplanes no doubt increased the probability that they would be scrapped once they were no longer in use, so conservation opportunities were possibly not so likely. That chap in Pennsylvania with a very large number of H200 boards and backplanes planned to sell them for scrap for that reason.

 

[RobS]

Regarding that board with the eight 74181 ICs and nine other mystery support ICs, I discovered that as wired it seemed to do very little. However, both Chuck and I guessed that it could have been a multiplier, so I wondered just how feasible that was. To be of any use in the H200 as a multiplication accessory, as the machine uses characters with six data bits it would need to be able to multiply two six bit binary numbers in one pass working in conjunction with the basic six bit ALU. I played with this for a while and discovered that, with complete rewiring plus replacement of those mystery ICs with more useful known ones containing just simple logic gates, it was feasible, so our guess that it could have been a multiplier was quite reasonable and it actually could be if I did quite a lot of work to modify it.

My redesigned board takes two six bit inputs and returns the lower six bits of their product while the processor's basic ALU performs the final addition needed to return the upper six bits all in a single pass through the logic. It isn't exactly an elegant design as I had a problem with one of the carry bits and had to use two or three gates in the support chips to handle it but at least I have proved that it is feasible with a single pass and no reiteration just as Chuck claimed.

Do I actually need to explain my design in full or will anyone interested work one out for themselves? Chuck mentioned Wallace and Dadda multipliers but I just put together my own design without bothering to find out what they are. An additional constraint to consider here is that the board only has 36 pins on the edge connector and at least three of those are used for the ground and power connections leaving 33 for inputs and outputs.

People say not to reinvent the wheel but every wheel needs to fulfil a slightly different purpose within particular constraints so I consider it good practice always to think in terms of just the basic principles. It's these types of little puzzles that I find entertaining during the design of my machine and in contrast I would get very bored if I were just building the machine directly following a full original construction plan.

On reflection perhaps I should write out my design in full just to confirm to myself that I've got it right and also ensure that it is available if I ever actually want to use it in the future as by then I will no doubt have forgotten what it was.

 

[RobS]

I have now written out my design for the six bit multiplier properly and checked the details so can file it away in case I actually ever want to build the device.

If I could work out how to attach the PDF for viewing here I would. Oh, I think I have.

 

[RobS]

I love it when one can see in an old computer exactly what the designers were thinking to make the machine the way it was. I have just received from my old Honeywell engineer friend a precise template for the positions of the holes for the buttons on the H200 control panel traced directly from an original fascia taken from such a panel. This will enable me to create the metal mounting panel for the switches in my replica with those switches in precisely the correct positions. That simple drawing told me something else though without a single word being necessary on it. In fact the very absence of words was the key to this fascinating snippet of information.

If you can't remember the exact layout of the panel look at my CAD picture of one on the home page of my website mentioned below in my signature.

The layout of the upper buttons used to set and view control register, address and contents values was self-evident and the buttons on the right used to display and update these also followed a similar spacing pattern but the master controls for the machine along the bottom were spaced in a peculiar way that didn't correspond to any other buttons and I wondered why until I realised the simple explanation, that the H200 was designed to be made as cheaply as possible.

Here is a picture of buttons taken from some other machine which used exactly the same type of switches as the H200.



Here the switches were obviously mounted horizontally so that there was room on the buttons for the text, but these buttons were each made from two special plastic mouldings, one for the button itself and another for the transparent cover over the slip of plastic with the text printed on it. The mouldings even had a stop incorporated into them so that the buttons couldn't accidentally be inserted upside down. These looked like expensive items to make, even in quantity, so Honeywell came up with a different most likely cheaper solution.

Their buttons were made very simply from a continuous plastic extrusion chopped into appropriate lengths, no doubt far cheaper than the complicated moulded buttons above. To avoid printing text on the buttons themselves where it would get worn off they printed it on the fascia of the control panel itself, which only needed one screen printing operation to make the whole thing anyway. In the place of text on the buttons they just painted simple symbols as a clear indication of which was which, so the text on the fascia was just there as an extra reminder of each button's function.

Now comes the artistic part. As there was no text on the buttons they could just as easily be mounted vertically as horizontally and by keeping the original spacing of the horizontal buttons the fascia would not have one long hole in it but several small ones, which no doubt made it more stable.

Now I knew exactly why the buttons were spaced the way that they were, because originally they were going to be placed horizontally hard up against each other as on other machines but someone thought of this way to cut costs and in the process make the panel look more visually appealing. To discover this all I had to do was put a switch on the template and turn it round and as soon as I did that it all became clear.

Well, that's another little mystery solved then, but maybe one that many people wouldn't even have given a thought. It all depends exactly why we each do what we do with these old machines.