I next needed to look carefully at what was working and what wasn't.

• What was working:

  • For all 4 keyboards, you could "Clear display" (sets all digits to blanks) and "Clear all" (sets all digits to 0's).

    • so the clearing works and all registers can be set to all 0's or all blanks​

  • You could enter at least a few numbers on each keyboard

    • so the input routine is at least partly working​

  • once set, a number was stable

    • since reading core memory is destructive, this meant that (most likely) all the cores could be written to and read from​

  • entering numbers or hitting other buttons on one keyboard had no effect on the others

    • so there isn't any crosstalk​

  • can enter and recall short (see later) numbers into the accumulators

    • so those registers are OK​

• What wasn't working:

  • addition and subtraction were OK for the first few significant digits but not the ones to the right​

  • hitting Enter or any of the log-related keys sent it into lala land - the display would keep changing and only a "prime" would get it to stop

​

I started a systematic analysis and saw that there was clearly something wrong with the 6th digit from the left (location 9 in core):

• You could enter digits up to there but not past there. That is, keying in 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 displayed "+12345xxxxx" ("x" = a blank digit)

• Addition had strange behavior around digit 6 (underlined below)

  • Clear all => "+.00000 00000" 

  • Clear display => "+xxxxx xxxxx"

  • 2 => "+2xxxx xxxxx"

  • Left + => "+2.0000 70000" - where'd the 7 come from?

  • Left + => "+4.0001 50000" - 2+2 = 4 but 7+7 isn't 15???

  • Left + => "+8.0004 x0000" ??

  • and so on​

​

This was true for all 4 keyboards - which pointed to that particular row or column in the core. But it can't be the cores, since we can store "0", "x", "5", and "7" (at least) in those locations. It can't be the register selection, since all the registers work with this one exception. It can't be the read and write registers and drivers since you can read and write fine to the other locations. This left the particular column in the core that holds this digit - either the driver was bad and/or the wires on the core board were bad. Alternatively, something could be wrong with the counters as they try to write data to this location.

​

How is the memory organized?

It is 1024 bits, organized as 16x16x4. That is, there are 16 registers, each consisting of 16 4-bit BCD digits. There are 4 separate calculating units, each with 4 registers (Working register, Log register, Right accumulator and Left Accumulator). The physical cores are arranged as 4 16x16 arrays. The 16 columns (X-coordinate) correspond to individual registers; the 16 rows (Y-values) correspond to individual digits within each register. When the calculator selects a particular X-Y pair (digit within a register) all 4 bits are read out in parallel on the 4-bit data bus.

​

The correspondence between X-Y addresses and actual row-column locations is complicated. This is done to avoid crosstalk between sequentially-accessed core locations. As a result, it took some figuring to get access to signals that gave meaningful X and Y coordinates. In the data that follow, the X and Y coordinates are those used by the internal logic, not the physical X-Y locations in the core. More on that later...

​

In the image below, the X-coordinates correspond to particular registers. In this case the register selection works like this: !XD8 ("not XD8") and !XD4 are 00 - indicating calculating unit 0; XG1 and XG2 are 00 - indicating the working register (the register that is displayed). The Y-coordinates are determined by the CGx signals - these are the output of the "C-switch" which selects the source of the memory address signals.

​

The DGx lines are the outputs of the "D-switch" - the data being written to the core. When SD1 is high, the data to be written to the core come from the E-register, which contains the data last read from the core. That is, when SD1 is high, data from the core are read out and written back unchanged to the core. When SD6 is high, data from the 4 least significant bits of the K-register - the data from the keyboard - are written to the core.

​

The sequence shown below follows typing "1", "2", "3", "4" and "5" - these were entered successfully. It shows in detail the events following typing "6". The calculator counts down (moving left to right in the digits) through the core starting at location 15 and re-writes the data found there (SD1 high) until it hits the first empty location indicated by a value of 1111 (F). It then writes the keyboard data at that location (SD6 high) and finishes re-writing the remaining digits (SD1 high).

​

The display should start with "+12345 xxxxx" and end with "+12345 6xxxx".

​

The numbered events on the right correspond to the red numbers in the figure.