Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 4

SIMULATION USED TO CHECK OUT THE NEW LOGIC FOR SEEKS

I carefully simulated seek behavior with the significantly changed code for the seek function in the Virtual 2315 Cartridge Facility (V2315CF). This runs under the Vivado design suite, although the actual generation of the code for the FPGA is done with the IceCube2 suite. 

It seemed to work well, but then again the prior version of the code seemed to work properly. In the real world, the signals come from the 1130 disk controller to the Virtual 2315 Cartridge Facility (V2315CF) and are passed out to the 2310 disk drive inside the IBM 1130. The controller and the drive appear to be in sync at all times, but the V2315CF which is just trying to shadow or observe the seeks ends up with the wrong cylinder number quite often. 

FIXES APPLIED TO V2315CF

My new version of the FPGA logic was loaded into the V2315CF. Up came the 1130 system and the virtual cartridge in real mode. I used my manual instructions once again to see if it does better in maintaining solid synchronization with the 2310 disk drive. 

Alas, I saw similarly bad behavior this time, in spite of an entirely different approach to shadowing the disk arm movements. For example, I performed a forward seek to cylinder 202, by setting the seek value to xC9 which is 201 decimal. When I did a read of the sector, I did see the proper relative sector number in the first word of the sector. 

However, when I tried to back up by 200, which would put me at cylinder 1, the Home indicator came on. I was either not fully at 202 with the forward seek or moved further than 200 in reverse. I tried some small seek values and saw similar mistracking.

It has been my belief that the physical 2310 and the 1130 disk controller were in sync, but I need to test that directly. If I take the top cover off of the 2310 disk drive, I can see the marked cylinder locations on the side of the disk arm actuator. It will be better if I can be completely certain that the drive and the disk controller are correct before I keep mucking with the logic in the V2315CF. 

Next I need to make the PICO debugging output list the cylinder number, allowing me to quickly see where the V2315CF believes we are and compare that to the arm actuator scale and to the intent of the instructions I execute. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 3

DEBUGGING TO FIND THE ISSUE

I looked for asymmetry - places where the logic in the IBM 1130 disk controller or Virtual 2315 Cartridge Facility (V2315CF) do things differently for seeks in the reverse versus forward direction, since the symptom appears to be that a reverse seek doesn't go as far as was requested while the forward ones 'appear' to work correctly based on very limited data points.

The disk controller in the 1130 acts symmetrically. When a program issues an XIO (eXecute Input Output) instruction pointing at an Input Output Control Command (IOCC) of type control, it is requesting a seek. The first word of the IOCC has a count of the number of cylinders to move from the current point. The second word has the code for XIO Control, the device address of the internal disk, and bit 13 which is reverse direction if 1, forward direction if 0. 

The disk controller logic picks up the count from the first word of the IOCC and stores its twos complement in a count register. It then sets the direction of arm movement based on word 2 bit 13 of the IOCC and begins repeatedly triggering the Access Go signal to the disk drive. Each time it issues Access Go, it increments the count register. When the register gets to zero, the seek function ends. 

The only fine point to modify the above is that the disk drive can move either 10 mils or 20 mils at a time, a step of 1 or 2 cylinders. The controller logic uses the 20 mil setting for every Access Go except the first one if the count of cylinders to move is an odd number. The increment of the count register is 1 or 2 depending on the step size being used. 

Nothing differs based on direction in the logic for selecting the step size, triggering each move with Access go, incrementing the count register and ending the seek. The direction signal is asserted based on bit 13 of the second IOCC word and shouldn't change during the seek operation. Unless there is some weird flaky component in the disk controller, therefore, it shouldn't cause the symptoms seen.

I reproduced the anomalous reverse seek stopping point by issuing XIO Control directly to the drive and saw similar behavior. This seems to exclude the disk function diagnostic 309 code. 

My logic in the V2315CF is minimally different for reverse versus forward seeks - the code that stops the arm from moving past its cylinder extremes of 0 and 202 has to check different limits. I don't see how the code could malfunction but it is one of the open areas.

The V2315CF looks for the leading edge of the Access Go signal to perform a seek. I have a chain of four flipflops to deal with possible metastability but don't do any explicit debouncing. The same signal that comes to the V2315CF is passed along to the 2310 disk drive, which also looks for the rising edge to start a movement of the arm. 

It appears from my scrutiny of the drive controller logic that the Access Go signal is blocked when the microswitch is activated by the arm sitting at cylinder 0 (Home). Thus the number of actual movements in the reverse direction will be less than the count from word 1 of the IOCC, if the arm reaches Home before completion of the count. 

This shouldn't impact the V2315CF because we get the Access Go signals exactly the same as the 2310 drive does, from the disk controller logic. A possible source of error is if the disk drive reports Home to stop the movement but the V2315CF believes it is at a higher cylinder number. It will then use the residual higher cylinder number to access RAM for when a XIO Read is done. 

I did plan to make a change to the V2315CF to look at the Home signal from the disk drive. Any time it goes to Home, the cylinder in the V2315CF will be reset to 0. This will sync the V2315CF and the 2310 every time we go to the Home cylinder. However, if the two are not tracking perfectly, the emulation will still not work correctly since the data read and written from the virtual disk cartridge will not match the intended cylinder address except surrounding times it goes to Home. 

To collect more data on the (mis)behavior, I set up the machine to manually issue some seeks and reads. I will move the arm around, in both directions, doing a read of head 0 sector 0 from the resulting location to observe the relative sector number which is written in the first word of the sector. By doing a mix of short, medium and long seeks, including some that attempt to move past Home or cylinder 202. 

The most important thing I detected was that this was not an asymmetric failure, occurring only with reverse seeks. For example, starting with the arm at the Home position and the V2315CF in sync with the 2310 disk, I requested a seek of 32 cylinders forward, then did a read. The first word of the sector told me we had reached cylinder 37, four too far as we should have been at 3... Following this with a reverse seek of 32 cylinders, I found the arm back at the Home cylinder according to the disk drive as reflected in the device status word. A read of the sector confirmed this.

I started at Home, performed a forward seek of 201 cylinders so that we would reach the last cylinder on the disk. A read confirmed we were at 202. If the V2315CF saw excess seeks it would still have stopped at 202 so this didn't tell me we performed exactly the correct number. I then executed a reverse seek of 201 cylinders, resulting in the 2310 disk recording our arm back at Home. However, reading the sector showed me at cylinder 16 as far as the V2315CF was concerned. This matched the asymmetric examples I saw earlier.

Now that the disk drive reported the Home cylinder, it was not possible to get the V2315CF to back up any further than cylinder 16. That is because the 1130 disk controller logic, seeing the Home cylinder, does not perform the reverse seeks I requested. 

For some reason, the V2315CF is not tracking the seeks being performed correctly. We are either dropping or adding movements compared to what the disk drive sees and performs. Given the relatively slow logic in the IBM 1130 and the disk drive, what IBM terms the 30ns medium Solid Logic Technology (SLT) family, short glitches from the controller to the disk might not result in any disk movement but we picked up by my logic. Alternatively, I may be picking up noise from adjacent signal lines that trigger the V2315CF. 

CORRECTION OF THE FLAW

I determined that I can make make use of the interlocked behavior of the 2310 disk drive to more faithfully track disk seeks. Each time the disk drive is commanded to move one or two cylinders, it toggles the Access Ready signal. More specifically, the sequence of signal actions is:

• Access Go is raised to request a disk seek
• several milliseconds pass
• Access Ready is dropped
• Access Go is dropped by the disk controller
• perhaps 10 milliseconds elapse
• Access Ready is raised

Notice the interlocked behavior, with Access Ready dropping to indicate receipt of the seek, Access Go dropped once the drive confirmed receipt, then Access Ready raised to confirm completion of the movement. I can make use of this in the V2315CF logic so that bouncing signals wont trigger multiple seek simulations. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 2

