Returning to testing for the Virtual 2315 Cartridge Facility

1130 SYSTEM NOW SOLID - POWER AND MEMORY ISSUES RESOLVED

When I was last testing the cartridge facility, I began to encounter parity stops due to continued degradation of traces inside the core memory stack of the system. I had previously added wiring to bypass broken traces on several sense lines, but another cropped up. I realized that the memory was going to continue its slide into oblivion due to whatever corrosion was occurring inside the memory stack on a surface to which I had no practical way to gain access. 

I designed a replacement for the core memory, based on a magnetic RAM chip (MRAM) which would preserve memory contents when power is off just as the original IBM core memory does. During testing of the core memory substitute board, I encountered a worsening of a second problem that had been plaguing the machine - a circuit breaker tripping on the +6V power regulator.

This would happen mostly when I had powered down the machine for a short time and then turned it back on. Very occasionally it would turn off while the machine was working. The rate of the breaker trip began to increase, so I wanted to resolve that before I could finish the memory board testing. 

I changed components on the Standard Modular System (SMS) card that performs the regulation inside the regulator module, until the flaky behavior disappeared. With solid power, I wrapped up the memory board testing. The machine was now ready to support my testing of the disk project.

THE VIRTUAL 2315 CARTRIDGE FACILITY BEING TESTED

The Virtual 2315 Cartridge Facility enhances the 1130 system, allowing the user to use the disk drive more flexibly and reliably while preserving the experience of the original disk drive operation. The disk drive in the IBM 1130 uses cartridges that contain a 14" disk platter inside a plastic housing. These slide into the disk drive. The drive spins the platter inside the cartridge and uses a pair of read/write heads, one per side of the platter, to access the 512K words of storage available on a cartridge. 

The disk cartridge is organized into 203 concentric circles on each side of the platter, reached by the drive moving the read/write heads on their arm inward to the hub center or outward to the edge of the platter surface. The movement of the arm to the 203 positions is called a seek. 

When the drive operates with a physical cartridge (IBM 2315), the motor spins it up to a speed of 1500 RPM for use. The arm moves in and out making a grunting sound as it moves. The 1130 system vibrates slightly due to the mass of the spinning platter and shakes a bit more due to each arm movement. The sound of the motor is also audible.

The Virtual 2315 Cartridge Facility modifies the disk drive so that the read/write heads do not actually move down onto the surface of the disk platter. They arm still moves, the platter still rotates, and all the sounds and sensations are the same. However, the data that would have been read from the surface is instead coming from a small plug-in virtual cartridge. Any changed data that is written out by the 1130 is captured and put onto the small plug-in virtual cartridge. 

This eliminates the risk that the heads will crash on the surface of the platter, damaging both themselves and the cartridge. It also allows the user to have as many of the small cartridges as they wish, rather than being restricted to 2315 cartridges which are no longer sold. Finally, the files on the small virtual cartridge can be used with an IBM 1130 simulator running on a PC or Mac. This interchangeability gives access to a much wider range of disk content that is likely to exist when constrained to using only actual 2315 cartridges. 

The virtual cartridge is implemented on a micro SD card that is installed inside a small plastic housing that looks like a small version of a 2315 cartridge. The SD card can be pulled out of the housing and inserted in a reader for use with the simulator, then re-installed to use it with the 1130 system. 

The Virtual 2315 Cartridge Facility involves a small control box that sits under the top lid of the IBM 1130, into which the virtual cartridge is plugged. It is connected to an interface board inside the 1130 that sits between the disk drive and the 1130 logic. 

A small motorcycle battery and related hardware ensures that the Virtual 2315 Cartridge Facility remains operating when power is abruptly removed from the 1130, long enough to ensure the virtual cartridge has preserved all new data written just prior to the power-down. 

BACK TO TESTING THE SEEK FUNCTIONALITY

The disk diagnostic programs from IBM have run against the Virtual 2315 Cartridge Facility, with all the reading and writing of data passing completely successfully. The seek of the drive is the one area that was not fully correct - sometimes the virtual facility would be out of sync with the disk drive arm position. 

