Back to the need to load the 1130 SBR card pins the same as my oscilloscope probe

THE WATCHED POT NEVER BOILS - OR IN THIS CASE THE BIT NEVER FAILS

I set up the scope again to watch the exact analog signal occurring when bit 14 fails to set in the most common situation triggering the parity stops while using my 1130 MRAM memory board replacement for the IBM core memory circuitry. I put another on bit 10, which is the other that comes up less frequently. 

Putting the machine in the perpetual Storage Display loop reading all memory locations, I found that bit 14 and bit 10 didn't fail. The machine ran longer until some other bit failed to latch into the Storage Buffer Register (SBR) and the machine stopped. 

Observing the pin with a scope probe seems to stop or greatly reduce the rate of failures occurring for that bit. The 'quantum' behavior where the act of observation changes the results. 

I had tried to recreate the electrical effect of the probe being attached, modeling the oscilloscope probes internal circuitry and applying what should be an equivalent set of components to the pin on the backplane where the sense pulse signal from my board arrives, the other end of the circuit hooked to the ground pin nearby The equivalent circuit did not reduce the failure rates at all. It was NOT equivalent to whatever analog magic happens with a jumper hooked to a probe is attached.

However, I just realized a significant difference exists between my equivalent circuit. When I hook up the four scope probes, the first one which picks up the Parity Stop signal is where I make a ground connection. That signal is in gate B, compartment A1 but the SBR cards where the other probes connect are all in gate B, compartment B1. Thus, the probe hooked to the pin for bit 14 has circuitry through the probe to the scope, but returning out of a different probe to ground on another compartment.

How that impacts the behavior I don't understand, but perhaps I can figure out the way the probe impacts the pin, then recreate the equivalent circuit. 

Fighting with the SLT contacts to solder them onto my 1627 plotter controller card

CONTACTS TURN AND TILT WHILE SOLDERING

I attempted the method of soldering one side using 183 C solder paste and hot air, so that I could add the other side's contacts using lower temp (138 C) paste without dislodging the first set. However, because my pad on the PCB does not match the shape of the contacts, as the solder melts the contacts are free to float and turn. 

I stopped heating the paste after the three rightmost ones melted and moved out of alignment. The left ones moved due to my touching them as I removed the board from the soldering area of my workshop. You can clearly see the square small pads that permit the contacts to move. Normally when a pad and the component are the same shape, the liquid tension of the melted solder will pull the part into perfect alignment. 

PROPER FIX IS REDRAWING THE CONTACTS ON THE PCB

I believe that I must redraw the contact pad on the PCB to match the actual contacts, then remake the board. That should give me the ability to solder these down properly. However, that involves some time, both to modify the KiCAD files, and to approach PCBWAY.COM who sponsored the first run of the boards to request a second build. 

NEAR TERM APPROACH WILL BE A JIG TO HOLD 12 CONTACTS IN PLACE

I have to figure out a jig that I could insert contacts for all 12 positions, hold them in place, set the assembly onto the PCB and then heat the solder paste to melting without destroying the jig. This will be complicated to work out, since the contacts, being springy, won't all have exactly the same shape. However, the jig must hold them so that the bottom contact area will be flat on the PCB in the right location. 

Thus there is a design and manufacturing complexity to such a jig that will hold all those contacts in the proper alignment. It also must not melt at temperatures up to about 200 C. Finally, it must allow the hot air to easily flow around the contact and the PCB so that the solder paste melts and then cools when hot air is removed.

If this is going to take longer than the time to get permission and then receive finished PCBs, it will be moot. Give me a day with my thinking cap on. 

Showing redundant wirewrap connection for Sense Bit 14 entering the SBR card

WHY THIS REDUNDANT CONNECTION?

The wire around pin D10 of slot L3 is the one that carries the -Sense Bit 14 pulse from memory into the card that implements bits 14 and 15 of the Storage Buffer Register (SBR). Tracing the wire up to the pins for cable T4, we see that wire connects to L1 E11 which is -Sense Bit 14 coming from the memory compartment (or my 1130 MRAM board). All the sense bit lines from cable T4 are connected through the backplane to the pins of the card slot where they are implemented, including bit 14, so this wiring is redundant.

IS THIS A CLUE?

OR . . . There was a failure in this backplane causing some traces to become broken, which required the wire wrap to restore signal continuity. If this wirewrap connection became corroded at either end, it might lead to sporadic errors from vibration of the machine. I can check this theory by adding another wire between the pins. If the problem disappears with bit 14, I will have found wisps of gunsmoke, although not precisely the smoking gun itself. 

Adding functionality to 1627 Plotter controller card project