RESULT OF DEBUGGING SESSION ON SEEK ERRORS

My first test was performed by setting up manual XIO commands to seek forward, seek in reverse, read 1 word of a sector and to sense the device status word. I used them to manually command the Virtual 2315 Cartridge Facility (V2315CF) and the attached internal 13SD (2310) disk drive in the IBM 1130.

I had set up the two seeks to move x00C8 cylinders, one forward and the other in reverse. That is a move of 200 cylinders, thus stopping on cylinder 200. The home bit (cylinder 0) was on in the device status before the seek and off afterwards. 

I then did a seek in reverse of 200 cylinders which should have returned us to cylinder 0. The home bit should be on in the DSW and when I read a sector, the first word should be 0x0000 to 0x0007. 

When it finished, the home bit was NOT on. The read displayed a relative sector number of 0x0020 (32) which corresponds to cylinder 4, not cylinder 0. I did another reverse seek of x00C8 but the value read from the sector showed we had only moved to cylinder 1, not to zero. It took a third reverse seek to light up the home bit and to read 0000 as the relative sector. 

This proved that the diagnostic seek to 0 should have been successful, but somehow it read sectors 112 to 119 instead. Similarly to the experiment with the manual XIO commands I set up, the reverse movement is not moving far enough. 

This rules out the diagnostic as the source of the errors. I may be the IBM 1130 disk controller logic, the V2315CF, the 2310 disk drive or some kind of signal integrity problem on the cabling between 1130, V2315CF and 2310. 

The home cylinder status is passed directly from the 2310 to the 1130, thus we are really not backing up as far as the command requests. The V2315CF decision on what cylinder we reached begins with 0 at startup of the machine and then tracks purely by the seek commands from the 1130 controller logic to the 2310 disk. 

I did update the logic so that when the home condition turns on from the 2310 disk drive, we immediately force the V2315CF to set cylinder to zero. This will keep them synchronized whenever the drive goes to cylinder 0. I don't believe this is the cause of the error, but it was something that made sense as I thought about it. 

The data returned by a Read command is based on the cylinder that the V2315CF believes we are at. Thus if the seek logic in V2315CF is not working correctly, it might get out of sync with the cylinder where the arm of the 2310 is flying over. 

I am busy tomorrow but should be back at the workshop on Thursday where I can load the new bitstream to the FPGA and test again. 

Feeling a bit more confident in the IBM 1130 core memory

CE STORAGE DISPLAY FUNCTION OF THE MACHINE

The machine has a few switches intended to be used by the Customer Engineer who services the system. One of them is Storage Display. When turned on, pressing Prog Start has the machine loop continuously through memory reading each word. If there were a parity error it would stop the scan, otherwise it just runs forever until you press Imm Stop to turn off the run flag. 

SHOOK MACHINE AND THUMPED CORE MEMORY COMPARTMENT WHILE SCANNING

While running the Storage Display, I jerked the machine around on its casters and even thumped atop the gate and compartment holding the core memory. No parity errors were detected which comforts me. I had feared there were intermittent connections, similar to the few I have already resolved, that would show up as new parity issues. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 1

IBM DISK FUNCTION DIAGNOSTIC 309 LOADED INTO CORE

IBM wrote a diagnostic to shake down a 13SD disk drive (the drive that is inside the IBM 1130 as well as separately mounted in an enclosure as the 2310). 

The diagnostic identified two flaws in the software simulation of disk drives in the IBM 1130 simulators that run on my laptop. These are the last two tests of the diagnostic, checking for unusual cases either writing a single word sector or writing too many words until the write fails. This will be a great test of my emulation logic in the FPGA. 

Both of these behaviors are produced by the disk controller logic inside the IBM 1130, not by the disk drive. Thus, I have every reason to believe that my logic is going to breeze through those two tests. However, it was worth testing just to be certain that I don't do anything to confuse the disk controller. 

LOADED THE DIMAL CARTRIDGE FILE IN THE V2315CF

I inserted the microSD card into the V2315CF main box, switched the V2315CF interface board to virtual mode, then powered up the 1130 system. Flipping the Load/Unload switch to load resulted in this cartridge being loaded into the virtual disk drive and after 90 seconds becoming ready for testing. 

I used my core memory loader feature to load memory in the 1130 with the contents of the 309 Disk Functional Test diagnostic program. It restarts when you push Prog Start with the machine reset, then setting the console entry switches to 0181 and pushing the interrupt request button on the keyboard restarts and pauses test 309. 

Issuing two more interrupt requests with the console entry switches set to 8000 and then 01C0 fired up the diagnostic, which typed out each test as it completed as well as a summary at the end. 

 DIAGNOSTIC BEGINS AND MOVES INTO ROUTINE 1 - GETTING ERRORS

The diagnostic first seeks backwards and confirms the Home cylinder is detected. It verifies that it receives the four sector numbers 0, 1, 2 and 3 in the correct sequence. It times the speed of the machine and prints out the 1130 cycle time. Lastly it seeks to cylinder 199 and reads sector 3 which contains a specific data word if the cartridge was initialized as a CE testing pack. After this initialization testing is complete, it begins running the test routines starting with routine 1. 

I began to see messages printing out reporting seek errors. Routine 1 starts by seeking to cylinder 0 (Home) and verifying by reading all eight sectors. It then moves around in various patterns, reading to check the achieved location. For each seek error, it flagged the movement (from location X to target Y) along with the cylinder that was actually read. 

My first error was from 199 to 000 but the data read in was from cylinder 14. The second error shows that the software tried to move from cylinder 14 to zero but now found itself at cylinder 12. This continued until I stopped running the diagnostic.

THE V2315CF TRACKS THE CURRENT CYLINDER AND RETURNS DATA FROM THERE

My logic is supposed to monitor every seek command and simulate the achieved position of the disk arm. That also determines which data is returned for a read operation. What I can't tell is what cylinder the 13SD disk arm reached. All we know is that the diagnostics code, the 1130 disk controller logic and the V2315CF were not in sync. 

The diagnostic subroutine that does a seek is given a target cylinder but is tracking the previous location, so that it can request a seek of a given number of cylinders from the 1130 disk controller logic. The controller logic converts that into a number of two cylinder seeks with a final one cylinder seek if the count is an odd number. The 13SD disk drive and the V2315CF should respond to those one and two cylinder seeks by moving the arm that amount. 

The source of the problem could lie in various places. The diagnostic code could have miscalculated the seek distance to request, thus moving both the 13SD arm and the V2315CF simulated arm to the wrong position. The 1130 disk controller logic could have failed to convert the seek count into the proper number of one and two cylinder movements Finally, the V2315CF might have missed movement requests or spuriously detected additional requests. 

The failure appears to be moving smaller distances that was intended - so I don't believe there are spurious movement detections in the V2315CF. It is possible that we are not correctly seeing all of the movements from the 1130 disk controller. 

However, I also have to consider that the 1130 disk controller might have bad logic, as it has not been fully shaken out prior to running this diagnostic. The diagnostic code might have been corrupted on the card decks I used to load it into core memory, thus miscalculating the target movement. 

NEXT STEPS DEBUGGING THIS

I have a few ways I can identify the failing component - diagnostic, disk controller, or V2315CF - in order to dive deeper into debugging. The debug output of the V2315CF should record every seek command detected by my logic - if that shows that, for example, the seek from 14 to 0 really only did a seek of 2 cylinders, then the flaw is more likely to be in the diagnostics or disk controller logic. 

I can try to manually recreate the seek pattern and read a sector with hand entered code. That is, I can first seek to cylinder 199, the back 199 positions and do a read. If I am at cylinder 0 after this, I will become suspicious of corruption to the diagnostic. If I am at cylinder 14, this confirms the issue is in disk controller or V2315CF. Comparing what my seek attempted to the seeks detected on the debug output of the V2315CF will shed more light on the failing.