The facility is simply observing the movement commands sent to the disk drive and should therefore always match the location of the read/write heads. In cases involving longer movements, it was sometimes off by a few positions, leading to the diagnostic issuing error messages.

The 1130 commands the disk drive to move 1 or 2 cylinders (positions), either forward toward higher cylinder numbers (the center of the platter) or backwards towards the outermost position on the platter which is called the home cylinder (0). Long movements consist of sequences of 2 cylinder movement commands, only followed with a 1 cylinder movement command if the total movement is an odd number of positions. 

It was possible that noise on the connection to the V2315CF was causing it to miss a move or spuriously record a seek that did not occur. Another vulnerability was that the disk drive documentation claimed that the seek was started with a short pulse on -Access Go but the logic of the disk controller inside the 1130 actually asserts -Access Go for a long time, dropping it once the seeking is over. 

I worked on the state machine logic to make it as bulletproof as I could. The main signal that advanced the state machine when I shadowed the actual seek operation between the 1130 and the disk drive was +Access Ready which I debounced. I counted time periods when the signal was high or low, updating a running counter which I allowed to move between 0 and 10. 

A sequence of 9 positive states followed by 9 negative states would never advance the counter to 10. Similarly a sequence of up to 9 negative states followed by a long run of positive states would never drop the counter to 0. Thus I had to have a steady signal to consider +Access Ready to be true or false. 

When we saw the -Access Go arrive, the state machine would next check that +Access Ready was true. If not, this is considered a spurious condition and we go back to idle. If it was true, we then sit and wait for the +Access Ready signal to become false, which occurs about 5 ms into a seek. A safety timer will count off 15 ms and if we are still sitting here waiting, we consider this a spurious seek and go back to idle. If +Access Ready did go false, we update the cylinder location and then wait for +Access Ready to return to true which is the end of our seek. 

The control signal we generate when a seek is requested happens for one cycle when we see a falling edge on -Access Go and the drive is online and ready. This is what moves the state machine out of idle. The previous version was generated continuously as long as -Access Go was asserted low, which is not correct but was driven by the error in the disk drive documentation that shows -Access Go as a single downward pulse. 

SIMULATION TO TEST THE SEEK LOGIC PRIOR TO TESTING ON THE 1130

I ran a simulation of the FPGA logic in a testbench to try out the functionality, including as many cases of noise and intermittent signals as I could think of. Once I was satisfied that the logic worked as I intended, it was time to fire up the 1130 system and test with the real hardware. 

Debugging work on the multiply-divide issue with the 1130 MRAM board - memory fixed and working flawlessly!!!!!

FALSE BIT 13 WHEN READING CERTAIN ADDRESSES WITH UNKNOWN CONDITIONS

The CPU diagnostic runs a test of the multiply and divide hardware which consistently fails after having successfully tested many sets of values. The memory location that holds one of the values - 0x0CFB - will consistently create a parity check when I attempt to access it using the Display mode of the 1130. Bit 13 will be turned on in the Storage Buffer Register (SBR) after the location is read, but the P2 parity bit is set as if that bit is not on, thus generating the parity check. 

It is strange that I can use the Load mode of the 1130 to set the value in the word, dropping bit 13 so that it matches what I believe was intended, but the next Display will again see bit 13 on and suffer a parity check. I should be able to store a value in location 0x0CFB and retrieve it without the phantom bit 13 turning on.

Now, this does NOT happen when I first bring up the 1130 system. It does not happen if I use the Storage Load and Storage Display modes of the 1130. It only happens once the diagnostic has run and we reach the error stop for the multiply-divide test. Something has happened that puts the 1130 or the memory board in a condition that then causes this strange behavior. 

HAPPENED TO ADD A BRAIDED GROUND WIRE IN PARALLEL WITH 18GA STRANDED

