More this and that, while waiting

BUILDING BRACKETS AND COATING THE 1130 MRAM BOARD FOR INSTALLATION

The gates in a Solid Logic Technology (SLT) generation mainframe have multiple compartments, each hosting as many as 96 SLT printed circuit cards which plug into a printed circuit board that interconnects those 96 card slots plus some top and bottom signal cables. One side of the compartment has the large board with about 2,500 wire-wrap pins that form the 104 sockets for SLT cards or cable connectors. 

The other side of the compartment is a metal cover behind which the SLT cards are inserted. These cards are oriented so that air flows in the 'aisles' between the cards, from bottom to top, to remove heat. Fans sit on the bottom of the compartment and pull air through filters to blow it up over the SLT cards. The top of the compartment is a grill through which the warmed air exits.

Compartment C1 in gate B housed the original core memory for this IBM 1130. It has a three dimensional core memory stack installed on the big board in place of about half the card slots. The remaining card slots have SLT cards which provide the addressing, driving and sensing circuitry for the core memory. 

Since the core memory stack has irreversible corrosion that is eating internal traces, it is no longer feasible to use it on the 1130. I developed a printed circuit board to replace all of the functionality of that card compartment. The three cables which connect this compartment to the rest of the 1130 circuitry are plugged into my PCB instead of the big board in the compartment. All power connections to that compartment are removed, thus nothing is operating in the compartment; my PCB serves as the core storage for the system. 

My PCB is mounted inside the compartment, just below the top grill where the hot air would escape. The three cables originally plugged into the compartment backplane in the top connector slots T1, T3 and T4. My board has those cables fitted and is suspended at an angle inside the gate just below the grill so that it is cooled by the airflow from the fans below. 

SLT backplane/compartment

mounting method

I cut some brass to form the brackets that will hold the PCB at a diagonal under the grill, permitting the existing SLT cards that are inactive to remain in place. The PCB and its brackets were given conformal coating to keep the electrical components insulated from any contact with the compartment walls or grill. The coating should be fully dry by Wednesday when I intend to bolt the memory PCB in place and close up the 1130 system. 

STILL FIGHTING WITH THE HEAD CLAMPS OF THE DIABLO 31 DRIVE

The Diablo model 31 disk drive mounts two read/write heads on the arm, one each for the upper and lower side of the disk platter that is inside the 2315 disk cartridge. These are held in place by three clamps - one each for the upper and lower head holders and a third that holds both head holders in place.

These had been loosened too much and could not be tightened into their proper position. The upper and lower head holder clamps have a tang at the bottom that nestles into a groove on the drive, keeping the clamp upright so that the bolt simply loosens or tightens it. The bolts had been turned too many times and now the tang was not in place, allowing the clamp to spin around. 

Access to the area where the clamps sit is exceedingly restricted and hard to even see into. I finally pulled out a fiber optic camera on a cable that I could push into the area and try to get enough visibility to work. Below is a view from the camera of one of the two head holder clamps, rotated out of position but at least with the bolt still threaded into the end. 

View through the fiber optic camera - not great

I was able to finally work the lower head holder clamp into position so that it tightened up, held from rotation by the tang. That took quite a bit of fussing and work until I finally got the clamp in place.

I then began working on the upper head holder clamp, but that seems jammed against the lower clamp or perhaps against the third (common) clamp. I need to get this one sorted out before I can move on to the third clamp which should be easier to orient once I slide one of the head holders into place. I ran out of steam; this will be waiting for me when I get back into the shop.

CREATING THE BUILD AND INSTALLATION MANUAL FOR THE V2315CF PROJECT

I am now at a point where I will be finalizing the debugging of the Virtual 2315 Cartridge Facility (V2315CF), an ambitious feature that works with the internal disk drive of the IBM 1130 to allow access to a wide range of cartridge images either archived from real disk cartridges or created on IBM simulators. These can be mounted and accessed as if they were real physical disk cartridges, with the internal drive spinning and the arms moving in and out. 

However, the heads do not actually load down onto the one physical cartridge that is inside the drive, thus eliminating the risk of crashes that could destroy the rare disk heads or the disk cartridges. The data for a virtual 2315 cartridge is held on a microSD card inside a little 2" replica of a cartridge which is plugged into the V2315CF main box. The data that is ready by the 1130 comes from the virtual disk image, rather than the heads in the drive. Any data written or changed by the 1130 will be stored on the virtual cartridge's microSD card. 