Signal integrity issues might lead the V2315CF to see a two cylinder movement as a single cylinder movement, or do a few forward seeks when they should be in reverse. That would be immediately obvious from the debug output. 

Ultimately I may need to use a logic analyzer to capture the activity of the disk controller performing a seek of 199 cylinders in reverse, identifying whether it counted correctly and issued 99 two cylinder and a single one cylinder seek in reverse. 

Final parts arrived so I could finish up the Power Distribution Board and second 2310 Interface Board

2310 INTERFACE BOARD WAS WAITING FOR ONE SCREW TERMINAL PART

When that arrived, the second board was completed and is ready to install in another 1130 system. This board has a relay that routes the Unlock lamp signal depending on whether the Virtual 2315 Cartridge Facility (V2315CF) is set to real or virtual mode. When in real mode, the 13SD disk drive in the IBM 1130 controls the Unlock signal, connected directly through to the 1130 console Unlock lamp. In virtual mode, however, the logic in the V2315CF determines when Unlock should light or be extinguished. 

OLD POWER DISTRIBUTION BOARD PCB MODIFIED AND COMPLETED

The Power Distribution Board lacked a 10 screw terminal connector, but also had the defect that shorted the battery power due to a KiCAD quirk. Finally, I didn't like the trace width for the power traces. These two issues are corrected in the new version of the PCB that is currently being fabricated by JLCPCB.com

I cut the grounding copper traces on the power signal that was incorrectly grounded, restoring the intended operation. I also used discrete wire on the bottom to bolster the current carrying capacity of the power traces. This gave me a usable board but I will swap the parts over to the new PCB once it arrives. 

Repair of IBM 1130 core memory with failure of bit 13 inhibit in lower 4K

ROLE OF INHIBIT WIRES

Core memory consists of a memory plane for each bit in a word. X and Y address lines select one core in a 2D grid on that plane. A third wire passes through each core, which IBM sometimes refers to as a Z wire. It is a wire that passes through all the cores on that plane, however, whereas a one X and one Y wire only cross in a single core.

Core memory is read by sending current in one direction (we will call this the Read direction) in one X and one Y wire. That current will try to flip the magnetic field of the core to an orientation we will call 0. The same Z wire that is used for inhibit is also used to sense the value of the core; if the core being addressed as previously magnetized in the 1 orientation, the flip of the magnetic field will produce a pulse in the sense/inhibit wire. Thus, we find out what is in a word by setting its bits to 0. This is called destructive read. 

To write into core memory, we reverse the current direction (now we call this the Write direction) in one X and one Y wire. Where they cross, the core involved will be flipped to the 1 orientation. If we don't want to set the bit to 1, but instead want it to be zero, then we have to inhibit the flip of the core. 

Magnetic cores have a threshold current that must be reached for its orientation to flip (to either 0 or 1 orientation). The current in an X or a Y line is less than the threshold. Thus, all the cores along the X or Y wire are not flipped except for the one that receives current from BOTH X and Y. 

If we send a current in the Read direction through the sense/inhibit wire, the net current in the core is now below the threshold and it doesn't flip. A Read direction current in the sense/inhibit line while we have a Write direction current in X and Y results in the core being set to (actually remaining) the 0 orientation. No inhibit, the core is set to 1 orientation. 

For engineering reasons, the core stack in an IBM 1130 is divided into four sections of 2K bits each. The upper and lower 4K have their own circuitry. Within a 4K section, however, the current loss due to resistance in the sense/inhibit wire during inhibit would be too great if it passed through all 4096 cores. Therefore, one wire runs through 2048 cores and a second wire runs through the other 2048 cores. One end of each of the two wires are connected together (called the common). 

During a read, the sense/inhibit wire ends are connected to a differential detector. When a core flips during a read, the pulse is detected across the two ends, even if the common connection to ground was not high quality.

The use of three wires for sense/inhibit is important to understand because the common point is wired to ground, so that the inhibit current flows through the two wires to ground. The driver for inhibit switches on a transistor to conduct current through a wire to the ground (common), while a mirror driver conducts to send current through the other wire to ground. 

Sense both ends see +6V conducting through the drive transistors, if there is no ground then there will be no current flow. It is only with a good ground at the common point that a current flows through the sense/inhibit wires and can block the flipping of the core. 

The connection point for the sense/inhibit wire triplet is on the top or bottom of the core stack, as shown in this diagram. We are concerned about inhibit for bit 13 in the lower 4K of the core stack. The connections are circled in green. The three wires from bit plane 14 come out on the A side (top of the stack when installed in the machine). These are on the right as viewed from the front of the core stack. 

Along the edges of the PCB at the base of the core stack, the portion closest to the SLT board upon which the stack is mounted, there are small S clips where the sense/inhibit wires are soldered. Counting from the right edge, looking down on the top of the core stack, clips 16, 17 and 18 carry the bit 13 signals from the two senses wires and the common wire, respectively. The wire triplets are white, blue and black - black for the common point. 

THE FLAW WE ARE FIXING

The common connection for bit 13 has much too high a resistance. The fault, as with all the others, is in the PCB sandwich at the base of the core stack, where it routes the signals to connector blocks that project pins through the SLT board for connection to the electronics. This lack of a low resistance path to ground causes the sense/inhibit wires to have essentially no current during a write cycle, allowing the bit to always flip to a 1 state. 

THE FIX

Since the common wire is ultimately connected to ground in the electronics, I can just cut the black wire from the edge S clip, add additional wire length to it, and bring it up to solder onto a ground pin on the SLT board. This will restore the path for current to flow when we inhibit a bit during a write. 

However, the wire broke off the common terminals at the edge of the core plane. I had to solder a new wire onto it, which I then routed to a ground point. The memory is starting to accrete many bodge connections to compensate for failing traces inside the core stack - although not within core planes. 

TESTING CORE SHOWS THE ISSUE IS RESOLVED

I wrote all zeroes across memory and read them back successfully. I also wrote all ones and that was correctly retrieved. This whacks the latest mole, so that until the next one pops up, I can get back to the disk drive functionality diagnostic testing.  I did run some code for a while, with one random parity check popping up. This leads me to suspect that there are more flaky connections in the stack. 

More 'whack a mole' - memory issues crop up; did fix a few things

CORRECTED TEMPORARY WIRING FOR V2315CF

I had failed to connect the sense line for power failure from the main Virtual 2315 Cartridge Facility (V2315CF) box to ground. This is a pullup input pin on the PICO processor that will be pulled to ground by a circuit on the Power Distribution Board as long as the +12V from the IBM 1130 power supply is active. 

My logic requires this to be low for normal operation, such as loading a virtual cartridge image. When it goes high, if a cartridge is loaded the V2315CF drops File Ready and immediately unloads the cartridge image back to the microSD card in the Mini 2315 Cartridge.

I had also built the new version of the 2310 Interface Board, one that contains a relay and MOSFET to drive the Unlock lamp on the IBM 1130 console when in virtual mode. However, I discovered that the real/virtual switch was not being detected. 

After a brief investigation, the cause was apparent. One of the contacts from the switch was not actually soldered to the trace underneath it, although it looked like it was. I repaired that quickly and got the V2315CF to load the virtual disk cartridge successfully. The drive did its 90 second warmup and then the drive was ready for access. 

STARTED 309 DIAGNOSTIC AND IMMEDIATELY STOPPED WITH A PARITY CHECK

After a bit of poking around, I realized that regardless of what data we stored into core memory locations 0 to 4095, bit 13 would be set to 1 whenever the location was next read. This was the same symptoms I saw a few weeks ago, which seemed to go away by reseating a card. Obviously it is a borderline condition that comes and goes. Time to find the root cause and fix it - once again diverting me from the final checkout of the V2315CF through successful execution of the disk function diagnostic. 

