Today was a marathon session moving scope probes, turning the machine on, interpreting the output, studying ALDs and repeat ad infinitum. The B bits 8 to 15 are all on, which means the shared line is pulled low by some gate.
Since it is a 'dot or', meaning all the outputs are wired together to a common pin, there is no way to know which of the driving gates is pulling low without finding one whose input conditions would legitimately drive it to a low output. That assumes that it isn't a damaged card which is pulling low in spite of inputs that should leave it high.
I started with the console bit switches, to verify that they are sending 0 or 1 based on the switch position. I looked at the last gate for the bit switches, the one whose output is wired together with all the other sources. Its input would vary based on the switch, but its output was always low. Since my working assumption is that some other gate is the cause of the low condition, not a problem with the bit switch gate, I moved on to look at all the other gates that were wired into the common pin.
My test switch was bit 14 and that common pin is driven by these gates:
- bit switch driver
- card reader/punch status bit
- card reader/punch data bit
- printer status bit
- forced bits during interrupt entry and prog load
- SAC data bit
The forced bits are how the machine implements an entry to an interrupt handler. During the fetch of the first word of a new instruction, the pattern for a BSI I instruction is put into the B register instead of fetching a word from memory. The second word of the instruction is an absolute address associated with the interrupt level - x00000010 plus the interrupt level.
Note that my memory errors in high storage have bits 1, 5 and 11 on, which are almost all the bits from this function but all piled together. However it wouldn't explain the problem I am currently shooting, which is why the bottom halfword has all bits set to 1.
I checked the card reader and the printer gates, but those did not have input conditions that would produce a low output and jam in the bit. I spent some time tracing the forced bits paths, since I had some flaky results with the interrupt request line that feeds this logic. However, it wasn't a good enough match.
That brings me to the Storage Access Channel (SAC). Its gate was indeed injecting a 1 value into bit 14 by driving the common wired pin low. That gate has two inputs, one of which is 'channel write gate'. Since I have nothing hooked to the SAC, It shouldn't be gating bits onto the shared bus but there it was, active and proud of it.
I could have spent some time sorting out why the low halfword was affected but not the upper half, but there was a jumper right on the ALD page which should be set so Chan Write Gate is tied to ground if there is no SAC. I put on the jumper, plus the other jumper that is defined when no SAC is present, to tie the cycle steal request to ground as well.
 |
