Extensive diagnostic work on core memory stuck bit problem, work on console printer and keypunch interface designing

DIGGING THROUGH MEMORY GATE BY GATE

Time to switch over from the Tektronix 7000, versatile as it is, since it does not have a storage function. Up until now, the signals I was debugging were steady or happened periodically and frequently allowing them to be seen on a continuously tracing scope.

Now, I will be looking at events which happen only at certain points and triggering on the signals which are shared across several hardware units will give me too many false images. I need to trigger only on the desired events and I need to store it and display it in human timescales. Out comes the Tektronix 466, a more limited machine but one with storage capabilities.

Tektronix scope with storage to watch one-time events

I will leverage the CE card installed in the machine to combine together signals as necessary to trigger the storage scope. For example, to scope one of the four sections of memory, I need to combine the Write Cycle signal with the two addressing bits that match my targeted memory, to ensure the scope stores a signal for the relevant hardware I am checking.

The CE card is installed in the A gate, not over by the D gate where core exists, but the signals I need exist over near A, actually in B, or can be recreated from accessible signals there. Some jumpers to bring signals to the inputs of gates on the CE card will give me an output that goes high or low at the appropriate times. That gets hooked to the external sync of the scope, to trigger a storage event.

Gates open to left rear, scope and ALDs at hand

After about an hour of checking the core storage logic with the scope - watching the Short Time and Long Time signals, the strobe pulses, inhibit timing and the rest, it seemed very healthy. I then turned to the stuck bits, focusing on bit 5 as one of the problems and bit 3 as a control since it performed normally.

Bit 5 definitely misbehaves, having a short inhibit effect even when the B register value should be zero. This is why it is flipped on, because that short interval drops the inhibition current enough that the magnetic flux flips the core to the on position. No such phenomenon occurs on the control bit, bit 3.

I took the signal all the way back to the first pin where it enters logic gates and the anomalous dip is still present! I then moved the probes over to the B register itself. That dip occurs because something is setting the B reg bit 5 on for a short portion of the cycle! B reg bit 3 doesn't experience this. I then watched both sides of the flip flop, normal and inverted output, to get a sense of whether this is a flip flop problem or logic issue with the inputs. The bit 5 and inverted bit 5 signals are perfect mirror images.

Exciting news - the stuck bit issue is caused in the processor or peripheral adapters, not in core memory. I am not saying that this rules out any core memory issues, but the major problem of the stuck bits is driven from outside the memory gate and that will mask any more subtle issues.

Back to the wired common pin issue, undoubtedly, as some input bit or control signal to B register is awry and many of those are the 'dot or' circuits which take a while to spot the culprit. I took a break and prepared a plan for scoping the various signals inside and into B register bit 5. I will find the trail of the miscreant circuitry, although it may take more tracing back through other 'dot or' junctions to get to the root cause logic.

I did  the first tests based on the forced bit logic used for interrupt handler entry, since that logic sets on bits 1 and 5. However, I didn't rule out anything at this stage as it is time to relentlessly down hunt the errant signals without shortcuts.

Forced branch - no. Card reader - no. Printer - no. SAC - no. Console printer - no. Keyboard - no. Disk drive - no. It appears that we are getting a blip from the sense line which is triggering the B register bit on. Still don't know why, but it does turn my focus back to the core memory.

Some nuances of the situation I noticed might be a clue to the problem. First, when I power on the machine, there is a delay of about 2-3 seconds before the bit goes high. Second, when I start the CE Storage Load operation with all the data switches off, I can see bit 5 flickering on and off. Flip that switch up and it goes solid, turn it off and we are back to the flicker. While bit 1 is off steadily, if I turn the switch on and then turn it off, bit 1 begins to flicker as well from that point forward.

Since these are the same sense/inhibit card, but four of them, each for a 4K block of memory, I swapped the card for bit 1/5, one block at a time. None of them made any difference to the behavior. I am going to stop the power-on diagnosis tonight, picking that up tomorrow or when I can next get to spend time on the project.

It's time for more continuity testing, checking voltage, and noodling about what common circuits could account for all this. Whatever happened began back when I was working on the first problem, which was only a memory addressing problem - might be a physical issue I caused when moving cards around for that diagnosis. I can look at everything with this in mind as well - what I might have impacted without noticing.

KEYPUNCH ENHANCEMENT AND NEW INTERFACE

Last night I ordered the Arduino Mega 2560 and twin 8 relay boards for the new keypunch interface, as well as a DB-25 extender cable. Once I get the push in plug ends and friction fit clips I need to properly connect the cable wiring into the keypunch logic gate, I will begin installing the cables.

I made a few more design decisions and worked on a draft of the installation instructions for the interface. The protocol has to be finalized, thus I should build up a comprehensive draft and circulate it to the other designers in order to reach an approved specification. Coding of the Arduino can't be completed until we have the protocol and functionality agreed.

To help in the conversions and also to help sort out a mis-wiring that exists in the 029 at Computer History Museum, blocking the duplicate function, I have created a set of charts which show all the wires connecting to each relay contact point and where they go. Using a continuity tester and the chart, we can figure out what has to be changed to repair the CHM 029. This took me about four hours all told, between building it up and cross checking it.

CONSOLE PRINTER (TYPEWRITER) RESTORATION

I have ordered the correct (this time) ribbon shift tape, since the part I first requested was for a narrower platen model and therefore too short. It needs to be roughly double the width of the typewriter frame plus 10" for the vertical run. Different platen widths require double the tape to add double the additional width, The tape for the 15" platen is therefore 8" longer than the one for 11" platen machines.

The tape runs from the carrier of the typewriter to a pulley on the right side of the typewriter frame, reverses direction and runs back to one of a pair of pulleys on the left side of the frame, proceeds directly down to a solenoid at the bottom left which has a pulley on the end of the armature, reverses direction upward to the second of the pair of pulleys at top left, then heads to the right back to the carrier, where it bends around a pulley on the carrier to run towards the rear of the carrier to hook to the ribbon lift mechanism.

Still haven't reattached the spring that connects between the cycle control latch and a fixed upright deeper under the mechanism. In some ways, this is akin to arthroscopic surgery - can't fit my hands or even fingers in where the spring attaches - and I have to be clever enough to invent a method out of the tools and facilities at hand where I get hold a spring, bend the end and insert it through a small hole in the fixed plate. Two or three tiny hand-analogs will be required, all of which have to fit down a small tunnel and are restricted to movements that can be made within that tunnel.

I leave the reattachment task on the back burner, waiting for the muses to inspire me with a solution (or, if you prefer, waiting for the right hemisphere and subconscious to work on the problem until they are ready to announce a possible solution).

My first hand cycle tool snapped off due to excessive resistance as I was rotating the mechanism; this is a safety feature but a nuisance as I have to extract the threaded end from inside the hub before I can install my replacement hand cycle tool and get back to coaxing the old grease to give up. If it weren't a nuisance to detach the printer cables, I would have already picked up the mechanism and given it a good bath of solvent to wash away all the solidified old lubricants.

I finally invested the time to detach and extract the cabling, allowing me to move the 1053 away from the 1130 and therefore can give it a solvent bath. The best solution would be mineral spirits, but they are outlawed in the bay area. The eco-friendly alternatives are of unknown chararacter as far as damaging motor winding enamel, plastic parts, contacts, or other parts, nor is it clear if the solution is going to evaporate with almost zero residue.

1053 out on table ready for more thorough cleaning

Cable and connector ends that are now detached from 1131

While I look for the right immersive or spray solvent, I did some more oiling and gentle working of the moving parts, trying to get everything freed up.