WATCHED A FEW SIGNALS TO CONFIRM THAT IT IS A FAILURE TO INHIBIT BIT 13

I can see the bit detected by the sense amplifier - it is detected whether we write a 0 or a 1 into the word. I also see the circuit trying to inhibit the write so that the bit stays at 0, when we want the value to be that. This is a current through the inhibit wire that opposes some of the X and Y write current trying to flip the core. By opposing enough current, it keeps the core from reaching the level where it will flip magnetic state. 

The most telling clue was the oscilloscope image of what the inhibit waveform looks like when we successfully inhibit bit 12, compared to the image of the waveform for bit 13. I built a differential connection as specified by IBM, using a twisted wire pair terminated by 150 ohms to ground at the scope inputs. 

The inductance seen by the voltage on the two wires produces the sloping wave, as energy is absorbed. There is also a reverse EMF when the magnetic field collapses as the voltage source is cut off.  The non-working bit, on the other hand, shows a pure voltage on the two wire ends with no slope. This tells me that we have little or no current flowing in the inhibit wire. 

Inhibit wires have three connections because there is a center tap with each of the other wires running through 2K cores of the 4K total served by these connections. When the inhibit driver is working during a write (when we want the bit to stay 0), there is current flowing through each 2K wire to the center tapped ground. 

The resistance across the two ends - one for each set of 2K cores - was a low single digit value. However, the resistance between each end and the center tap was about 128 ohms. It should be a low single digit value. With this relatively high resistance the amount of current flowing through the inhibit wire is too low, allowing the X and Y driver current to flip that core to a 1 value. We see no reverse EMF in the trace for bit 13 

Interestingly, even without the center tap having a good low resistance connection to ground, the sense amplifier can detect the pulse during a read, when we flip all the cores to the 0 orientation. The induced pulse is reliable. Thus, our center tap issue is mainly affecting the write cycle where the wires are used for inhibit, with little impact when they are used for sense. 

SIMILAR ISSUES TO OTHER FAILURES IN THIS CORE MEMORY MODULE

We have had several failures in the core memory module on this computer. Most of them involved the connections to the sense/inhibit wires. In all the cases, the broken connection was on the PCB on the bottom of the core stack which routes signals from connector blocks to the edge where discrete wires carry the signal to the core planes. 

I went through several gyrations to bridge the signal from the core planes, where the sense/inhibit wiring was always intact going through the cores themselves, getting it connected to the circuitry in the compartment that surrounds the core stack. Had any breaks been inside a plane, where teeny wires are threaded through thousands of small cores, it would have been much more difficult to repair.

CONSIDERING WHETHER I CAN REPAIR THE PCB OF THE CORE STACK

With all the welded and soldered connections to many small wires on each of the 18 core planes, all the wires running between the planes and down to the bottom PCB, and many wires running up and down on the outside of the planes, it seemed impossible to open up a stack so that I could separate the planes and PCBs. 

However, I do have a core memory stack of very similar technology. I believe this one was used with an IBM 1800, a sister computer to the 1130. The main difference is that the 1800 has some additional memory addresses (AUX area) that can be used; the 1130 does not use these areas. It is banged up and definitely not usage. It was marked to be scrapped. It does, however, let me try to open the stack up as much as I can since there is no risk of damaging a working 1130. 

The last picture above is of the bottom PCB that is used to interface the core stack to an SLT board that has support electronics ringing the stack. The connector blocks you see fit through tiny drilled holes in the SLT board and stick up alongside pins that are installed on the SLT board. A jumper block is plugged over the mix of SLT board and core stack pins, connecting the signals together. 

The connector blocks carry the X and Y addressing signals as well as the sense/inhibit signals. The bottom PCB is actually a sandwich of two PCBs, not a multilayer board but two separate PCBs sandwiched together. Around the edges of this PCB sandwich, pads are connected using "S" clips that clamp the boards together. 

The PCB that is visible has traces for the X and Y addressing lines. Diagrams in the Automated Logic Diagrams (ALDs) for the core storage show these patterns, which are the ways that signals from the edge connect to common wires that run on the other side of the bottom PCB (bottom of the two PCBs in the sandwich). 

However, we do not see the traces for the sense/inhibit wires. These are connected near the corners, also using S clips, but the traces are on the upper of the two PCBs in the sandwich. The pictures below show the traces running from the sense/inhibit S clips which will connect to pins on the connector blocks in the central area of the bottom PCB. 

The sense/inhibit wires are twisted pairs of white and blue, plus a black common wire. They are soldered to the small S clips on the edges and tack welded to the ends of the wires at the core plane. I do have access to the wires and to the ends that come out of the core planes. 

PLAN OF ACTION FOR REPAIRING THE INHIBIT BIT 13 DEFECT

Based on what I see from the partially disassembled scrap stack, I will look for a good low resistance ground connection from another bits wiring, then bridge that to the black wire for bit 13. It is slightly less desirable that the individual ground connections with controlled traces (I assume) on the upper PCB of the bottom PCB sandwich, but should work well enough. 

HACKED THE POWER DISTRIBUTION BOARD TO CONTINUE TESTING

The power logic for the V2315CF involves a battery, a charger/maintainer, the 12V from the IBM 1130, a time delay relay, and the power supply for the main V2315CF box. The Power Distribution Board was central to this functionality, including a circuit that detects when the 1130's 12V supply stops so the V2315CF can do an emergency unload of the virtual cartridge if it was loaded. The timer disconnects the battery after 40 seconds of battery only operation, sufficient for the unload. 

A flaw that I missed resulted in KiCAD grounding the connection from the time delay relay to the power supply. This caused a big pop when I first triggered the relay to test the 40+ second battery power for the power supply. It blasted a trace apart inside the time delay relay. 

I repaired the relay, then got to work on the Power Distribution Board. Since I had a ground plane across the bottom of this PCB, KiCAD made the connection to ground by connecting the terminal screw 10 pin to the ground plane with four thermal relief pads. It also connected the hole where a diode was inserted to feed the power supply, putting in four thermal relief connections to the ground plane. 

I grabbed my trusty knives and dug away the copper thermal relief connections, disconnecting screw terminal 10 and the diode hole from ground. Once I verified that it was isolated, I returned to my testing of the power logic.

Yellow circles where I removed the thermal relief connections

This time, when I triggered the time delay relay with 12V that would be coming from the IBM 1130 12V source, it connected the power supply to the central bus. Since the battery was feeding the bus, the power supply turned on. About 40 seconds later, the relay dropped the connection and the power supply was off. 

I do have replacement boards coming that do not have the incorrect grounding, avoiding the need to rework the boards with an Xacto knife. When they arrive I will switch the parts over to the correct board. I have one more test to perform, once I connect the battery charger/maintainer to the board. I will have the charger hooked to 115VAC, everything else in place, with a bench power supply standing in for the 1130 power supply. 

The test will be to first run with the bench power supply, seeing the V2315CF power supply turn on and stay that way. Next I will switch off the bench supply. The V2315CF power supply should remain on for about 40 seconds, using the battery, then switch off. While this is happening, I will watch the signal output that is the power fail warning to the V2315CF. 

Laptop parts swap completed; fault in V2315CF power distribution board

FOUND AN ERROR IN THE V2315CF POWER DISTRIBUTION BOARD

I was rewiring the Virtual 2315 Cartridge Facility (V2315CF) with the final versions of the power related equipment, doing a bench test with everything connected to sanity check the operation before it was installed on the IBM 1130. 

The power from the battery (and its permanently connected charger/maintainer) is connected to the V2315CF power supply through a ride-thru timer module. This module is powered by the battery, but its trigger is the incoming 12V from the IBM 1130. As long as the 12V is arriving from the IBM 1130, the timer keeps the connection to feed into the V2315CF power supply. 