REQUEST TO RECEIVE PLOTTER COMMANDS OVER USB SERIAL LINK

A great suggestion came from a museum that will build one of my 5806223 substitute cards to include 1627 plotter support in their IBM 1130 system. If my card could output serial data through the USB connector of the FPGA daughter board, they could use that to produce an image on a monitor of what the plotter would be drawing, but without having to use plotter paper and pen ink. 

When my card receives an XIO Write command to the plotter from software in the IBM 1130, it will grab the six bits of the request and send them as a stream of six ASCII characters, 1 or 0 depending on the state of each bit, followed by a carrier return and line feed. The serial link will run at 38400 baud which is more than fast enough to handle the rate at which the plotter can accept movement commands (an absolute maximum of just over 263 movements per second). 

ADDED CODE TO PERFORM THIS IN THE DIGILIENT CMOD S7 FPGA

The logic to drive the serial port required a 100 MHz clock, which I generate from the onboard 12.5MHz clock of the FPGA. The logic now has two clock domains, thus I made use of an independent clock FIFO to pass the data from my original logic over to the faster data pump which will format and drive the characters out of the serial port.

As the main logic processes the XIO Write from the 1130, it grabs the six bits and pushes them into the FIFO after which it handles the physical plotter and status back to the 1130. 

My data pump grabs any word pushed into the FIFO. For each of the six bits in turn, it will set up an ASCII 0 or 1 character and trigger the UART logic module. The UART outputs a start bit, the eight bits of the ASCII character and a stop bit all at 38,400 baud. The UART logic signals readiness for the next character, which advances my data pump to step through the six bits from the XIO Write. Once done outputting those six characters, it sends ASCII characters x0D and x0A, the carrier return and new line codes. 

SIMULATION TO VERIFY THAT THE LOGIC CORRECTLY OUTPUTS A SERIAL STREAM

I modified my testbench to capture the UART transmit signal coming out of the UART logic and ran it with both/drum pen movements and pen raise/lower commands. It performed appropriately and confirmed that the output stream will complete before a single pen or drum movement will finish. 

Working on the connectors for the substitute 1627 plotter controller card

NEW APPROACH - BORROW CONNECTORS FROM A SACRIFICIAL IBM SLT CARD

I came to the realization that if I could take the specially shaped connectors from an IBM Solid Logic Technology (SLT) card and install them on my board, it would give me a card that will snap into the backplane socket and lock in place. This absolved me from the need to design and build a hold-down method for the card. 

I grabbed a card from my stock, took the plastic connector covers off, and then unsoldered the 24 connectors. I hadn't shaped the copper pads on my printed circuit board to the exact shape of the IBM connectors, but I experimented soldering some onto the card and found that they would work with the existing PCB design.

I used my heat table and hot air rework tool with solder paste to attach the connectors. Many of them slid into decent alignment, but others were skewed or shifted relative to the card edge. The plastic connectors that fit over the card connectors have dividers that fit between each contact, thus alignment is more critical than simply to ensure pin contact without shorting to adjacent connectors. 

GOING TO NEED SOME KIND OF A JIG OR NEW INSTALLATION PROCESS

The next and more serious problem arose when I flipped the card over to install the connectors on that side. The heat that melted the solder paste and allowed the contact to pull into position was conducted to the underside and also remelted the solder under the previously installed contacts.

The contacts on the bottom side would either fall off or shift out of position. Some turned 180 degrees from their intended positioning. While I could finesse the contacts enough to get the plastic covers over them, unless the contacts were all at the proper position at the edge of the card, the locking action of the backplane pins wouldn't be reliably applied to all 48 connectors. That might be solvable with enough fussing, but the desoldering effect on the other side of the card is the show stopper.

I had my hot air tool set to 180 C but the solder paste has a melting point of 138 C thus I should drop the temperature to maybe 145 C. My table was set to 130 C which is too high given the low melting point of the paste, so I should drop that to perhaps 115C. I still believe the heat will conduct through the PCB and release the contacts on the other side from where I am working. 

One idea I had was to use two solder types, with different enough melting temperatures. I could install on side using the higher melting point solder, then lower the heat and use the other solder for the back side. If done properly, I would never soften the solder joints from the side I first installed. I just ordered some solder paste with a temperature of 183 C which should arrive tomorrow. 

That wouldn't perfectly solve the alignment issues, so I also am investigating some kind of alignment jig that could hold all 48 connectors in the proper spacing on the pads of the printed circuit card, so that I could somehow get hot air in to melt the solder paste for all the pads. Once they cooled I could remove the jig and have all the connectors in their intended locations. 

