Updated memory substitute board, chasing down two failures

NOW THAT THE MAIN ISSUE WAS IDENTIFIED, THE FIX WAS APPLIED

Amazon had a vendor offering 0805 size surface mount resistors in a set that included twenty at 470 ohms, available to deliver rapidly. I reworked the 1130 MRAM printed circuit board to replace all eighteen of the 2K base resistors with these 470 ohm parts. The board was reconnected and I confirmed the results with a very long period of cycling through memory reading every word of every address. 

RUNNING HIGH CORE MEMORY DIAGNOSTIC, FAILS AT ONE POINT

I used my core memory loader capability I had built into the VCF 1130 system to load core with the IBM diagnostic program that loops through core memory checking it for errors. It fails in one of the six tests, in one specific totally repeatable points. It gets a parity check and stops in test 2, but after that single error, if I run the next four tests, they run to completion successfully

Test one fills memory with all one bits, then complements to all zero bits, checking each location for the expected pattern. 

Test two fills memory locations with the value that matches their address, then complements the value and for each location it verifies that both results match the expected pattern.

Test three alternates setting each location to 0x5555 and 0xAAAA patterns, verifying that the memory returns the expected pattern.

Test four begins setting all locations to 0x8000, verifies that, then shifts the bit one right and repeats until all sixteen bit positions successfully record a 1 in that position and zeroes in all other bits. It then complements to 0x7FFF and shifts right to verify each location has a zero in the bit position and all ones in the remaining positions.

Test five loads blocks of all zero and all one bits throughout memory, called the worst case pattern for core memory. It checks, complements and rechecks this four times. 

Test six loads the complement of the worst case pattern and then checks, complements and rechecks four times. 

While running test two, doing the complement of all locations, it stops with a parity error while doing a LD I (load indirect) of location 0x0FF3 which returns 0x0FF7, bit 13 turned on unexpectedly, which triggers a parity error.

I reran this many times. It always stops with the exact same issue. The locations prior to it have all been complemented, but it stopped at this point so the addresses going onward all have the original memory address as their contents. I can manually load and display location 0x0FF3 successfully. 

The fact that this is so deterministic and repeatable tells me it is not a marginal signal issue like the earlier problems. However, the parity error can only happen if my board returns a pattern and generates a parity check bit that doesn't match what was returned. It has to cause the value of bit 13 to turn on then revert to the correct value within about 160 nanoseconds during the read cycle. 

If bit 13 is turned on in the 1130 Storage Buffer Register (B register) but not emitted by my board, that would also cause the problem. Several sources feed the B register flipflop thus another circuit could flip that bit on, but it would need to be triggered in some verify specific case such as we see here with address 0x0FF3. 

I will have to instrument to catch what is happening here. 

RUNNING CPU DIAGNOSTIC PROBLEM, FAILS AT ONE POINT

I decided to load the IBM CPU diagnostics program which tests every instruction in all variants including all the edge cases. That would be the confirmation that the machine is completely happy with the new memory I provided with the 1130 MRAM board. 

The diagnostic runs all the way through until the last test, which rigorously tests the multiply and divide instructions. It stops with a wait code 0x316D which means that during one iteration of the test, the ACC (Accumulator) was not zero when it was expected to be.

This test tries every number from -32768 to +32767, multiplying them in phases by 0xC000, 0x8000, 0x4000 and 0x2001 then dividing by the same value. The failure occurred as the test was cycling through all the numbers in one of the phases, where one specific calculation ended up with a non-zero value in the ACC. The value shown in the ACC is the same when I ran this several times, so once again we have a deterministic and repeatable failure in very specific conditions. 

The diagnostic has an option to turn off the multiply-divide check, since that is relatively time consuming to run given it tries 65,536 values in four phases of multiply and then divide operations. When I set that console entry switch to skip the check, the CPU diagnostic runs to successful completion with no errors. 

I will need to collect more data about the specifics of the failure - which phase and what value of the integer was being used to multiply and divide. I can hand test the operation of the instructions for that particular set of values, as well as possibly instrumenting to see what is happening at the time it fails. 

I am not certain yet how I can trigger the logic analyzer to freeze when it fails - perhaps an instruction address match to the wait condition. Naively this requires 13 address bits out of my 16 possible signal leads. It still might be useful if I can use just enough of the address bit to positively match that instruction but not trigger incorrectly on other instructions during execution. 