When the 12V from the 1130 drops, the timer retains the connection of the battery to the V2315CF for about 40 seconds, which will be long enough for the V2315CF to do an emergency unload and writeback of a virtual cartridge file if it was loaded when system power failed. 

I had the timer wired in, the battery, and the V2315CF power supply. I had not yet connected the charger/maintainer when I tried the first test. With no simulated 12V from the 1130, the timer had disconnected the battery from the V2315CF power supply. When I provided 12V to the timer to make it activate, a trace quickly burned through on the Power Distribution board I was testing. 

Some checking uncovered the fact that when the relay activates, it connects the battery input directly to ground! It also connects it to the V2315CF power supply, but ground wins in this contest. That is not correct. 

I opened the KiCad design files and discovered an unintended connection of the terminal block screw 10 to ground. I had tied all the ground screws together and marked that net as ground. However, when I drew the line from screw terminal 10 to the power supply input diode, KiCad helpfully added a dot to the wire it was crossing to connect it to ground. It was only because the ground symbol was close enough to the horizontal line from screw 10 that it assumed they should connect. 

I guess I didn't notice that because all the other even numbered screws are actually ground connections - 2, 4, 6, and 8 - so this wasn't visually different. However, it does mean that the board is not usable. I did a quick fix and sent it out the JLCPCB to fab a new set. 

THE SECOND LENOVO LAPTOP ARRIVED TODAY AND I DID THE PARTS SWAP

I had ordered a "used, good as new" Lenovo Ideapad L340 17IRH gaming laptop from them through Amazon. I opened up both of them and exchanged the SSD, the Intel Wifi/Bluetooth module, and the RAM card. I changed the RAM because the replacement laptop only had 16MB installed while my original was a 32MB machine. 

The 'new' machine is working great. I tested all my node locked software, no issues. It did meet my primary goal, which was as expedient a repair as possible with minimum downtime from my more important project goals. 

Console printer ready and diagnostic program now running

DIAGNOSIS OF THE MISSING -TWR CB RESPONSE SIGNAL

The power cable to the typewriter - an SMS paddle card plugged into the base of the IBM 1130 - supplies 115VAC for the typewriter motor, +12V and +48V. The 48V passes through three sequential microswitches, which IBM terms circuit breakers (CBs). These are actuated by cams or other moving parts to break the connection during the active portion of some typewriter operation and restore it as it finishes. It is wired to the 1130 logic as the -Twr CB Response signal. 

CB2 rides on a cam on the end of one shaft that only rotates during a print cycle - when the typeball is going to be slammed against the ribbon and paper to produce a printed character. The connection opens at approximately 20 degrees of movement and closes again at 120 degrees, out of 180 degrees that this particular shaft turns in a single print cycle. 

Printing begins when the selection solenoids are activated, simultaneously tripping the print cycle clutch. The solenoids that were activated release an arm from a hook so that it is NOT pulled down by the print mechanism. These arms pivot levers that ultimately produce the rotation and tilting of the typeball as it is set up for printing. 

The purpose of CB2 is to prevent any additional selection solenoid activations during this time when the ball is rotating and tilting for the initially selected print character. After the 120 degree point, the golf ball is locked into position, ready to fly forward toward the ribbon. All the mechanical motion from 120 to 180 occurs without regard to the arms that might be selected for the next print character.

In order to achieve the fastest possible print speeds, the computer could now trigger a new set of solenoids to select the next character to be typed. The print cycle clutch would remain tripped and as the first print cycle ended at 180 degrees the mechanism would just continue on, pulling on the arms that were not selected for the second print character, rotating and tilting to a new position, and preparing the ball for typing. 

The only way to achieve the 16.5 character per second max rate is to have selected the next character before the prior one has mechanically completed. The controller logic in the IBM 1130 is blocked from activating the selection solenoids (and triggering the print cycle clutch) when the circuit for -TW CB Response is opened by CB2. As soon as CB2 closes again, it can activate solenoids. 

CB5 is activated by the operational section, which involves a set of clutches that turn a mechanism 180 degrees when the clutch is tripped. That rotation is converted into vertical movement of a plate on the rear of the typewriter. As the plate is moving, CB5 opens at about 15 degrees of the operational clutch rotation and closes again at 105 degrees. 

There are two operational clutches, which convert the continually turning shaft motion into a rotation. One of them turns a full 360 degrees - it is used for carrier return and line feed activation. The other is the one connected to CB5, which makes just one 180 degree turn each time it is tripped.

The 180 degree clutch is connected to three different solenoid activated linkages - tab, backspace, and space - which cause it to rotate. In addition to tripping the 180 degree clutch, each linkage will move a pivot arm under that vertically moving plate at the rear of the typewriter. If the pivot arm is under the plate, it is pulled down during the clutch cycle. CB5 is pushed open by an arm of the vertically moving plate. 

For example, the space linkage, when pulled down, rotates a spring loaded hook down to grab and twist the space torque bar, with the hook pulling off the torque bar partway through the hook's downward movement. It is designed to impart a short twist to the space torque bar, which pops a tooth out of a rack temporarily on the carrier. The coil spring has tensioned a cord that tries to pull the carrier rightward at all times. The tooth is what stops the carrier from movement, so the temporary removal of the tooth lets the carrier slip to the right one rack space. 

The operational unit functions - space, tab, return, etc - are independent of printing characters. It is important to block a new request from activating while mechanical motion is underway on a previous one. We don't want to space to the right while simultaneously driving the carrier to the left margin in a return operation. 

Thus CB5 keeps the 1130 controller logic from activating any solenoids to drive the 180 degree operational clutch by opening for a portion of the clutch rotation. A different mechanism blocks the controller while the indeterminately long functions of a carrier return or a tab movement take place. These depend on the position of the carrier when it starts, and on the column where a tab stop is set in the case of a tab movement. The +Twr CR-LF-T Intlk signal handles this, routing +12V when these long functions are active. 

The final CB in this chain is CB7, which blocks typing while a shift of the ball is occurring. The Selectric typeball has two hemispheres with 44 characters each. On a typewriter used for normal office purposes, we have both capital (upper case) and lower case versions of the 26 letters. One hemisphere of the ball is the upper case side, the other hemisphere is for lower case. When switching between the cases, the ball must be twisted 180 degrees by the shift mechanism. 

The controller logic in the IBM 1130 keeps track of which hemisphere is current in use. If the next character to be printed is located on the other hemisphere, the logic first triggers a shift cycle to turn the ball. Once this is done, the logic then triggers the selection for the actual character we want printed. 

Thus two cycles are needed when shifting between upper and lower case, rather than one. This drops the printing rate of the typewriter - at worst case its maximum would be a bit over 10 characters per second if every other character was on the opposite hemisphere. This is faster than simply half of 16.5 because of the overlap afforded by the timing of the CB signal. 

The solenoid that triggers a shift between hemispheres is fired, and while the shift mechanism does its 180 degree rotation from one position to the other, a cam causes CB7 to open at 15 degrees of rotation and close at 115 degrees. This holds off the activation of any character selection solenoid and thus holds off a print cycle while it is open. The choice of 115 degrees allows the maximum safe overlap of a print cycle with the preceding shift cycle, maximizing print speed of the console printer. 

In addition to the task of blocking solenoid activation while at sensitive points of mechanical motion in the typewriter, the signal is used to set the end of operation latch in the logic. This happens with a rising edge of the -Twr CB Response signal, as the CB involved restores the connection to 48V. If the signal does not drop during a print, shift or other operation, then it won't be detected as a rise. 