The jig would need to be able to withstand temperatures of about 150 C (around 300 F) since I was using 138C solder paste. It also must not stick to solder. 3D printed nylon parts generally use filament that melts at about this level, making them unsuitable. Quick manufacturing with laser cutting or 3D printing typically involves materials that won't stand up to the heat. 

1130 MRAM board effort continues - not quite there yet

SWAPPED CARDS BUT ISSUE REMAINS AT BIT 14

The issue is somewhere from the pins of sockets L2/L3 in gate B compartment B1 of the 1130 out to my 1130 MRAM core memory replacement board. I continues to be intermittent, but fails on the order of once every few hundred accesses. I also find that bit 10 continues to fail but that might be one time for every few dozen times we stop with a bit 14 error. 

I resoldered all the leads and components on my PCB that are involved in handling bit 14 - no change in the results. I examined the backplane where the card for that bit plugs in (L3) and noticed that a wire wrap connection was made from the T4 cable connector on top down to the pin where the sense pulse for bit 14 is connected to the card. That connection should already exist on the backplane, so the added wire seems redundant unless it is fixing a defect in the board. If there was a defect it might have spread a bit. 

Continued confusion over analog issue with the 1130 MRAM board BUT progress made

SLOWING THE EDGES OF MY SENSE PULSES

I could apply a low pass filter to remove high frequencies from the signal so that the pulse is rounded, to see if that will correct for whatever the heck is going wrong on the Solid Logic Technology (SLT) circuit board that is implementing the Storage Buffer Register (SBR). That card expects a falling edge from my board as a sense pulse and should turn on the SBR bit when it receives the pulse. However, once every few thousands to millions of times, it doesn't quite turn on. 

Hooking a scope probe to the pin seems to mostly tame the beast. Thus if I could add the same impact to the pins at the backplane, I might be able to achieve consistent reliable operation. A complication is that the signal is directly routed from my board to the pin where it enters the SLT card, so I have no reasonable way to insert a series resistance. This means that a typical RC low pass filter isn't practical. 

I did develop a load that will look similar to the probe - a simplified equivalent circuit ignoring cable inductance, cable capacitance and the complexity of the actual equivalent circuit. I then increased its low pass behavior hoping to slow the edges a bit more. If that does solve the analog issue plaguing the memory substitution project, I will see no parity error stops at all and fully correct readback of memory at all times. 

The load circuit is a resistor and capacitor in series from the pin to ground. I have 18 pins that need the loading applied, if this works, which I will support with a teeny PCB that slides over the pins in place on the SLT backplane. The SBR card is a double width card that implements two bits of the register. 

I put together a couple of the circuits and hooked them to the two bits that seemed to be the most problematic. It had no effect at all. I think this was a false trail. 

SWAPPING CARDS TO SEE IF THE BITS THAT FAIL MOVE

The SBR register is implemented with several SLT cards - IBM type 5804619 - each card implementing a pair of bits. Eight cards are installed in gate B compartment B1, in slots B2/B3, C2/C3, D2/D3, E2/E3, H2/H3, J2/J3, K2/K3 and L2/L3. The most common bit error is bit 10, which resides on the card in J2/J3 but there were also some errors on bit 13 which is K2/K3. I will swap these with the cards in C2/C3 and D2/D3. If the failures move to those bits it will point at the card, but if the failure does not move then the issue is in the cabling, backplane, or my design. 

The problem with bit 10 disappeared, and in fact the only sporadic drop is with bit 14 which is one of the cards that I did NOT move around. Perhaps the rodent urine atmosphere layered a bit of corrosion on some contacts between the cards and the backplane, which I wiped off by the removal and insertion. I will try to swap L2/L3, which implements bits 14 and 15, with the card in E2/E3 in the hope that this resolves any added resistance that was plaguing the circuit operation. 

HAND TOGGLED CODE TO VERIFY THAT DATA IN ALL WORDS MATCH THEIR ADDRESS

My loop wrote the address of each word as its data, then the new loop read and compared the contents of each word with its address as a means of catching any mangling of data or addressing defects. The program ran to successful completion several times. 

USING STORAGE DISPLAY HARDWARE FUNCTION TO FIND BIT DROPS

The last work I did today was to let the machine loop continually reading every word of memory, unless a parity stop is forced if a single bit gets dropped. I know I am not dropping pairs of bits because of the loop that verified memory word contents match the address, but I will get stops where bit 14 is dropped. I can easily tell that is the case because the Storage Address Register (SAR) should always match the SBR due to what I wrote throughout memory. In each stop, bit 14 was missing in the SBR but part of the address in the SAR.