Virtual cartridge images can be transferred to and from the IBM 1130 simulators that run on modern computers. As well, the collection of physical 2315 cartridges that I have collected will be archived by the other current project, the Diablo Archiver, so that they can be used on the V2315CF. 

The only issue that was outstanding when I had to walk away from the debugging (due to the core memory of the 1130 failing) was the coordination of seeks (disk arm movement between the 203 cylinders of a 2315 cartridge) between the internal disk drive, IBM 1130 and the V2315CF. I am optimistic that this will shortly be resolved, after which I can finalize the installation of the V2315CF in the IBM 1130 that belongs to the Vintage Computer Federation and which I am restoring. 

This is a complicated system that involves modifications to the internal disk drive, several printed circuit boards, a complex power system with battery backup, and the main box of the V2315CF. The main box is an extensively modified derivative of George Wiley's RK-05 Emulator which he built to emulate the DEC disk drive which is a derivative of the internal disk drive from the IBM 1130. There are also the virtual cartridges, software to transfer the disk images and changes to the RK-05 Emulator kit. Finally, a plexiglass case mounts the main box and some of the other components inside the top cover of the IBM 1130, right atop the internal disk drive. 

I began writing a manual which details all the modifications, construction details and other tips necessary for someone to build and install a V2315CF for use with their own IBM 1130. The project is shared on Github along with PCB design files, Verilog and C code and other essential files, but the manual covers the essentials for putting it all together. This manual will be at least 50 pages long and may grow substantially beyond that as I validate that a reader will have all the information they need to successfully implement the project.

WAITING TO PROCEED ON OTHER TASKS

I have no response yet from Lattice about the license file I need to synthesize the FPGA logic for the V2315CF - those changes are what I must test to finish debugging the seek behavior of the project.  

I am waiting for filter and gasket materials to get the Diablo model 31 disk drive in good working order for the Diablo Archiver project to begin reading and saving the contents of the 2315 cartridges from my collection. 

I will also be tied up all day Wednesday providing a tour of Cape Canaveral Space Force Station and its historical facilities to 200 undergrad and graduate college interns, a Brigadier General and other brass in support of the Air Force Civilian Services organization. It is likely that my progress is mostly stalled until Thursday when the awaited items may be on hand and when I can get time to go back into the workshop.

This and that - waiting while moving several projects along

WAITING FOR FILTER FOAM AND MATERIAL TO REPLACE HEPA FILTER ON DIABLO

The Diablo archiver project depends upon the Diablo model 31 disk drive being ready to safely read the pile of 2315 disk cartridges I have with IBM 1130 software and data on them. The heads are not yet mounted but I also have to ensure that the air supply is clean enough to protect the drive from head crashes that dust or other tiny contaminants might cause.

Bits of foam and gasket material have degraded over the years and must be replaced. They have to provide a tight seal for the purified air that comes in through the main filter on the drive. This filter has a HEPA 13/14 level filter to block all the tiny particles, with a foam prefilter to stop bigger junk from reaching the HEPA filter. There are also gaskets where the filter joins the drive body and also where the clean air enters the 2315 disk cartridge - these are degraded and must be replaced.

I have ordered products I can use to replace the gaskets, the prefilter foam and the HEPA filter so that the drive is again able to provide a clean air environment for reading the cartridges.

MUST WAIT FOR NEW LICENSE FROM LATTICE FOR ICECUBE2 TO TEST V2315CF

Having completed the simulation of the improved seek functionality for the Virtual 2315 Cartridge Facility, I started up iCEcube2 to synthesize the Verilog and prepare to program the FPGA. When it started, I was informed that the free hobbyist license had expired. I submitted the email for a renewal/replacement license, but as it is Sunday I expect it to take a day at minimum and probably more. 

WORKED WITH BETTER BRAIDED GROUND WIRE FOR 1130 MRAM

I received this tinned copper mesh ground wire today and began to install it on the 1130 to provide a low impedance ground path from the 1130 MRAM memory substitute board to the 1130 power rails. There is a bit of work to do with the mounting brackets to place the board safely inside gate B compartment C1 which was where the IBM core memory circuitry resided. 

That wire mesh is enormous overkill, but I want the memory to run clean and after fighting mysterious issues due to the ordinary stranded ground wire, I don't want to accept any risk at all of memory problems in the future. 

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.