Saturday, October 11, 2025

IBM 1130 MRAM memory replacement - continuity test, then testing on the IBM 1130

CONTINUITY AND SOLDER JOINT TESTING

I found one pin that appeared to be soldered well but lacked continuity - the output of the write timer circuit. Based on this I decided to do a more thorough test using the PCBite probes to check that each pin on a chip had continuity to the appropriate end points and that there were no shorts to adjacent pins. This was time consuming but worthwhile.

I came across about ten connections that looked like shiny good joints and the pin wouldn't move when pushed sideways, but electrically they were capacitors or open circuits. I carefully repaired every one of them.

I took the time to check many of the control connections and the memory address lines for good continuity. Once I believed this was likely free of bad connections, I moved over to test with the 1130. 

LIVE TEST ON THE IBM 1130

I plugged the board into the IBM 1130 in place of the IBM core memory compartment B-C1, connecting cables T1, T3 and T4 as well as +12VDC power. The machine was powered up and I could do some quick tests. 

Using the rotary mode control set to Load and to Display, I can load chosen patterns into memory and read the results. The pattern is toggled with the 16 console entry switches (CES) and the results show on the display panel as the Storage Buffer Register output. dete

I saw a few spurious Parity Checks - which should never happen because the two parity check bits are created on the fly by my board based on the memory contents. Mostly the memory was storing the data I set on the CES and retrieving it when requested, but there were those phantom Parity Checks to consider. 

I then used the Storage Load and Storage Display functions that are available to the repair engineers - these let me set a pattern on CES and loop repeatedly through memory setting that into every word. Once done I could perform the Storage Display and loop repeatedly reading memory. During these events I found a few more phantom Parity Checks. 

More disturbingly, when I went back to use the rotary mode to display locations, after having set every word to FFFF, the data coming back was somewhat random, not the pattern. 

FIRST THEORY

I suspect this is a timing issue, because the detection of a parity check occurs during the write portion of a storage cycle, when the data should have been established along with its chosen parity by some logic in the CPU. It could also be a continuing issue with reliably triggering the B register flip flops with the sense output pulses. 

I will have to set up a logic analyzer to capture key signals while I run some Storage Load, regular load, Storage Display and regular fetches from memory locations. That will help me focus down on the area having problems. 

No comments:

Post a Comment