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. 

Collecting data with logic analyzer on 1130 MRAM parity stops - tantalizing hints

ERROR STOP WE ARE TRYING TO CAPTURE

The IBM 1130 employs odd parity to detect core memory errors, where each 8 bit half of a memory word has an associated parity bit to make the count of bits with a 1 value be odd. If the count is not odd when retrieving a word, the machine stops with a Parity Check error. My replacement for the core memory has a much more reliable memory technology and thus does not bother storing parity bits with each word. It instead generates the correct value for the parity bits as a word of data is read.

I can load and display memory several ways using my 1130 MRAM memory replacement board, with no detected errors. However, if I load the IBM high core memory diagnostic program and run it, the program encounters parity stops at predictable, repeatable points in the code. This happens after the code has successfully run through the same point more than a thousand times. 

I could also repeatedly see the error when I store and then display words at certain addresses. Anything with data having a 1 in bits 8, 12, 13 and 14 would come back with bits 12, 13 and 14 as 0 instead of 1. Because an odd number of one bits had been removed, the parity bit would have had to change to ensure odd parity, but it corresponded to the value when 12, 13 and 14 were correctly read as 1 bits, thus triggering the parity error. 

LOGIC ANALYZER SETUP

I used my DSLogic USB logic analyzer because it is very portable and easy to connect, but it is limited to 16 channels of data capture. That does result in iterative changes to use of the probes as I narrow in on a problem. Of course, my initial 16 channels of data need to provide some clue to where to next look. 

I need a trigger signal, which is the +Parity Stop signal when the error is first recognized. I will capture the two parity bit flipflop values and the signals generated when a halfword plus the parity bit has even parity. The two sense signals from my board whose pulse sets a 1 value into the parity bits, -Sense 16 and -Sense 17 will be recorded. Rounding this out will be the +Storage Read signal to place the activity in context of a memory cycle. 

The other eight channels will be recording sets of data bits from the SBR or address bits from the Storage Address Register (SAR). Since there are 16 data bits and 13 address bits, it will take at least four runs to record all of them in conjunction with the eight channels from the paragraph above. 

OSCILLOSCOPE USED TO LOOK AT SENSE PULSES FOR BITS 12, 13 AND 14

The four channel scope was set up to trigger on the +Parity Stop signal in one channel and display the -Sense Bit 12, -Sense Bit 13 and -Sense Bit 14 signals on the other three channels. I wanted to confirm whether the 1130 MRAM board is emitting pulses to set the bits to a 1 or not. 

Indeed, I could see pulses coming from my board but the SBR bit was not being set in the 1130. I experimented with longer pulses, with no effect. I then tried separating the pulses with 40 ns pulses within each 75 ns state machine step, but the results became worse. 

RECOGNIZING THAT THE SAME OLD UNEXPLAINED ANALOG ISSUE PERSISTS

 I rebuilt my board entirely from the prior design that seemed to have too much ground bounce, thus encountering spurious retriggering that produced sense bit pulses at improper times. I continually strengthened the ground plane, power plan and size of the power connections within my board. I drove the pulses with very fast discrete transistors controlled by the logic chips. I varied timing and spread out the bit setting. Ultimately, none of these changes gave me a memory that was reliably and consistently working. 

There are constraints on how early in a read cycle that I can set bits in the SBR; I believe I must wait at least 450 ns so that I am in clock step T1 of the four clock step read cycle (T0 - T3), but also must complete all the bit settings before reaching clock step T2 because the 1130 may begin gating the results in the SBR to other registers in the system within that step. 

The two parity bits do not need to be emitted within that constraint. They only need to be set by the end of the read cycle since they are interrogated midway through the ensuing write cycle at clock step T6. This still requires the 16 data bits to be pulsed in that interval. 

This gave me a tight window of 450 ns in which to set 16 bits, just over 28 ns if each bit were set separately. The Solid Logic Technology (SLT) family used in the IBM 1130 is 30 ns nominally, making this impossible to achieve with a single bit in a step.  

If I pulse two bits in each FPGA step, then I have just over 56 ns for the pulse, which should be long enough. However, since I don't understand what is happening with the analog behavior that leads to this issue, I am not satisfied that such a change is sufficient. 

MUSINGS

Each pulse sent to the 1130 is in fact a current sink from the IBM 1130 through an open collector transistor on my board. The power rail on my board is not involved in this current flow just in the minor 1.5ma drive current to the transistors as well as minor switching current in the 74LVC08 quad 2 input AND gate that is delivering the 1.5ma to each transistor. 

The ground plane of my board is joined to the ground bus of the 1130 system with stranded 18 gauge wire which should keep my ground plane from straying too much from the 1130's however my hunch is that this is where the problems arise. When I watched pulses that failed to set the SBR bits, the pulses didn't make it all the way to zero volts on the scope. They seemed to bottom out higher, which could be caused by a voltage differential between the ground planes. 

With an inductance of 800 nanoHenry and an effective resistance at 2.2 Mhz of approximately 60 milliOhms, the resulting impedance is around 20 ohms, giving me a voltage drop of almost one-half Volt on the ground conductor for those high frequency signals if they were a continuous train. 

This is quick and dirty, but it is consistent with the scope observed pulse bottom rising above 0V. The germanium diodes in SLT circuitry have a voltage drop around 0.3V, thus I could easily drive up the pulse bottom so high that it fails to switch the transistor in the register. Depending upon what other pulses were produced close in time to the affected one and what ringing might occur in the ground wire, I could see that it would be possible to get instances where it fails to set the bit. 

I still don't see how specific data patterns cause the failures. These are spread across three SLT cards in the B gate compartment B1 at H2/H3, K2/K3 and L2/L3, across two of the cables between my board and the 1130 and across multiple parts on my board. 

DOING MORE INVESTIGATION

After tightening up the FGPA code even further, I found that the 1130 would run for 5-15 seconds before encountering a parity stop. I noticed that bits 10 and 13 were the most likely to not register in the SBR when they should be 1. 

I then hooked the scope up to the -Sense Bit 10 and -Sense Bit 13 pins on the 1130 to watch the signals when a failure tripped a parity stop. Interestingly putting the scope probe on one of the pins dramatically reduced the rate of that bit failing to set. Putting probes on both led to the machine running 25 to 30 seconds, looping through memory successfully, prior to hitting a parity stop. The machine executes almost 277, 778 reads and writes per second, thus the failure rate was around once per 7 million accesses. However, only words with a susceptible bit set to 1 would cause a parity error, thus the actual error rate is closer to 1 in 3.5 million accesses.

Close, so close, but far from acceptable when the computer may run for many hours to days. However, the fact that putting leads on the backplane pins lowers the error rate is a tantalizing clue. The scope doesn't show ringing on the signal when observed at the pin, but that may be due to the impedance of the scope probe - its capacitance and resistance. The input resistance should be around 10 megohms and the capacitance perhaps 10 picofarad. For 100 MHz signals, the impedance is closer to 100 ohms and at 1MHz the impedance is still around 10K ohms. 

The effect of the frequency dependent impedance is that the probe absorbs the higher frequencies more than lower, rounding the pulses. It acts to slow the rise and fall times of the pulses, which appears to improve the reliability of the memory. Thus I may need to develop a filter to produce similar but larger rounding of the pulses.