When the operation complete latch is set, it also raises the request for an interrupt on level 4. The 1130 will branch into the interrupt handler, check the device status for the console printer, reset the operation complete condition during the XIO Sense DSW it used for the check, and branch out to clear the interrupt level. This normally triggers software to issue the next XIO Write to print another character or request another movement from the typewriter. 

When the operation complete latch is not triggered, we don't get an interrupt request and the software that is driving the printer will stall. That is precisely what was happening with the console printer in this case. I had to determine why we were not seeing the signal dip and rise. 

CB5 which I worked near is associated with space, backspace and tab operations driven by the 180 degree operational clutch. It remains closed otherwise and the signal dip would be caused by CB2 for a character printing (and possible CB7 if the ball had to be shifted between cases before the typing). This strongly suggested that I had not mechanically misadjusted CB5 to cause the problem.

I checked the presence of 48V going through CB2, CB5 and CB7. I checked for continuity of the -Twr CB Response line from those CBs back through a signal SMS paddle card into the IBM 1130 logic for the console printer. No 48V getting to the logic backplane. 

I decided to track it through the three CBs and then down the cable. That was when I noticed that the cam for the shift mechanism, driving CB7, was in the wrong position. It was holding the contacts open while the ball was at rest, not while it shifted hemispheres.

REPAIR AND SUCCESSFUL OPERATION RESTORED

I could rotate the cam relative to the shift mechanism itself, but it should be anchored in one position to achieve the make and break degree positions defined for the CB. Here it is oriented as it should be resting when we are not in a shift cycle. 

I removed the circlip and washer to expose the screw that sets the cam in place. The screw inside was indeed very loose. 

I hand cranked the machine through shift cycles, varying the position of the cam, until it achieved the make and break timings we need for good operation. I then locked it in place with a bit of gorilla glue so that it won't work loose again. 

FIRING UP DIAGNOSTIC MONITOR AND DISK FUNCTION TEST 309

Using the core memory loader function on this system, I loaded the core memory I had saved when I started the diagnostic monitor and the disk function test diagnostic on an IBM 1130 simulator, held at the point where I could start it up to test the Virtual 2315 Cartridge Facility. The machine was paused between instructions of the diagnostic monitor, which I could then resume by pushing Prog Start on the 1130 console. 

Setting the console entry switches (CES) to 0181 and pushing the interrupt request key (IRQ) on the 1130 keyboard will ask the diagnostic monitor to restart the 309 diagnostic in paused mode. Turning CES to 8100 and hitting IRQ will select the 1130 internal disk drive for testing. Flipping CES to C10C and hitting IRQ informs the diagnostic that we are aware it will write patterns on many disk sectors because this is a test cartridge, not a live customer cartridge. Turning CES to 4100 and hitting IRQ selects the tests to run (all of them) and then choosing 01C0 in the CES will start the diagnostic when we hit IRQ. 

As the diagnostic 309 is restarted and paused, we will get a printed line each time we hit IRQ informing us that the CES value was received and passed to the diagnostic. The final IRQ with CES at 01C0 prints the start message for the diagnostic (START 0309) then various informational (and possibly error) messages printed as the tests are performed. 

I brought it up to the point where I was ready to start 309, having 01C0 in the CES, but needed to bring up the virtual disk cartridge in order to proceed. I was rewiring the power connections to the Virtual 2315 Cartridge Facility and did not get the sense wire connected that informs the logic that we have good power from the 1130's 12V power supply. Without that connection, the logic would not load a cartridge because it believed we were in a power failure situation. 

The erratic space function and other adjustment issues made the print above a bit rough, but good enough for me to run the diagnostic and evaluate its outcome - once I get the power wiring fixed. 

1053 Console Printer has capacitor replaced - motor now working well - one small issue to debug

MOTOR NOW RUNS AT FULL STRENGTH

With a proper value capacitor wired correctly to the motor, it now starts up crisply and can maintain torque through the printing and movement operations of the 1053. The results were all I hoped for, with clean typing, tabbing, carrier returns and other operations. 

The replacement was close enough to the original equipment part used by IBM that it fits into the existing bracket and available space. 

RAN HAND LOOP TO SEND COMMANDS - DISCOVERED INTERRUPT NOT RAISED

If I reset the 1130, which sets the initial state of all the flipflops in the machine to their starting state, I can fire off one command to the typewriter, which it performs well but only that one will be accepted. The typewriter controller logic should raise interrupt level 4, presenting an operation complete status in the DSW, but it did not occur. 

The logic for a print cycle which culminates in the interrupt request looks at a signal from the typewriter (-Twr CB Response) to tell it that the machinery has completed its movement. It won't accept a new command until the prior one is over, to avoid jamming the machinery with conflicting movements of parts that might occur from overlapping operations. 

The -Twr CB Response signal is a series of three microswitches that are normally closed, delivering +48V to the controller logic. When the typewriter is in motion during operations, one of these is opened for the portion of the motion that can't be interrupted by new requests. The logic looks for the -Twr CB Response signal to drop from 48V to 0, then return to 48V as the operation is completed. 

I did a very quick check as I was preparing to leave the shop for the day, testing continuity from the pin where -Twr CB Response enters the logic compartment going back to one of the three microswitches. It should have shown continuity, but there was no connection registered by the ohmmeter. 

I expect this to be a relatively simple issue to find and fix, when I return to the shop tomorrow. One of the three microswitches is right next to the capacitor mounting position, thus I might have disturbed something during my work. 

REMAINING ISSUES TO BE RESOLVED - SPACE AND FRONT PANEL BUTTONS

The front panel buttons - Space, Tab and Return - fire the same operational unit clutches as the solenoids when an XIO instruction requests those movements. Therefore, since the XIO versions work properly, the failure is due to mechanical adjustment of the buttons and their linkages. I will address this later as it is not essential to running the disk diagnostics. Below is some background on how the adjustments are made. 

The adjustments for these take place in two places and they interact. There is no process I can see other than trial and error to work out the best adjustment for each half of the mechanism. 

A pivot on a bar fixed to the typewriter frame pulls on a cable - similar to the cables used to open automobile trunks or to adjust lawn mower carburetors - that sides inside a metal sheath. The other end of the cable is attached to a swing arm, spring loaded to its idle position, that will push down to trip the operational clutch release latch arm to trigger the desired function such as tab or carrier return. 

I can adjust the positions of the cable, the swing arm, the pivot and by tweaking all, I get a positive release of the operational clutch release latch for a clean movement of the pivot at the front of the typewriter frame. 

The faceplate of the console printer has the sixteen console entry switches attached to the top, some lever parts involved in setting and clearing tab stops, a display window that shows the left margin, current carrier column and right margin, and three rectangular pushbuttons marked Space, Tab and Return. 

These three buttons are spring loaded to remain toward the front, with a foot on the rear of each button that will push on the pivot arm for the other mechanism. The front of the pivot arm has a screw whose head is contacted by the foot on the button. By turning the screw in or out, I can adjust the position of the pivot at rest and when the button is depressed. 

The position of the button foot when it is unpressed, held out by the spring loading, isn't easy to see when the faceplate is installed on the front of the typewriter. This makes it challenging to set the screw on the pivot arm to a reasonable position that just touches the button at idle and also pulls the cable far enough to reliably trip the operational clutch release when the button is depressed. 

Adding to the challenge, if the cable pulls on the swing arm too far, it can slide under the operational clutch release latch and get stuck in place, blocking both the operational function the clutch provides and preventing the button from being used again 

The space movement of the console printer is triggered two independent ways. One is triggered by a cam at the end of each character print operation  - this one works fine. The other is triggered by an operational clutch fired by either the solenoid or the front panel pushbutton. This is the one that didn't work. 

The torque bar that lets the carrier be pulled forward one space is common to both methods. The rod coming from the print cycle mechanism will pull on the torque bar, with the length of the rod adjusted to make sure it activates the space when pulled but allows the carrier to stay locked on a column when it shouldn't be moving. 