BOTTOM LINE - TWO ISSUES THAT MIGHT BE MRAM RELATED OR CPU FAULTS

These are likely related to the same root cause. If I can spot some commonality between the conditions that arise with the CPU diagnostic error and the memory diagnostic parity check, it might point me somewhere useful. Otherwise, debugging at least one of them to the root cause should be enough. Once I understand the cause I can correct the problem and end up with a machine that passes both diagnostics cleanly. 

Building the Diablo 2315 Archiver circuit board

CIRCUIT BOARD ARRIVED - THANK YOU PCBWAY.COM

PCBWay.com offered to sponsor the production of the main printed circuit board for my project to archive the 2315 disk cartridges containing software and data from IBM 1130 systems. I used a Diablo model 31 disk drive with standard density heads, which is compatible with the 13SD disk drive built into the IBM 1130. 

The shipment arrived today, securely packed, shrink wrap sealed with a desiccant packet. I opened everything and inspected my new PCBs. I chose to make these four layer boards with a blue solder mask and white silkscreen to give it an appropriate color scheme for the retro computing systems whose data I was archiving.

Well made attractive blank PCB

Protected in the box

Sealed with desiccant packet

PURPOSE OF THE PCB

This board plugs into the top of a Digilent.com Arty A7 FPGA (Field Programmable Gate Array) board which is where the logic and memory resides that will drive the Diablo 31 drive to read the entire cartridge and then upload it over a USB serial link to a program that build the file image on a PC. 

The PCB regulates power, producing both 5V and 3.3V rails from the input 9V supply, feeds the input 9V unregulated DC to the FPGA board, and delivers the two regulated rails to the circuitry on the PCB. I has an IDC-50 connector where a cable from the Diablo drive is plugged. Resistor networks provide termination of the incoming Diablo signals as well as transistor drivers to create the control signals out to the Diablo drive. 

Since the Arty A7 board uses a Xilinx Artix A7 FPGA chip with 3.3V LVCMOS input-output pins, I placed 74LVC125 buffer chips between the Diablo and the Arty A7 to shift the voltage levels from the 5V DTL signals of the Diablo to the 3.3V levels for the FPGA. The transistors that drive the output signals serve a similar purpose, controlling the base of the transistor with the 3.3V output of the FPGA and controlling an output line pulled up to 5V or sunk to ground by the transistor. 

INSTALLED THE COMPONENTS AND CONNECTORS

I had already bought or collected all the components to go on the PCB, thus as soon as I got to the workshop I began the assembly. I chose to solder on the resistors first, then the transistors and buffer chips as they were all surface mount. Next came the voltage regulators and their capacitors. At the end, I installed the various pin headers, the IDC-50 socket and the barrel connector for the 9V wall-wart that powers the assembly.

I did run into a snag - I had somehow ordered a 1.27mm pitch 50 pin socket instead of the 2.54mm IDC type. I searched the shop and found a breakout board that could donate the correct socket - to be replaced when I get the correct socket in the mail. 

Oops

Yanking this off the breakout board

FITTED THE PCB ONTO THE ARTY A7 BOARD AND CONNECTED THE DIABLO CABLE

The PCB has pins on the bottom that fit into the connectors atop the Arty A7 board, giving access to the input-output pins I was using for the archiver. It also supplied the FGPA board with 9V for its power. I discovered one mechanical issue - the Ethernet connector on the Arty A7 board is higher than the input-output pin sockets. It causes my PCB to be tilted rather than inserting flat above the FPGA board. The solution was to remove the Ethernet connector from the FPGA board. 

The cable from this board to the Diablo is a 50 pin IDC-50 male to male ribbon cable, the type used for internal SCSI drives in earlier PCs. That cable runs to an adapter PCB I built that routes the signals from the IDC-50 connector to an IDC-40 connector (the type used for internal hard disk connections in earlier PCs) which is what was on the end of the Diablo produced signal cable. 

The Diablo drive has a ribbon cable that ends in a male IDC-40 connector, which plugs into that adapter PCB that I whipped up. It is a small simple board that allowed the two sockets to be connected in the pattern necessary to route the signals, with a good ground plane assuring signal integrity. 

