Fixing the FACIT 1123


Several years ago it came time to clean out a closet filled with electronic equipment which I had accumulated twenty years earlier as a kid during the Seventies.

Both my parents had been accountants in that era and when calculators at the office broke down or developed bouncy keyboards and were deemed no longer worth repairing, they brought them home to me. I would open them up, see what could be done with them, and then put them away perhaps to be used in some project requiring a keyboard or display or some such in the future. Most of them remained in their received state - for a couple of decades.

Consequently, a couple of the boxes filling the closet contained calculators, ranging from several late-Sixties NIXIE-display desktops through to mid-Seventies simple vacuum-flourescent LSI machines.

Now it was time to decide what to do with them. Opening the boxes for the first time in many years it occurred to me there was actually a bit of a collection here. Most of them needed only some cleaning and minor repairs. One of the most interesting was a FACIT 1123; however it had problems.

The FACIT 1123

To begin with the display didn't even light up. From a servicing perspective, that's actually a good thing. Complete lack of display indicates a probably simple power supply problem or absence of timing signals to multiplex the display. A little probing with a scope determined the clock signal was present but disappeared upon entering an IC. The 14-pin DIP integrated circuits the machine was constructed from were labeled with a proprietary numbering scheme and I could find no cross-references for them. However, the pattern of traces connecting the pins of the IC in which the clock signal disappeared suggested that it was simply a quad 2-input gate unit. A little more testing confirmed that it contained four 2-input NAND gates. Substituting a standard 7400 TTL IC for the bad unit brought the timing system back to life.

With the timing fixed, the unit was largely functional. The display was present, numerals could be entered and cleared from the display, it would even multiply: 2 times 2 resulted in 4. It just couldn't add properly: 2 + 2 resulted in 8. For a machine of this era and design, multiplication could be expected to be accomplished with multiple additions, so the machine being able to multiply but not add was a perplexing problem. It was obviously rooted deep in the logic of the machine. Looking at the 3 printed circuit boards populated with 140-or-so unknown integrated circuits, the likelihood of finding the problem seemed remote.

The two possible routes to solving this problem were:

Reverse Engineering

So I set out on the task of reverse engineering the unit.

Some weeks later the schematic was complete, and while many of the functional units of the calculator had been identified and isolated in the schematic, the state machine - where the addition problem was likely to be rooted - was still pretty much indecipherable. After poking around the calculator for a while and staring at the schematic trying to imagine the logic operations, solving the addition problem seemed no closer.

The problem was that the schematic didn't present an understanding of the more detailed functioning of the calculator. Furthermore, poking around in the calculator with a scope, trying to observe one-time events, was difficult and not helpful. Opening and closing printed circuit paths for testing and confirmation would just make a mess of the unit. So, what next?

A logic simulation of the unit would solve these problems, allowing one to gain an understanding of the unit in a controllable environment, by being able to slow down the clock rate and build meaningful displays.

The Simulation

The next task was to obtain a logic simulator. The only programming environment I had for my Mac was Macromedia Director, a multi-media development environment. Not exactly the first choice for building a logic simulator but built in to Director is a quite powerful object-oriented scripting language called Lingo. Lingo is a pseudo-compiled language so while the result might be slow, it's object-oriented nature is ideal for creating multitudes of things like gates.

Another few weeks and the simulator was tested and complete. The task now was to create the simulation of the calculator. This involved another laborious procedure of manually typing a description of the calculator logic, connection-by-connection, into text files for the simulator to read.

...and Finally...

With the functioning simulation it was now possible to observe the intended operation of the logic via the simulation and compare it with the physical unit. Astoundingly, within about 20 minutes of completing the simulation, the problem was traced to a bad feed-thru stub on a printed circuit board!

Before plated-thru holes were used extensively in consumer products, connecting traces on the two sides of a printed circuit board was sometimes accomplished by inserting a little stub of wire through the board and soldering it on both sides. In this case, during manufacture the stub was not inserted fully and ended up being butt-soldered to the lower trace. Eventually the connection opened, in a manner quite invisible to observation.

Upon repair of this connection, the calculator could add properly. So after several months of effort, months of which was devoted to preparatory work and 20 minutes to the actual repair, the FACIT 1123 was restored to full functionality.

The open connection can be simulated and the consequent flaw observed by enabling the checkbox labeled "Simulate Flaw" when running the 1123 simulation.

None of my other units have required this degree of effort to repair, but several of them have been reverse engineered and several other simulations have been created.

  Calculators | Integrated Circuits | Displays | Simulations
Aug 2000