I had dual 18 gauge ground wires to the PCB from the IBM 1130, but decided to use a braided ground wire in place of one of the regular stranded wires. The thought was that the braided wire has many more strands, smaller strands, which gives a lower impedance path for high frequency currents to ground that ordinary stranded wire. 

I then ran the CPU Diagnostic to successful completion about ten times, then loaded the core memory diagnostic program and ran it multiple times to successful completion. The problem was indeed ground impedance, as one of my readers had been suspecting. In the DC domain I had extremely low impedance with the multiple heavy ground wires but the issue was the fast switching demands of the chips.

MEMORY SUBSTITUTE BOARD NOW WORKING PERFECTLY

The project is finally working to my satisfaction. I will update the bill of materials and build instructions to cover the very necessary braided ground wire. 

MINOR IMPROVEMENTS TO THE PCB DESIGN

Last night I broadened the ground traces for the MRAM chip on the board and added a second decoupling capacitor under the chip, a 10uF tantalum next to the .1uF ceramic. I also opened the solder mask for the four ground pads that would be used to solder a magnetic shield over the chip on the PCB. Unless I see evidence that the fault is one that these are needed to correct, I won't be building the new PCB but I am sharing the improved version on Github. 

Unexpected results when digging into the Multiply-Divide error in the CPU diagnostic program

WORK ON MULTIPLY-DIVIDE DETERMINISTIC ERROR

IBM's CPU diagnostic program exercises all the instructions of the machine, trying all the variants and testing all the edge cases to validate the correct operation. At the end, the program runs a multiply-divide test which is where we are getting an error stop.

The program starts with the largest negative integer, multiplying that number then dividing it, with four chosen other integers that would stress edge cases. The outcome should be zero for each of those multiply-divide pairs, otherwise we get an error stop. Once the four chosen integers are used, out original integer is bumped up by one and we do it all again. After the original integer is tested with all values from the most negative to the most positive, the test ends. 

The 1130 uses 16 bit words with twos-complement format. The most negative number is -32768, or 0b1000000000000000 in binary. The most positive integer is +23767 or 0b0111111111111111 in binary. The four chosen integers that get multiplied and divided by our integer are 0x8000, 0x4000, 0xC000 and 0x2001 which are -32768, +16384, -16384 and +8193 respectively. 

BACKGROUND ON MULTIPLY AND DIVIDE INSTRUCTIONS

The chosen integer is loaded into the ACC before the multiply instruction is executed. The machine shifts the value from the ACC into the EXT before it accomplishes the multiplication against the chosen integer multiplicand  which is loaded from memory in each cycle as part of the multiply instruction. 

A divide instruction works with a 32 bit wide value (a doubleword integer with a sign in the top bit of the first word and what normally would be a sign bit of the second word treated as just another data bit of the larger integer value). This doubleword is loaded into the ACC and EXT as a combined pair of registers. It then divides by the integer brought into the AFR as part of the Divide instruction (divisor). The result of the division is to have the result left in the ACC and the remainder in the EXT, both represented as 16 bit twos complement integers. 

The multiply instruction takes a variable number of execution cycles based on an algorithm. This algorithm performs cycles where it shifts the multiplier (value in ACC originally) to the right and conditionally does adds or subtracts of the multiplicand value, continuing until all sixteen bit positions of the multiplier have been shifted but ends the multiply when the value in the ACC becomes zero. These steps are essentially adding or subtracting n to the power 2 times the AFR (because of the shifting of the results in the combined ACC and EXT registers). 

For each cycle, it considers the two low order bits in the EXT and the previous type of arithmetic operation (add or subtract), to choose what it does in the cycle. This table shows the choices based on those three inputs:

Bit 14      Bit 15       Previous      Next Operation

   0          0            Add             

   0          1            Add               Add

   1          0            Add            

   1          1            Add               Sub

   0          0            Sub               Add

   0          1            Sub

   1          0            Sub               Sub

   1          1            Sub