At this point, the hardware for my Archiver is all complete - I have the Diablo drive with its connector and terminators installed, the power supplies to power the Diablo drive, the archiver assembly I just built and the 9V wall wart to power the Archiver. As you can see, the FPGA board powers up and gives reasonable status. Once I get the heads installed and aligned in the Diablo drive, and the drive tested to be sure it works properly. I can start the archiving process. 

Better chat with Copilot led me to an important issue with the 1130 MRAM board - and it appears to be the root cause of my issues!

USING COPILOT TO REPEAT CONVERSATION WITH GOOGLE AI

I repeated my discussion from earlier, describing the observed signals and the sporadic failure of the SLT card AC trigger to recognize my sense pulse. Copilot quickly led me over to the drive of my pulse, which I described including the transistor type and expected sink current of 35-40ma. 

It then asked me details about how I was driving the transistor and pointed out that the 2K base resistor I was using would only provide about 1.35ma to the transistor which would NOT put it fully into saturation. That would mean that even with the minimum beta of 25 from the spec sheet, the transistor may not actually sink the 34ma I was expecting. Too little sink current would fail to pull the SLT input down low enough. 

That does match the signal trace I saw - I initially assumed the low level a bit below 1V was due to impedance in the path and circuit details inside the SLT card, but it very well could be a marginal logic level to trigger SLT. Copilot suggested switching to a 470 ohm resistor.

It then had a cogent discussion of how I was driving the base resistor - a 74LVC08A chip with 3.3V supply voltage. It confirmed that the chip has plenty of drive to deliver 5.7 to 7 ma to the base of the transistor. The chip is designed for up to 24ma per output. At the minimum beta, the transistor could sink up to 142ma of current but the SLT circuit will not deliver more than 1 ma or so. 

I even asked for an analysis of the current into the input pin of the SLT register card with the "AC trigger" - falling edge sensitive input. It gave a very nicely reasoned analysis, calculations and background. It also realized that the input was triggered by a falling edge, thus the capacitor is charged through the +3V rail on the SLT card. Gemini claimed it was charged by the -3V rail. 

Somehow when I looked at the spec sheet for the BVS52LT1G transistor I am using, I thought that my base drive current was sufficient. It doesn't directly give any number for what base current puts the transistor into saturation, which is the necessary condition for the transistor to fully drive the output. 

As you can see in the top line of the chart above, I should have a large signal (DC) gain or beta of 25 with 1ma draw. The saturation voltage for the base to emitter junction is 0.7 to 0.85 V and I was providing 3.3V through the 2K resistor. Naively I assumed the transistor was saturated and able to deliver the 25X gain from a base current of 1.23ma worst case - sinking over 30ma from the connection to the SLT card. 

DOING A TEST CHANGING THE BASE RESISTOR FOR BIT 2

Since the sporadic failure I keep seeing is on B register bit 2, I located that resistor on my PCB and swapped it out. I looked all over the shop for a 470 ohm 0805 size resistor - a very very common value. However, the nearest I could find was a 499 ohm resistor which is what I installed on the board in the bit 2 position.  I then fired up the machine and looped reading memory to see whether the errors disappeared. 

The machine ran for 22 minutes without an error on bit 2. It eventually failed when bit 0 was dropped, understandable since I hadn't changed any of the other 17 base resistors. I ran for a while with no probes attached at all - bit 2 was 'healed'. 

The pulses drive down further toward ground and are sharper to boot. I have a bit of ringing at the low point but the SLT logic is insensitive to such fast signals and was already triggered by the falling edge thus unaffected. 

The falling edge is FAST. The scope is set for 100 ns per division, showing the falling edge as essentially vertical, in the range of hundreds of picoseconds. It appears to fall to about 0.15V, far below the specification for a valid SLT logic low level. 

THE ROOT CAUSE APPEARS TO BE IDENTIFIED AND THE FIX IS EASY

Based on this test, it seems that I was driving a marginal signal into the SLT card due to inadequate base current on the fast transistor I have in the board. It was close but failed sporadically after a few millions of successful operations. Stepping up the base current 4X with the resistor swap gave me a very solid and reliable operation for bit 2. With the machine performing almost 278,000 reads per second, it completed more than 380 million successful reads before a different bit failed. 

