Wednesday, June 12, 2024

Deoxidizing contacts, looking into dim/missing lights with the 3819 card, verifying cycle steal behavior

MY FIRST ATTACK WAS ON THE FORMS SWITCH ON THE 1053

That was indeed an open circuit due to oxide but quickly recovered with Deoxit and exercising the switch. That was the reason that the Forms Check lamp was lit on the 1130 but wouldn't go out when I pushed down on the roller that senses paper in the path. 

SWAPPED 3819 CARD AND SAME CIRCUITS NOT WORKING PROPERLY

I put another 3819 card in the place of my repaired one, into the D5 slot, but the results were identical. Still no Run lamp, a dim Parity error lamp during an error, and no restore of the keyboard. That immediately points the finger at the board (backplane), where traces must have been partially and in some cases fully erased by the 48V surge through the failed tantalum capacitor. 

I will need to run wires to restore continuity to the pins on the backplane, as well as looking for shorts to ground or other issues in that area. 

TESTED THE PINS THAT MY CYCLE STEAL MEMORY LOADER WILL USE

My new memory loader that uses cycle steal, what is called Direct Memory Access (DMA) today, is based on the response to pulling certain pins to ground on the 1130 as well as sensing certain signals that control the progression of the state machine on my device. 

I put the scope on those pins to verify that the signals I sense do what I expected, then grounded the level 0 cycle steal request pin. I did see the machine taking cycle steal memory cycles, however since I didn't present any address bits the machine was reading/writing to location xFFFF which has the bad address bit 9. The result - Parity Error - as one would expect.

My future testing will use the Arduino and my board so that I can target single memory cycles at chosen addresses, which will let me confirm the rest of my assumptions behind the loader. It also will let me load memory locations and verify that the cycle steal mechanism is completely healthy, at least for level 0. 

BEGINNING DEOXIDATION OF THE KEYBOARD CONTACTS

I opened the table and removed the keyboard mechanism to give me access to all the exposed contacts where oxidation will have formed over the decades. 

The bails on the left and right sides at the back of the keyboard are open contacts that will need the most work. I worked with a burnishing tool as well as Deoxit spray, using an ohmmeter to validate when the resistance was back to nearly zero for each contact. 

At the bottom of the keyboard each keylever moves a vertical bar which at the bottom forces contacts closed under that key. This also needed burnishing and spraying to get the contacts down to nearly zero resistance.


I will check that all is well by reinstalling the keyboard and running the hand loop from the CE Handbook that displays the resulting code produced by every keypress. It depends, however, on the restore solenoids being driven, so this test has to wait until I fix the issues around slot D5 where the 3819 card caused damage. 

No comments:

Post a Comment