The hardware always shifts the ACC and EXT to the right in an execution cycle as long as the EXT itself has not become all zero. Shifting to the right continues until the low bit of the EXT changes (if we had a 1 then we shift until the low bit becomes 0, else we shift until the low bit becomes a 1. The original sign bit when we started the multiplication is saved elsewhere in the hardware and we ignore the sign bit on each cycle because the shifting of ACC+EXT put a 0 in the vacated top bit position. 

When we begin the first execution cycle of a multiply the previous operation is considered to have been an Add, the multiplier was put in the EXT register and we shift until we find a 1 bit in the low position of the EXT. We count how many positions are shifted until we reach 16, then the multiply ends. 

Lets take a simply case where we are multiplying an integer by the chosen integer value 0x4000 to see how this works. The first cycle of the multiply will start with the ACC and EXT as 0x0000 0x4000 then it shifts until the single one bit in EXT reaches the rightmost bit of EXT. We add the integer from the multiplicand into the ACC then shift the ACC + EXT to the right looking for the next bit to be 0. However we reach a shift count of 16 so the multiply stops. The multiplicand value is now in the ACC, meaning that the integer was multiplied by +16384. It looks like the original integer but shifted one place to the right. 

For the case of the chosen integer 0x2001, we start with the ACC + EXT having 0x0000 and 0x2001 in them. We have a 1 in the low bit position so our operation is to add the multiplicand into the ACC. The next cycle shifts until it finds a one bit in the low position of the EXT. We then add the multiplicand again, equivalent to multiplying the multiplicand by +8192 and adding it to the running total. That gives us 8193 times the multiplicand in the combined ACC + EXT registers and we shift until we have done all 16 positions. 

The other two chosen values just start us with negative numbers, either -32768 or -16384 instead of positive values. Our ACC and EXT begin with 0x0000 0x8000 or 0x0000 0xC000 and we remembered the negative sign this time. The rules for shifting and arithmetic operations will produce the correct result in ACC + EXT. 

The divide instruction takes a fixed number of execution cycles - 18 - unless the value of the result would exceed the largest integer values of -32768 to +32767 in which case the divide stops with an overflow error. It always shifts the ACC + EXT one position to the left in a cycle, but choses whether to add or subtract the divisor value based on whether the top bit of the ACC and of the EXT are the same or not. It checks for overflow, where the result would be larger than the biggest positive or negative integer, and stop if that error occurs. 

LOOKING AT THE ERROR

When the diagnostic stopped with wait code 0x316D I looked at the value of the integer and which of the chosen integers was multiplied and divided to do the test. It was the first phase, using 0xC000 as the chosen value, because index register 1 was at its initial value of 4. The stop was with 0xFFFB in the ACC and 0x0000 in the EXT register. 

Looking at the fact that both multiply and divide will re-fetch a memory location on each execution cycle for the multiplicand or dividend, if one of the memory fetches returns a different value when we could have the symptoms being reported here. 

I set the machine to display the value in 0x0CFB which is where the integer began as the largest negative number and is bumped by one after each multiply-divide pair. The machine gave a parity check while displaying 0xE1F4. I believe the error is with bit 13 being on incorrectly. I stored the value 0xE1F0 in the location and tried to display it, but again got a parity check with 0xE1F4 returned. 

STRANGE REPEATIBLE BEHAVOR DISPLAYING THAT ADDRESS

Strangely, I could repeatedly put the machine in Load mode, set that address and write the intended value 0xE1F0 yet when I put it in Display mode at address 0x0CFB the machine returns 0xE1F4 with a parity check each time. 

If I use the Storage Load mode to set all of memory to some pattern - 0x0000 or 0xffff or 0xE1F0 - then I put the machine in the Storage Display mode to continuously read and display all memory locations, it does NOT get a parity check. 

MUSINGS ABOUT THE RESULTS

My memory board returns the 16 bits of the word by setting the Storage Buffer Register (SBR) bit to 1 if the memory value is 1, otherwise it does nothing so that the SBR bit remains 0. The parity bits are generated on the fly by my board based on the 1 and 0 values it will set in the SBR, thus it should NEVER get a parity check. In the past, I got parity checks when a pulse from my board intended to set the SBR bit to a 1 but the pulse was too marginal to actually set the bit. 

The situation here appears to be the opposite. Bit 13 of the SBR is turning on but my board is generating parity as if bit 13 is a zero. The pulse is only generated if the MRAM chip on my board outputs a 1 for that bit position, yet the bit being output also generates the parity. I don't see a mechanism where I could produce a pulse when the memory value of the bit is 0. 

Further, this happens when the machine has been successfully returning the value of that location for many many cycles, enough to have advanced from 0x8000 to 0xE1F0 before failing. It reached -15,376 from -32,767 meaning it correctly did the multiply and the divide 17,391 times,  involving 20 to 34 fetches of the address for each time we do the multiply-divide. That means somewhere between 350,000 and 600,000 times it did not get a parity check or have a phantom bit 13 set.

It also means that some condition comes up that seems to always results in a phantom bit 13 showing up in the SBR but only when fetching from that address. Vary similar to the issue with the memory diagnostic where we get a parity check at the same address every time with a phantom 1 in bit 13. 

I noticed that the addresses have bits 8, 9, 10, 11, 14 and 15 set to 1. Why that is significant, I don't know. I am really struggling to find a failure mode that is so strong and repeatable for addresses like this and only when certain unknown conditions sensitize the system to this. That is because when I use Storage Load and Storage Display modes, we never see bit 13 emit a phantom 1, nor do we see parity errors. On the other hand, when I reach this point in the multiply-divide routine, any attempt to display the address generates the phantom bit 13 issue. 

This is going to take a bit of noodling and some good luck spotting whatever is causing the issue. I could solve it by locking the value of the data word and parity bits into a hardware buffer so that what comes out is always self-consistent, however that presupposes that the value I lock into the buffer is always the correct contents. Doing that would require changing the PCB and design, something I would hate to do without firm evidence that I know the true root cause and can definitively correct it. 

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. 

Started master file list from all 2315 cartridges and stored on Google workspace

ARCHIVED VIRTUAL DISKS FROM AN IBM 1130 SIMULATOR

I have been using the IBM 1130 simulator from Carlos Vincenzi and looked at the virtual disk drives from release 4.4.1.R9 as that is the version I have used the most. I grabbed 9 virtual disk drives from their and ran off the contents from the LET, FLET and SLET of each cartridge.

I entered them in the master spreadsheet I decided to use. This will let me quickly search for a file name and see all the cartridges that contain that file. It also provides an inventory of the cartridge as a whole. 

I will use the Unique field to assign some kind of globally unique identifier since I already have several virtual cartridges that had the same four hex digit ID assigned. For LET and FLET entries, it is the number of sectors the file consumes on disk. For the SLET entries, it shows the size in words of that phase. As well, the type field for the SLET will be the two character phase ID. 

Some files have multiple named entry points, thus the size and type fields are blank for the additional names. The names FADD, FSUB, FADDX and FSUBX are all contained in the one file whose initial entry is FADD. The file is in Disk System Format and takes up 8 sectors of the LET. 

In addition to the compact DSF format, files may be stored in Disk Core Image (DCI) format or in Disk Data Format (DDF). A DSF file must have all its linkages resolved and be combined with all other files it requires to produce the final core image that is what executes. Thus DSF is more compact, but DCI skips the time needed to link together all the files so it is faster to execute. DDF files are not executable. 

Files such as FADD are standard FORTRAN subroutines, loaded when the Fortran compiler was installed on this cartridge. Other files can be applications and utilities, either provided by IBM, from contributors or developed by the user. I will use the Purpose field to note what I discover about the files that are not standard parts of the Disk Monitor System and its compilers. 

The nine cartridges gave me 4, 095 entries in the spreadsheet. I envision the entire archive will be in the range of 100,000 to 200,000 entries. This is why I hosted it on Google. In addition, I can share it easily with other hobbyists and researchers. 

Work progressing on Diablo Archiver project

PYTHON APPLICATIONS DEVELOPED TO READ LISTINGS AND BUILD CSV FILE

I whipped up some Python code to open listing files - printer output of the IBM 1130 simulator running tasks to print the LET (Location Equivalency Table), FLET (Fixed Location Equivalency Table) and SLET (System Location Equivalency Table), extract all the file names along with some salient information, and create a comma separated values (CSV) file to add those to a spreadsheet in the format that I have initially defined. 

They ask for the Cartridge ID, the four hex characters that label the 2315 disk cartridge, a secondary name that I can maintain which is unique across all cartridge images, then read the printer file and spit out the CSV format file that can be used to import those values into a master spreadsheet recording the details of every file stored across all the archived cartridges. 

SOLDERED TOGETHER THE CONNECTOR ADAPTER BOARD

The Diablo came with a cable that has a Winchester MRAC-42 connector on one end and an IDC 40 pin connector on the other. The ribbon cable has a metal ground plane across its breadth, which supports signal integrity for the 37 signals thar are carried across the cable. 

I developed my Archiver PCB with an IDC 50 pin connector on a ribbon cable, supporting 25 signals with a ground wire between each signal wire. I whipped up a design for a board to connect those 25 signals to the corresponding pins of the IDC-40 connector on the Diablo cable. The board mounted one each IDC-40 and IDC-50 socket. 

WORKING ON THE CHALLENGE OF THE DIABLO POWER CONNECTOR

The rear of the Diablo drive has a male Winchester MRAC-14 connector, with five active pins that carry ground, +15V, -15V, another +15V and a second -15V power rail to operate the drive. The power supplies need a MRAC-14 socket. I don't have a cable for that.

MRAC connectors are fairly rare and have strong demand which forces high prices. The used sockets on eBay are all sold as plastic bodies without any metal contacts inside. The female contacts came in several types depending on the wire that would connect to it, whether by crimp or soldering. For my purposes I need the larger solder types.

The female contacts are sold in groups for several hundred dollars. Not a price I want to pay. At worst case I would have removed the male MRAC-14 connector and switched to a more readily available connector type for power. However, I did think I had found a solution that would come in  around $60 total. I found a female 9 pin connector that had the female contacts installed in the body, and I found a female 14 pin socket. Move the contacts, of which I only need 5, and viola.

However, when I received the 9 pin socket yesterday I realized that I had made a mistake. The Winchester connectors come in two flavors - MRA and MRAC - with the difference being that the MRA have the contacts permanently molded into the body, while the MRAC have contacts that can be removed and inserted. The contacts are not compatible between them, as the contacts for MRAC have a metal tab that locks them into the body.

What I had purchased was a MRA 9 pin socket with permanently molded contacts and a MRAC 14 pin body. I decided that I will find a way to re-use the contacts and put them into the 14 pin body. I spent a half hour carefully releasing the female contacts, although it required the destruction of the body. 

I will find a way to anchor the contacts into the 14 pin body. It might require epoxy or some other adhesive, but after I solder wires onto the contacts I will affix them to the body so that I have a workable power connector to hook to the Diablo.

SELECTING HEADS TO MOUNT IN THE DIABLO DRIVE

I pulled the heads from the Diablo drive (the two on the left in this picture) and collected a few heads I was assembling on compatible holders. I will decide which are the best and insert those into the Diablo drive.

Sent Head Adapter Tool off to fab; supports aligning heads in standard density Diablo 31 drive

GOOGLE AI CONTINUED TO SPEW INCORRECT INFORMATION

I asked Google AI to tell me the connector size for the head cable connection to the J10 PCB in the Diablo Disk drive. It responded authoritatively and confidently but embarrassingly incompetently. It was describing pin connections that made no sense. 

I called the software on one of the more egregious errors, claiming that each head had two erase coil windings. It apologized, said I was correct and updated its advice. Still woefully wrong. 

It asserted that the connection was two 6 pin connectors, one above the other. It still claimed that two leads came out from the erase coil and three leads for the read/write coil (two ends and a center tap Select line). Here is a picture of the cable from each head - only four pins just as is shown on the Diablo schematics. The erase coil has one end tied to the same Select line that is the center tap of the read/write coil, but the AI didn't grasp that. 

It said the connectors were standard 2.54mm pin headers. It gave pin numbers that don't match the Diablo schematics. The AI pinout had no ground connection and no mention of shields. 

I went to the workshop and examined the connector and the J10 PCB. I did some signal tracing as well. The connector is a standard 14 pin DIP socket. Not 6 on the top and 6 on the bottom. Further, it has four pins that grounding the shields of four tiny coaxial cables that carry the four head lines. 

I have tried using Google AI for some coding assists. It did a decent job giving me sample code to do new user interface tasks and using unfamiliar Python libraries. It seems to work adequately in that domain. However, for researching vintage computing hardware it emits AI slop. 

CORRECT PINOUT USED FOR MY DESIGN

I now know the pin assignments, which do match the pin numbers from the Diablo schematic of board J10. If you were to number a DIP socket in reverse, that is start with 1 at the top left, go to the right across the top row to 7, continue below with 8 and go back to the left bottom as pin 14, then the numbers match perfectly.

Pins 1, 2, 13 and 14 are connected to the board ground. Each pin on the connector has the shield of one of the four signal cables, two per head. Since there is no connection on the other end, there is no continuity to observe here but the PCB shows the pins tied to the ground plane. 

Pins 13 and 12 do nothing, they are unassigned. That leaves four pins each for the upper and lower heads. Each head has a connection to the common Select that ties the center tap of the read/write coil with one side of the erase coil. Each head has a line from the other side of the erase coil. There are two more lines, tied to the two ends of the center tapped read/write coil. 

4 - one side of the read/write coil that feeds Head Bus A

5 - the other side of the read/write coil, feeding Head Bus B

6 - Select, the common point

7 - the other end of the erase coil

8 - the other end of the erase coil on the second head

9 - Select for the second head

10 - one side of the read/write coil on second head, feeding Head Bus B

11 - other side of read/write coil, feeding Head Bus A

DESIGNED A SMALL PCB WITH A DIP 14 SOCKET AND DIP 14 MALE PINS

I whipped up a PCB that has pins to plug into the DIP-14 socket on the J10 PCB. It is marked with an up arrow much like the cable connector. Above that, it mounts a DIP-14 socket into which the head cable connector will plug. 

The erase coil of one head is connected to Head Bus A. The erase coil of the second head is connected to Head Bus B. The two Select lines for the heads are connected to their normal places. The other ends of the read/write coils are unconnected since this adapter uses the erase coil for alignment signal capture. 

SENT TO JLCPCB FAB FOR QUICK TURNAROUND

I expect the PCB to be built in two days and shipped back to me in about a week total time. It was fastest just to ship this off to JLCPCB who I had been using, in spite of the kind sponsorship from PCBWay.com since it adds time to arrange for them to pay for each sponsored PCB. 

Creating the Head Adapter Tool for aligning the Diablo drive

PROCESS IS DIFFERENT FOR STANDARD DENSITY (1130) CARTRIDGES

The method of aligning the heads takes advantage of the wider spacing of the poles of the erase coil in the head compared to the read/write coil. To do this, a special tool is connected between the J10 printed circuit board and the connector from the heads. It rewires the connections to switch the read preamplifiers from the ends of the read/write coil to the erase coil. 

This provides a very sharp null position over the track centerline so that only signals that are offset to the sides will be detected. The CE cartridge that is used to align packs had track 100 recorded with a special drive that offset the center of the spindle. 

This caused the written track to shift during a rotation, putting the center of the recorded track close to one edge and then the other of the .01" track width when it is read back on a drive with a normal spindle position. Since the center of the erase coil does not see a signal, the only signal picked up is from the portions of the special track that wander off center to be under one or the other pole of the erase coil. Correct alignment gives equal signal strength on both poles, otherwise we see more signal on one or the other so that the scope trace is unsymmetric. 

image for properly aligned head

High density machines, including the Diablo 31 we used to archive the Xerox PARC cartridges from the Alto computers, cannot use this method because the track width is too narrow. It must use the read/write coil for alignment. 

HEAD ADAPTER TOOL REWIRES THE CONNECTIONS TO USE THE ERASE COIL

No schematic or board view exists of this tool, but its purpose is described enough to work out a substitute. I will create a mini PCB that sits between the socket and the plug of the connector from the heads. It will also provide scoping connections.

Google AI gave me a start on the wiring, but it has several problems. As usual, it creates plausible text but can be way off on important details. The pin numbering from the AI output does NOT match any schematics of the Diablo drive. 

It refers at one point to the heads as having two erase and one read/write coil, which is NOT correct. It claims there are two erase coils (yes, but one per head) and a common return line (not true, separate wires from the heads only joined on the J10 PCB to form a common erase return path. 

Further, it doesn't seem to work with the method of selecting the head to align as described in the alignment procedure. The select line (a common line to all three coils in a head) has to be grounded. Grounding pin 5 of the J10 input pads selects the upper head; without that, the lower head is being selected. The wiring of the erase connections must conform with this. 

The AI discussion has both erase head ends connected across the differential amplifier, which is one for the top head and one for the bottom head. This could work if we have a floating select line hooked to one side of the erase coil in the head we aren't watching and an activated select line hooked to the other side of the coil on the head we care about. The two select lines go where the two erase return lines are connected on the original schematic. Here is what I think the wiring should be - from the head wires on the connector through to the socket on J10 PCB.

The normal wiring from the heads into J10 connects the two ends of both head's read/write coils together and they both feed the differential preamplifier, also called head bus A and head bus B. The erase coils are hooked on one end to the select line, as is the center tap of the read/write coils. The other end of the erase coil on each head comes onto J10 and are tied together there into a common erase return. 

All I need to do is disconnect the read/write coil ends and reroute the erase coil lines. Select lines remain unaffected. The erase coil line from one head goes to head bus A and the erase coil line of the other head is attached to head bus B. Very simple rerouting of the signals. 

HEAD SELECTION ON THE DIABLO DRIVE

The wiring of the heads uses a Select wire that is connected to the center tap of the read/write coils plus to one side of the erase coil. The two ends of the read/write coil are hooked to head bus A and B, while the other end of the erase coil is connected to a common return line that is grounded when erase current should flow through the erase coil. 

The select line is set to +14V when the write gate is turned on, thus the erase gate also drives the erase coil in this case. However, when the head is not selected, the select line is floating thus we don't have any erase or write current flow. For reading, the select line is set to 0.1V on the desired head and floats on the unselected head. 

As a result, even though the erase coils of both heads are connected to the differential preamplifier channels, only one select line is connected thus a signal voltage is only developed on one of the head bus channels at any time. 

WILL HAVE TO DETERMINE PIN NUMBERING OF ACTUAL CONNECTOR ON DRIVE

I have to sort out which pins lead to the read/write and erase coils of the two heads. The Diablo schematics should four pins per head, eight total. I know that it uses shielded cables to each head thus there are two more pins used for those shields. There is also mention of a chassis ground connection in the AI, but no documented in the Diablo manuals. That means I have 10 or 11 pins used in a 2x6 connector. If that matches what I find on the actual board and drive, then I can start developing the logic for the adapter.

I must work out how to connect the two erase coils (each with a return line) to the preamplifiers and how to cause only one to drive signals (selection of the head). I have to be convinced I have a rational wiring scheme before I design and manufacture my adapter board. 

Also to be determined is the pin spacing and size of the connector. I will have to put pins on my adapter board that slide into the J10 PCB with good contact, as well as mounting a compatible socket on my adapter where the connector from the disk heads will plug. Any elements needed to select which head I am aligning will also have to be placed on that board. A few turrets may be added to attach scope probes for raw measurements.