Another mechanism has multiple parts that rotate and then convert that into a downward pull on a small hook which pulls on the torque bar but slips off before its pull motion is complete. Slipping off is essential so that it doesn't hold the torque bar too long and allow the carrier to move more than one column to the right. On the other hand, the hook must engage with the torque bar and pull it far enough before the hook slips off, so that the torque bar is rotated enough to release the carrier reliably for its one space movement. 

Several adjustments interact to get that arm to move the proper amount and slip off when the operational clutch for spacing is tripped. The clutch takes a 180 degree spin, in doing so it pulls down on a spring loaded lever that is coupled to the other parts that ultimately move the hook up and down. The hook is spring loaded to rest over the torque bar but the spring is light so that the hook can slip off the torque bar when it turns enough to release the carrier. 

Lack of the ability for XIO to put in spaces will only impact me slightly with the diagnostics. The text of a message will be smooshed together without separation of words, but otherwise legible, because each letter printed will get its own space during the print cycle. Therefore this adjustment can be postponed until later, letting me proceed rapidly to the disk functionality diagnostic 309. 

IBM 1130 Console Printer - 1053 Selectric typewriter - it was the Run capacitor! Waiting for replacement part

COMMENT BY A FOLLOWER POINTED ME IN THE RIGHT DIRECTON FOR THE PROBLEM

The motor on the I/O Selectric Keyboardless Printer (the console printer of the 1130) was stalling in the middle of printing most characters as well as moving the machinery much slower than usual. I was planning to verify the voltage was correct but Merlin Skinner-Oakes, who read the blog entries about the printer behavior, suggested that I consider the Run capacitor if this was equipped with one. 

Ordinary Selectric typewriters use shaded pole motors without capacitors, but on many of the printer models such as mine, IBM substituted an inductance motor with a capacitor that functions as both a start and a run capacitor. If that was bad or out of circuit, it would explain the weak start and lack of oomph. 

CHECKING CAPACITOR ON THE 1053

I removed the wiring to the capacitor on the rear of the console printer chassis and tested it with a capacitance meter. This is a 4 mfd Sprague Chlorinol 330V capacitor designed for induction motors. It is bolted on the back of the frame with cardboard insulation around the electrodes. I removed the bracket then took off the insulation. 

The issue was pretty clear as soon as I saw the capacitor without the insulation. The can was bulging out and deformed at the plate with the electrodes. 

I checked it with my test gear and found it had a capacitance of about 0.1 nanofarad and was essentially a short circuit at 0.1 ohms across the terminals. 

I purchased a 4 mfd run capacitor of almost the same dimensions, which will fit properly in the bracket and inside the typewriter. I should have it installed by Saturday and be able to verify that the console printer is back to 'console printing'. 

Update on console printer, testing and other issues or activities

MOST 1130 DIAGNOSTIC PROGRAMS TOTALLY RELIANT ON TYPEWRITER WORKING

Most of the diagnostic programs run under the Diagnostic Monitor, a program that provides essential hosting and common services for each diagnostic. It is a powerful capability as it supports multiple concurrent diagnostic programs, providing time sharing that is otherwise unknown in the IBM 1130 system. 

The normal operating software, Disk Monitor System, runs a single program at a time and is a card and printer oriented batch processing system. The Diagnostic monitor relocates diagnostic programs allowing them to stack in core memory, its supervisor will alternate providing processing time to each running diagnostic, and its user interface (console entry switches and typewriter) is designed to be shared across the diagnostics. 

The Diagnostic Monitor logs the status of diagnostics with typed lines on the console printer (typewriter). As each stacked diagnostic is started, it is assigned a relative number that you use to direct the console entry switch (CES) setting and interrupt (IRQ button on keyboard) to a specific number. One can also direct a CES and IRQ to all running diagnostics, if it makes sense. 

My disk functional test, diagnostic 309, depends on the Diagnostic Monitor. That first starts up, prints in initial message, then loads 309 and begins its operation. That is accompanied by a message on the console printer. 

Each command given to 309, such as selecting which drive number to test, involves setting the CES and hitting IRQ. The monitor prints out the CES value passed to 309. There are three different CES entries needed to start 309 testing the drive inside the 1130, each of which must print first. 

The diagnostic prints messages with status as it runs through its various tests, as well as printing more detailed error messages when an issue if detected. For each such printed message, diagnostic 309 calls the diagnostic monitor to do the typing and will not resume executing until the monitor reports completion of the output. 

In other words, until the typewriter is working or I find a way to fool the diagnostic monitor, I am unable to run the disk function diagnostic 309. I therefore have to invest time working on the typewriter first, before I can finish the high priority work which is finalization of the Virtual 2315 Cartridge Facility. 

TYPEWRITER SYMPTOMS AND INVESTIGATION

Any XIO instruction to type a character will cause the typewriter to begin printing. It rotates and tilts the typeball to the appropriate character position and then throws the ball forward into the ribbon and paper behind that. Starting from a known good condition when power is first turned on, I will see the typeball get partway through a print cycle and come to a halt. From that point, the motor of the typewriter is stalled. 

I triggered a shift between lower case and upper case, which worked quite well. I did find a few characters, mostly those with minimum rotation and tilt, that would complete without the motor completely stopping. However, even those moved very slowly. 

I can trigger a tab, a carrier return, and a backspace using an XIO command and I see them begin. The CR causes the motor to stall, but at least the mechanism begins to work. Curiously, the space command does not cause any spacing - no sign of any action at all. The front panel Space, Tab and Return buttons do nothing. 

I have a good 48V voltage delivered to the typewriter, Most of the solenoids do appear to operate successfully since I start printing characters or doing non-print movements. The motor seems very weak and anemic, almost like it is receiving well below 115V. I do need to check the voltages for the motor, but the most likely suspect behind all of this poor behavior is solidifying IBM lubricants. That is, the oil and grease that I mostly flushed out with my clock oil remained in small quantities and is again binding the mechanisms. 

LAPTOP PHYSICAL COLLAPSE

The primary laptop I use to work with the 1130, design code, and so forth is rapidly becoming a pile of broken parts. It is a Lenovo Ideapad with a 17" screen and i7 processor. A fatal flaw that I discovered which plagues these machines is failure of the hinges. About a year ago, the right hinge became stiff and hard to rotate when opening and shutting the lid. Six months ago, the screws tore out of the plastic case since the hinge would no longer rotate at all. Thus, the right side of the screen was detached, an ugly bit of metal stuck out, and I had to carefully move the lid to use the machine at all.

Nothing I did would free up the hinge. Internet searches turned up a litany of hinge failures, endemic in Lenovo machines that used this hinge design. Apparently they were not being repaired by the maker either, thus the owners had to buy a new laptop when the hinges froze. 

About a week ago, the left hinge began to bind up as well, thus pushing apart the plastic on the body. The screen/lid now barely holds in place when I jockey it open and I am likely just weeks away from the screen cable tearing as the death knell for the system.

I have lots of software that is licensed to the ethernet MAC address, which would be a major pain to deal with if I just moved to a new laptop. Plus there is the joy of reinstalling and reconfiguring everything I have on this system.

BOUGHT ANOTHER OF THE SAME LAPTOP, WILL SWAP ETHERNET AND DISK

I found a used Ideapad 340 17IRH that Lenovo was selling and purchased it. I plan to swap the disk drive and the ethernet/wifi parts that contain the MAC address so that I can presumably keep working as if the PC hadn't fallen apart in my hands. 

SLOWING WORK IN THE SHOP

This does slow work in the shop, as I have to baby the laptop and take extra time before doing simple things like loading a new FPGA bitstream, loading code in the 1130 core memory, or connecting to the debug serial output of the Virtual 2315 Cartridge Facility. 

