The IBM360/30 gets stuck in a microcode loop. The documentation indicates that a branch should be taken if the Z-bus is zero, and the branch should be taken. The branch is not being taken.
A previous annoyance was that the microcode would stop at address 0xB46. As the documentation indicates for that location, it is checking that a register is zero. Hmm… checking for zero? That is the problem with the loop not stopping. So I dug deeper into this stop. There was a stuck bit! And here is what I found:
The circuit is an AND-OR-Invert gate and the output of the AND was high. The above circuit is the AND gate. If any of the inputs on the bottom go low the output should go low. The output was not going low. However, there is nothing on this circuit to force it low, but rather it allows the output to go low. So, the problem was the input to the OR gate:
Aha! That transistor with an X on it is not good. Fortunately, we have spares of this SLT module, and replacing it fixed the problem with the first microcode stop. However, the microcode loop with the non-taken branch is still not working as documented. Dig deeper…
The IBM360-30 uses Printed Card Capacitor storage for microcode.
The cards were created by printing Silver ink on Mylar:
Or etched copper:
304 cards make up the microcode. I scanned them all.
My procedure was to remove one card, clean it, scan it, and then replace it before removing the next card. My original thought was to clean the cards thoroughly using water, possibly with soap, as the machine was stored in a damp location. However, the cards turned out to be quite clean, and only required wiping.
Scans were captured at 24-bit color, 600-bpi resolution. The captured area was 3.15″ x 7.25″, and saved as .BMP files (24MByte). I used different color backgrounds, and chose the sky-blue background as providing the best contrast for my eyes. Processing of the images used the Blue channel. Determining a threshold of hole/not hole was tricky, as there were two types of card, and each card had two areas to decode: the first 10 columns as card ID, and columns 11 through 70 for microcode data. Registration of the scans was quite consistent for row alignment, but column alignment was variable. Only one card needed adjustment vertically, but all card images were trimmed to align the first column. Data was decoded from the card images and stored in a card archive.
Well, not quite.
It appears the memory can be read, but it also looks like it is not being restored/written.
See how the Yellow trace and the Blue trace ~almost~ are high together? Well, IF they were both high together then the memory is supposed to write.