| Jumpers added to B-B1 gate to block write gate and cycle steal from SAC |
I powered up the machine and my problem with xFF in the bottom halfword was gone! Finally, I am back to the pure situation of tracking down the forcing of bit 1 and 5 on for three of the four memory sections (independent logic cards for each 4K but two of them share a core stack of 8K words in a compartment.
I am thinking how best to track this down, now that the two extraneous errors I introduced while touching cards are resolved. What strikes me about this situation is that bit 1 and 5 are forced on in the low 4K of compartment B1 and both 4K parts of the compartment A1. The high 4K compartment of B1 has them off, except if I switch the data bit switches on for 1 and 5, the value is not stored either.
Memory sense amplifiers are wired together to a common pin (this is a familiar theme, isn't it). If any one of them is pulling the line down to zero steadily, then the other three parts of memory would think they had bits 1 and 5 turned on. If the card is bad, it wouldn't properly work for its own part of memory, but the symptoms would be different. that shines the spotlight on card A4 of gate D, compartment B1. It is responsible for bits 1 and 5.
I can swap it with another such card that is handling another pair of bits properly, to see whether the problem moves. However, I should be a bit cautious here, in case it is some other common factor and moving the card might result in damage to an otherwise innocent and working card. I am going to look for failure modes, such as a bad diode that reverses read and write currents, plus other issues. I can also do some continuity testing without power on to check out some other possibilities.
I feel a great sense of accomplishment in that I am back to roughly the stuck memory bit problem I was facing after I fixed memory problem A - the addressing card failure. I still need to repair or get a replacement addressing card, but that can wait until I know what causes the stuck bits problem. If that is solved or definitively connected to a specific component, then I can worry about repair/replacement.
I chose to swap A4 and A6 in compartment B1 of gate D, but it made zero difference. Whatever is going wrong is not a defect on the inhibit/sense card. It is clear I will have to slog my way slowly through signals in the memory, looking at each step from addressing to control, read to write, inhibit to sense, trying to spot the pont where the bits become stuck and from that determine what is causing it.
1132 PRINTER CABLE REASSEMBLED
 |
| The 1132 printer signal cable reassembled, cable clamp securely on sheath of cable |
KEYPUNCH INTERFACE DESIGN
I worked on the design and documentation for the new version 2 of the keypunch interface. One of my goals was to find a cleaner way to hook into the keypunch, rather than wires snaking all over. I also spotted an improved way to power the release mechanism and better ways to hook up to the release, multipunch and clear switches.
 |
| Logic gate for keypunch to which all interface wires can be connected |
Two diagnostic programs make sense, one to run just to verify the reasonableness of the wiring at first install, the other to test all the functions of the combined interface plus keypunch. I planned these out at a high level.
One of the steps needed before attaching the new interface to a keypunch is to swap some wires between the normally open (N/O) and pole contacts on relays. The sensing pins that read the holes in a card at the read station in order to duplicate the holes into the next card, sitting in the punch station, is connected with 48V on the common bar and each pin is hooked to the punch solenoids for a particular row.
This connection of 48V and the punch solenoids only happens when the DUP1 and DUP3 relays are activated. When the relays are idle, no connection exists - the normally closed (N/C) contacts have no wires attached. Thus, it doesn't matter which wire is hooked to pole and which is hooked to N/O, a switch connection is commutative. As wired by the factory, the common bar is hooked to N/O and 48V is hooked to the pole on DUP1, while each of the pins is hooked to N/O on DUP3 and the punch solenoids are on the poles.
 |
| DUP3 relay at left, DUP1 is next to it |
When the DUP1 and DUP3 relays are inactive, 5V fed to the common bar will pass back on any sense pin where a hole exists in the card, coming out to the interface box. When the relays are energized, the common bar gets 48V and any sense pins over a hole will activate the punch solenoid for its row.
I swapped all the wires on the two relays and then tested out the duplication function to be sure it still worked. I found that a couple of the pins in the contact holes were touching adjacent pins, which blocked that row from punching. With pliers and a small screwdriver, I got the connections in good shape, free of shorts, which gave me perfect duplication on the keypunch.
 |
| Connections on back of relay panel, with push pins into serpentine connectors |
Some wires we add will need the friction fit connectors, which can stack up two or three deep on a tab, when they are going to attach to the SMS panel. Other wires will need the push pins if they are going to be hooked to the relay sockets with their serpentine connectors. I will need to get a supply of both types of connectors, to hook to the wires for the cables I will attach.
 |
| tab connectors on back of SMS card socket panel, with friction fit connections |
REPAIR OF DISK DRIVE INTERFACE CONNECTOR
Part of the maintenance procedures for the disk drive are done after disconnecting the interface cable from the mini backplane on the drive, but when I removed it the connector came apart rather than detached from its slot.
The end of an SLT card or connector is a black plastic grid that fits into the backplane slot and allows the 24 pins to stick up into the connector. Metal clips are wedged onto the end of the PCB, making contact with the copper clad, gold plated trace of the board. The clip is pushed into the holes in the black plastic grid, so the pin from the backplane pushes up and into the metal clips.
 |
| SLT connector, black plastic grid, side that touches the backplane |
 |
| Inside of the black plastic grid where the metal clips would fit |
I was able to pull the grid out of the backplane slot and reassemble the connector. It is ready for reattachment when it is time to connect the drive once again.
 |
| Repaired connector for disk interface cable, ready to plug into mini backplane |
No comments:
Post a Comment