BOUGHT A MOTORCYCLE LIFT TO RAISE 1130 BOXES UP IN THE AIR

Some work I do on the IBM 1130 required me to lie on the floor on pads while I awkwardly worked on objects that were 6 to 14 inches above the ground, but deep inside the box. Trying to solder wires while on my back looking up is annoying, too. 

I located a motorcycle lift that has a platform which is 87 inches wide and 27 inches deep. It can lift up to 1000 pounds getting those pesky lower areas up where I can comfortably work on them from a chair. An IBM 1130 is 29" deep and 58" wide in its basic configuration and 88" wide with the expansion frame added. 

That may appear to be an inch or two too large for the lift, however it rolls on heavy casters that are offset inside those dimensions. Thus the 1130 models will fit on the lift. The basic configuration is around 750 pounds and the full machine with expansion hits 1000 pounds. 

When I showed up at Harbor Freight to pick up the box, which the online manual shows comes in pieces that are bolted together by the purchaser, I expected I can get it into the trunk of my Tesla, with the rear seats down to allow the box to slide back far enough.

I discovered that the motorcycle lift was shipped in a crate for handling with a forklift. The crate was eight and a half feet deep, with tall wood strips across the bottom to raise the crate off the ground to permit the forklift to get under it. The weight was heavily skewed to one end. 

Thus, the boxes width and height would fit in the Tesla trunk, but the wood blocks on the bottom made it impossible to slide it in easily. The depth was too long to fit with the trunk closed, even if we could have gotten it fully inside. Lastly, the wood blocks were arranged for the forklift to fit under with the crate extending side to side eight plus feet. If they had been at right angles, the forklift might have been able to drive the crate into the Tesla, but that wasn't the situation I faced.

Somehow we got the crate into the Tesla far enough to ensure that with the very heavy end inside, it wouldn't tip out. The trunk lid closed partway and I drove slowly and carefully out to my shop. Getting the crate in the car depending on the help of the forklift. With no forklift at the shop, I had to improvise to get it out all by myself.

Fortunately, the crate wood used by Harbor Freight is so thin and cheap that I could tear apart the crate with pliers, screwdrivers and my hands, no saws or heavy machinery. I took out sections of crate, removed the big wood blocks from underneath, and then pulled the various components of the lift out of the crate one by one. 

The final piece, which was still around five feet long, I was able to slide inside the crate until it was ready to tip down to the ground. I had to pull it far enough out that it didn't pivot up and strike the inside of my car, so there was quite a bit of tugging and lifting of weight involved towards the end. 

In the end though, through sheer stubbornness, I persevered. I had the parts all on the ground outside the shop and put it together out there. I then collected all the crate parts, broke them down to more manageable sized pieces, drove it over to my condo and got it all in the dumpster that sits under the garbage chute in the building. 

I rolled the lift into the shop where it waits for the next time I need to get access tbo the lower part of an 1130 box. Currently, the typewriter that I have to work on sits at the upper portion of the machine, but it won't be long before I want to get this on the lift and ready to raise and lower. 

PREPARING NICE LOOKING ENCLOSURE FOR VIRTUAL 2315 CARTRIDGE FACILITY

I drew up a design for an enclosure that will sit inside the IBM 1130, accessibly by lifting the top grey cover to the right of the typewriter. Inside it I will mount the main box, the power distribution board, the time delay relay, the power supply and angle the main box up so its face is tilted where the operator can best see it with the 1130 cover open. 

The enclosure will be constructed of black opaque acrylic. I ordered the acrylic sheets in roughly the proper sizes but have developed laser cutter files to cut the precise outlines and various holes I will need. 

FINISHING PRODUCTION VERSIONS OF MY PCBS FOR THE FACILITY

As I receive the final components from Digikey, I am building the final versions of everything with the goal of having a full final version of the Virtual 2315 Cartridge Facility working on the VCF's 1130 system, plus a second unit ready to install on the System Source Museum's 1130. 

Ready to run disk functionality diagnostic (309) but 1130 console printer not working

LOADED 309 DIAGNOSTIC PROGRAM VIA CORE MEMORY LOADER

I set up the diagnostic on an IBM 1130 simulator then dumped the contents of core to a file. My core memory loader add-on to the 1130 makes use of that file to load core memory of the physical 1130 system with the same data as was in the simulator. It does this via a terminal program on a PC that communicates over a USB cable to the feature in the 1130. The program sends each line of the dumped memory file to the core loader, paced by prompts from the loader. 

STARTED THE DIAGNOSTIC ON THE 1130 WITH THE TEST DISK READY TO ACCESS

A test disk image was loaded via the Virtual 2315 Cartridge Facility and the disk drive spun up. When the File Ready light came on, I set up the console entry switches to begin the diagnostic. A code is set in the console entry switches and the IRQ key on the keyboard is pressed to enter each request.

The diagnostic monitor program that hosts the diagnostic will first print out the code received via the interrupt request (IRQ). The typeball turned slightly and froze. No letter was typed and the typewriter was unresponsive to button presses on the front panel. 

Since diagnostics and the diagnostic monitor communicate status and results via typed messages, this blocked use of the diagnostic. When I get time back in the workshop I will figure out the issue and correct it so that the console printer is working again. 

New PCBs arrived, building them for two Virtual 2315 Cartridge Facilities in final form

PCBS FROM FAB ARRIVED

I had what I believe are the final versions of the 2310 Interface Board, Power Distribution Board and the dress faceplate. The faceplate was a purely cosmetic remake. The 2310 Interface Board added a relay and changed the circuits for lighting the 1130 console Unlock lamp. The Power Distribution Board had additional terminal connections to improve the wiring to the time relay that keeps the Virtual 2315 Cartridge Facility (V2315CF) powered up from the battery after the 1130 system power drops. 

BUILDING THE FINAL VERSIONS OF THE TWO BOARDS

I believed I had all the components on hand in order to assemble two final versions of the two PCBs, one set for the Vintage Computer Federation InfoAge museum's 1130 and one for the System Source Museum's 1130 I had previously restored. 

I had almost completely built the boards but discovered I was missing a couple of screw terminal parts. A four wire block is used on the 2310 Interface Board, but one of the two boards is missing the block. Both of the Power Distribution Boards are missing 10 wire blocks. I expect a shipment from Digikey with the 10 wire blocks by Monday. I had to put in an order for the 4 wire block, as I clearly messed up. 

A BIT OF WORK LEFT TO COMPLETE ON THE BOARDS

In addition to the screw terminal blocks, I have to insert 24 gold plated pins into one of the 2310 Interface Boards - the cable from the IBM 1130 controller logic plugs into these pins. Then, I have to solder in the wire harness whose end plugs into the 13SD internal disk drive of the 1130. I ran out of time today to finish this work up - plus I am short the terminal blocks. 

FINISHING UP PYTHON UTILITY PROGRAMS FOR USERS OF V2315CF

I wrote some short programs under Python that deal with the virtual cartridge image files. The V2315CF format for a cartridge image has a header which includes a cartridge identifier and a text description. IBM 1130 software uses a cartridge identifier, consisting of four hex digits, which can be any value between 0x0001 and 0x7FFF. 

Program convert1130.py will take a disk image in the format used with the IBM 1130 simulators, requests a cartridge identifier and description from the user and produces a new file in the V2315CF format. 

Program convert2315.py opens a disk image from the V2315CF and produces a disk file in the format to be used by the IBM 1130 simulators. It lists the header information on the input file while doing the conversion. 

Program listcartridges.py is pointed at a folder on a PC. It will look at all files in that folder that are in the V2315CF file format, listing the file name, cartridge identifier and description for each valid file. 

Program showsector.py will open a V2315CF disk image file then ask the user for the cylinder, head and sector that they want to display. The program lists the 321 hex words of the sector.