I will replace all eighteen of the base resistors on my board. Once that is done, I will run the core memory tests and other CPU diagnostics for a couple of hours just to convince myself the memory replacement is solid. 

I DO AGREE WITH ONE OF MY READERS - COPILOT BETTER THAN GOOGLE GEMINI AI

This is the second time that I did a comparison of the conversations from Gemini (through the Chrome browser) and Copilot. At least for vintage technology subjects, It didn't take that much prompting to move the conversation to productive areas, unlike Gemini which just iterated apologizing and straying in new ways. 

I have a loose lower head cable clamp in the Diablo 31 drive that must be reattached before heads can be installed

BASED ON THE EXPLODED PARTS LIST DIAGRAM, THE HEAD CLAMPS ARE TOO LOOSE

three clamps at upper left

Two of the clamps have a body with a tang that fits into a hole in the metal plate that is central in this diagram excerpt. If the bolts are loosened too far, the tang comes out of the hole and the clamp can spin around thus blocking the head from sliding into place. A third clamp must be oriented with its long axis vertically so that the sides grab on the two heads and lock them in place. When loosened, gravity causes it to turn 90 degrees so the long axis is parallel to the ground. 

The lower head clamp is not only too loose to have its tang in the hole, the bolt has disconnected entirely! You can't see the gap in the photo - very limited access for pictures or for working - but when I put an allen wrench on the bolt I can pull it away from the clamp entirely. 

I will have to do some microsurgery, getting a tool in to hold the clamp while I get the bolt inserted and the threads turning. I then have to tighten it up while maintaining its orientation until the tang enters the hold in the plate. It should only be loose one-half turn from a tight position. 

The upper head clamp is still threaded on the bolt, but its tang is out of the plate. This will be a somewhat easier surgery than the lower head clamp because all I need to do is hold orientation while I tighten it. Once it is in place, one-half turn loose should be enough to let the heads be installed.

When the upper and lower head clamps have their tangs in place and are appropriately loosened, I will try to install the heads while jockeying the third clamp vertical, as you see it in the picture above. I will then tighten it first, then loosen one-half turn. 

