I only had a few hours tonight to work on the system, but made the memory issue my top priority. I set up the scope and dove into the memory operation again. For some testing, I had to connect twisted pair cable with proper termination at the scope, where I displayed the differential by inverting and adding one channel to the other.
More scope testing |
I pulled the card and verified continuity on the sense/inhibit wire through the core stack. I checked that all the control pulses arrived at the right time. Everything looked right but the bit was flipping on regardless of the state of the inhibit line.
I shut things down and went through some continuity checks to verify voltages and signal quality. One of the inputs to the card is called 6V inhibit 1 & 5 but it isn't timed, it is a steady connection from the 6V line to all sense/inhibit cards at all time. I checked that the two cards handling bits 1 & 5 for the low and high 4K of this compartment were connected. Then I checked to see if the pin was also connected to the 6V inhibit voltage on the sense/inhibit cards for other bit pairs. It was an open circuit!
The card was not getting the 6V supply to drive the inhibit current, thus allowing the bits to flip on. I checked thoroughly to verify that all the other sense/inhibit cards were mutually connected. They would all have access to the 6V supply, but the cards for bits 1&5 were isolated.
I then moved over to the A1 compartment holding the second 8K core stack. The exact same fault existed on that board - the two cards for bits 1&5 were isolated from the 6V supply. I then thoroughly checked the other cards to ensure they had 6V supply, but found another pair that were isolated. The cards for bits 11 & 17 for the low and high 4K of the core were also isolated. I had noticed that bit 11 was stuck on in the high 8K but didn't see bit 17 because that is one of parity bits.
Now I had the cause and could correct it by bridging those isolated card pairs over to the 6V supply from adjacent cards. Now the light bulb went off. These were the locations where my machine had three red jumpers. The jumpers I removed while troubleshooting the one bad addressing card. The jumpers I removed right about when the problem of the stuck bits began to manifest.
One of the jumpers was connected to only one pin, the other end dangling. The other two were connected to the same pin of the two cards in a pair, which showed as connected on the backplane. This was the reason I believed them to be nonfunctional and just stowed there for convenience. As well, they didn't look like they were a permanent fixture for the machine, which I would have expected to be done with wire wrap and annotated in the ALDs.
I didn't put the jumpers back where I saw them, but I put one for each of the three isolated card pairs to bring it 6V from a working adjacent sense/inhibit card. When I powered up, the memory was working flawlessly (other than the 1K missing due to the bad addressing card I still have to repair or replace).
It wouldn't have worked properly even if I had left the jumpers as I found them, since one of the three was hanging loose on one end. However, in hindsight I could have zeroed in on the problem quicker than I did.
My two core storage backplanes have a fault in the internal traces, one that interrupted a steady voltage used only for inhibit. If the main voltage lines had been interrupted, none of the logic on the card would have worked, but this particular failure was with a special feed.
Since the jumpers work, I will make a more permanent fix using a hand operated wirewrap gun and a special color of wire. I have annotated the ALD page for the voltage distribution inside the core memory compartments.
KEYPUNCH INTERFACE DESIGN
I found that Molex .062" connector male pins work well in the serpentine connectors on the relay sockets. I will solder these to the DB-25 cable wires and push them in place to install. I still need to find a good friction fit connector to use on the SMS card panel, then I can install the connections into my 029.
We are discussing the details of the protocol in order to get it finalized, after which I can begin coding the Arduino.
INTERNAL DISK DRIVE TESTING
I spun up a disk with the interface cable removed, looking over the operation of the drive without putting the heads down at flying height. Everything looked good, but I wasn't ready to risk the heads just yet.
Heads in position over rotating disk, but not lowered to flying height |
Closer view of the heads straddling the rotating disk platter |
1442 CARD READER/PUNCH RESTORATION
Now that the processor is working, I can get back to the peripheral restoration. I hooked up the card reader cables and brought up power. The reader will clear cards (NPRO function - Non-process run-out) but wouldn't pull in a card or go ready. I brought out the scope and the ALD to start the debugging. First up, verify that the start button is operating and that the hopper empty switch recognizes that cards are sitting ready to be fed.
Terminal blocks connecting the button/light panel to the logic cards below |
Hopper empty works, but the start button is dead. I opened up the unit, tested directly at the switch, but still nothing. Contact cleaner spray and worked the switch many times, but it wasn't going to work. Fortunately, there is a spare switch that was used for the local modification to add a Program Start button on the reader.
Back side of light/button panel, the failing switch is in the middle of the picture, near the bottom |
These readers have a variety of error checks that look for when all rows are blocked, when light is visible (e.g. holes in a column or the card is not in place) and relates that to the rotation of the mechanism. If the machine reaches a certain point but light is or is not detected, depending on the error, the machine stops with a check condition.
I can figure out what check we are getting by using the scope, plus I can watch and observe the exact conditions being experienced. It will just be a matter of time to step through, find any issues and get them fixed.
One mechanical problem I can see is that the stacker rollers that move cards from back to front along the left side of the machine are not turning. When I activate the NPRO function, the card gets to the left rear but then doesn't move forward. This may be a clutch, belt or something else mechanical. I ran out of time tonight but can continue this debugging until I get the reader operational.
Congratulations on nailing the memory problem! Nice to know that core is good.
ReplyDeleteThank you, Jack. It feels quite good to be working on new issues, moving forward, rather than 'stuck' on bits 1 and 5
ReplyDelete