When the heads are installed, I can figure out what to use as the adjuster to align the heads. Diablo provides a tool (but I don't have one) that is threaded, to insert through the plate, with a conical head that will push against the side of a diagonal notch in the heads to make them move forward as the tool is screwed inward. 

Prepared the power supplies and cable for the Diablo model 31 drive I am using with the Archiver - powers on

CONNECTED WIRING TO THE WINCHESTER MRA9 SOCKET CONTACTS

I bought three regulated power supplies to support the Diablo drive. Two of them deliver 15V at 7A for use with the drive motor and the rotary arm positioner, the third is a dual voltage +15 and -15V supply at 2.5A each which powers the circuit boards of the drive. The two high current supplies were hooked up so that one delivered +15V and the other delivered -15V. 

These have a common ground wire which will become contact C of the MRAC-14 socket. The high current +15V is wired to contact K. The high current -15V is wired to contact R. The low current +15V for the circuit boards goes to contact H and the low current -15V is wired to contact P. 

Diablo actually uses a single supply for +15V and a single supply for -15V, but routes two separate wires from each. The heavy current on one of the wires drops the voltage on that wire a bit but the other wire stays at the regulated voltage to more reliably power the circuit boards. 

I chose entirely separate power supplies to ensure the cleanest logic power to the Diablo. The power supplies were not expensive and could have other uses once the archiving is complete. I twisted all the wiring together as recommended by Diablo. 

The three power supplies were connected to the AC mains in parallel, so that all three come on or go off as the plug is inserted into the wall socket. If this will become a more permanent drive - perhaps as a second drive for my IBM 1130 - then I will mount the power supplies in something more professional looking (and safer than exposed terminals). 

Test fit of the contacts in the body

+15 rails are good

-15V rails are good

Test fit of power connector

DISCOVERED A GENDER ISSUE WITH THE MRAC 14 CONNECTOR

The part I bought appears to match the part that was installed on the Diablo - other than the Diablo side has the male contacts and mine has female contacts. This locks the tightening screw and body in place. I have to loosen the nuts on the side to let the screw and receptacle rotate to thread onto the Diablo side screw and receptacle, then tighten the nuts when it is fully pulled tight. Since I haven't glued the contacts in the body yet, I only tightened it enough to verify it fits and delivers power properly. 

WILL GLUE THE CONTACTS INTO THE MRAC-14 SOCKET BODY

I plan to JB Weld original epoxy to glue the connectors into the socket body, hoping it would provide enough strength to at least connect the cable one time. I did NOT sand the contacts because the spec sheet mentions they have beryllium in them and I will not risk inhaling any. I did clean the contact and the body with isopropyl alcohol first, then applied the epoxy. It required 24 hours to cure before I could attempt to move it or insert it into the drive. 

CABLE ONNECTED TO THE DRIVE AND DID A POWER ON TEST

The key was to see if the drive would power up and be happy. A bonus if I could get the motor to start spinning. I turned on the power supplies and saw the Power lamp illuminate as well as the Unlock lamp. The drive allowed me to open the cover to insert a disk cartridge. I put in a cartridge (but as i don't have the heads installed I won't spin it up to the point where the drive tries to load the heads) and got the motor spinning the platter for a few seconds. The servo was also locked in place unless I pushed the servo unlock button inside the drive.

The drive appears to be pretty healthy. This was not a checkout, thus we could have failed ICs or other issues yet to resolve, but power is good and the machine didn't do anything strange. 

Fighting to install the heads in the Diablo 31 drive

CHOSE THE REPAIRED HEADS BUT HAD TO CLEAN THEM 

The heads that my friend carefully polished to remove the head crash scratching actually looked good enough that I decided they would be the first set I try to fly. However, when examining them under the microscope I saw that the polishing powder was still on parts of the head. The bits of the powder are large enough that they would certainly cause a head crash as they flaked off during the vibration and airflow of disk operation. 

I could see it in the two round airholes that establish the cushion pressure as the head flies over the surface. I could see a lot more caked up behind the head, around the coil and on the attachment points. As I touched it with tools, it moved and came off in sludgy sections. 

I carefully removed as much as I could and bathed the heads in isopropyl alcohol in a container to try to wash away as much as I could. They seem pretty clean after all that work. 

HEADS STUBBORNLY REFUSING TO SLIDE FULLY INTO THE ARM

The heads should slide into the arm where clamps would be tightened to hold them down. They were not going in sufficiently. Unfortunately, the clamps are hidden inside the rotary motor and arm assembly, barely visible from the side using a light. I thus can't really see what is blocking the head from sliding into position. 

SEEING THE PROBLEM BY STUDYING THE PARTS CATALOG DRAWINGS

The excerpt from the parts drawing shows the three clamps and the slots on the right where the heads slide in (from the right moving inward to the left). It appears from the diagram that two of the clamps have a tang that should sit in a hole in the metal block. I have loosened them too much and they are now turning freely and not held in the proper alignment.

Once I get the two clamps tightened with the tang in the hole, I can loosen they slightly and they should remain in alignment. The third clamp should be oriented as shown but it freely spins round the bolt when there are no heads installed. I will then need to turn that to the proper vertical orientation before I attempt to slide the heads into the arm and get them to settle down between the clamps. 

I will attempt this on my next visit to the workshop. Once the heads are properly inserted and connected up, the drive should be ready for head alignment. The Diablo drive has a pushbutton inside that blocks the servo from moving the heads. I will hold that down and move the heads to a far cylinder manually then wait until the heads load. That way, any damage to the special CE cartridge used for alignment will be past the point I need to use. If the heads fly safely, I can move it back to cylinder 100 where the alignment data is written. 

Getting insight into what is happening during failure of 1130 MRAM doing reads - no more quantum effects

CURRENT SITUATION

When storing words of all 1 values (0xFFFF) into all of memory and then setting the machine to do continual storage reads looping through memory addresses, I will get sporadic parity errors where bit 2 fails to be set. Since the 1130 MRAM board has calculated parity based on that bits stored value of 1, the parity check fails and the machine stops.

I had been unable to see what was occurring because any time I put an oscilloscope probe or the logic analyzer on the incoming pin for setting the bit, the machine never failed. I finally dumped about over $500 into acquiring an active FET probe (used) which has less loading effect. 

MORE EXPERIMENTS WITH ACTIVE FET PROBE

I set the active probe to 10X attenuation and AC coupling, with a direct ground lead to the ground pin on the same SLT card as the incoming sense bit pulse. That worked as I wished - the rate of sporadic dropped bits didn't change thus my loading was not affecting the measured circuit. 

What I saw when a parity check was triggered was that the pulse which attempted to set the B register bit 2 was slightly different shaped than the others. It is there, but somehow it isn't flipping on the bit thus we get the parity check. 

The yellow trace is from the active FET probe recording a negative going pulse from my 1130 MRAM board which is intended to cause the SLT card to flip on the bit. Thousands prior to this successfully turned on the bit but this one didn't. I looked closer at the failed bit attempt as well as the successful one that came just before.

Pulse which fails to set the B register bit 2

Example of a pulse successfully setting the bit

The failed set involved a pulse that dropped about 2V whereas the successful ones show a pattern that comes from the capacitor discharging inside the SLT card and getting down to about .25V. The edge detector in SLT is a capacitor that is charged up through a resistor by an enable signal; then when the falling edge pulse arrives, it discharges the capacitor, resulting in the flipflop being turned on. 

The transistor on my 1130 MRAM board pulls the signal line down to ground. A pullup resistor on the SLT backplane causes the line to sit about +3V until the transistor fires to drop the line. We see the pin barely gets below 1V in the failing case but down to 0.25V when it succeeds. 

The transistor has a minimum beta of 25 and with a 1.6ma drive current it should be sinking over 40ma which should be sufficient for the activation of the IBM edge detector. The successful pulses reach a threshold of about 0.9V and then we see the capacitor delivering energy as it is discharged down to 0.25V. The failed pulse reaches about the same initial level but we don't see the capacitor delivering energy. 

I had a long, long chat with AI about what might be happening. Lots of speculation that didn't make sense, but I did 'listen' carefully and think about the phenomena being described. A good refresher on EE topics. Discussions about varying signals from other processing in the 1130 didn't make sense as this is a pure memory display loop.

As the AI pointed out, the SLT backplanes are designed for slow signals and higher frequencies such as from my board's fast pulse edge can ring across the backplane and cabling. The speculation was that ringing reflections could randomly cancel out my pulse edge if it arrives at just the wrong time However, the active FET probe is not showing any 'long term' ringing. 

When I started the discussion with the sporadic nature and failure rate of about 1 in 200,000 memory accesses, the AI asked me to look for a beat frequency of 1.388Hz but that is assuming it is always deterministically 1 in 200,000. Other suggestions assumed that the IBM flipflops are clocked, but they are really asynchronous circuits. Still, it did push me to think along many lines. Slight timing drift between my board generating the pulses and the clocks in the 1130 could line up bounce and dips on rails. 

I do remember seeing ground bounce in earlier versions of the board and that might still be an issue I need to address. I will add a braided ground strap from my board to the 1130 ground bus and see what effect that has. Another idea was to temporarily add a .1uF capacitor from ground to the -3V rail input of the SLT card and another .1uF capacitor between ground and the +6V rail input on the SLT card. This will absorb some high frequency bounce that might be caused by my fast pulse edges. 

The shape of the failed pulse looks to me as if the capacitor is not discharging. It has to be charged by the SLT circuit prior to my negative going pulse arriving. AI speculated that the resistors on the SLT cards have drifted high and are barely recharging the capacitor in time thus very random timing differences between memory cycles might eventually arrive just too soon to trigger. Bounce of the rail that charges the capacitor might also cause it to fail to charge sufficiently, it mused. 

This problem has bounced around the machine between the SLT cards. The B register is implemented across eight double width SLT cards, two bits per card. Previously the most common failure was bit 14, but recently it is bit 2. Thus it is unlikely that several cards have degraded to have exactly the same vulnerability. The only commonality I remember is that the errors always occurred on even numbered bits - those on row 3 of the SLT backplane. Thus cracked traces for power or ground could be a factor and only impact the cards that used that row. This may be coincidence however and the same issues might be possible on row 2 connections - odd bits. 

Bottom line, I can now see the failures where before they were masked by the loading of the probes. This should allow me to drill down to figure out what is causing my issues. I am making progress but don't yet have the smoking gun that pins down the exact cause. 

PLAN FOR NEXT OBSERVATIONS

When I next get to the workshop, I will add oscilloscope probes to the +6 and -3V pins of the SLT card and watch in AC mode for any activity on the rails that coincides with the failures.