Found a solution to building the code for the PICO processor - Google Colab

BATTLING VARIOUS BRICK WALLS WITH VISUAL CODE ON WINDOWS

I put in too many hours trying to figure out why I couldn't simply build the executable using the same files that had worked before on the Raspberry Pi OS. I kept getting complaints about build.ninja files, errors with CMake and other chases through a sea of barely helpful web hits and truly not useful documentation from RPi. 

As is often the case, the documentation works perfectly to build stupid simple programs to blink an LED or display Hello World, but doesn't cover all the details for a complex program with multiple source files, included libraries and the like. 

RASPBERRY PI ENVIRONMENT STOPPED WORKING FOR PICO BUILD

I had originally set up the Raspbian Linux on a RPi 5 to build PICO executables, using the documentation from RPi. This had worked very well indeed. However, this RPi was modified extensively for the Space Force Museum display project and issuing 'make' no longer produced the proper results. I needed to keep the display project version of the Pi around so I couldn't change it too significantly. 

FOUND SOME POINTERS TO USING GOOGLE COLAB TO INSTALL THE PI PICO TOOLS

Pete Warden produced a YouTube video about using Google's Colab and a link to fire up Colab and load a Jupityr notebook page to use it for PICO code production. This is the link if you are interested - Link to notebook page to run 

The page is set up to load the various Raspberry Pi PICO code examples and to compile the simple blink program, but it is easy to upload your source code and then issue the make command for your own project  - as I did. 

Firing up a colab gave me a running Linux image on my web browser. I could then pull down the tool chain for the Raspberry Pi PICO build system from github and install everything in the online image. I uploaded my source and related files that would not compile on Windows VS Code or on the modified Rasbian system. They built perfectly, producing the object files I needed to load onto the PICO processor and resume my testing. 

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

STILL INVESTIGATING FAILURE TO STAY SYNCED DURING SEEK OPERATIONS

During my testing of the Virtual 2315 Cartridge Facility (V2315CF) I discovered errors in operation when running the disk function diagnostic (309) while operating in real mode. That is when the 2310 (13SD) internal disk drive in the IBM 1130 is spinning a physical cartridge to provide some of the signals for operation while the V2315CF provides the read and write data streams from a virtual 2315 cartridge. 

The issue I experienced was mismatch between the cylinder that the software expected the disk arm to have reached and the data being read. Each sector on a 2315 disk cartridge holds up to 321 words, with the first word traditionally holding the relative sector number. Each cylinder has eight sectors, thus a cartridge with 203 cylinders holds relative sectors 0 to 1623. The software read the first word of a sector and found that it was NOT for the cylinder expected.

I set up some direct instructions on the 1130 to seek specific amounts, as well as instructions to read one word of a sector and to check the status of the disk drive. I used that to try various movements of the disk arm. On the IBM 1130, a seek (arm movement) moves a relative number of cylinders and a direction, either forward to higher cylinders or reverse back towards 0. 

I found that the data returned by the read would sometimes match where I had asked to move the arm and sometimes not match. The disk drive provides a signal, Home, that indicate that the arm is at cylinder 0. When it is at 0, reverse movements are not attempted. However, if the V2315CF is at some higher cylinder, there is no way to back up because reverse seeks won't take place. 

One example was a long seek, from the Home cylinder moving 202 forward, then moving 201 backwards. That should leave the arm at cylinder 1, with Home not turned on, and the relative sector number of the sector read would be 8. However, the Home switch was on indicating that the disk drive movement wasn't correct and the data read was off by multiple cylinders. 

I made changes to force the cylinder used by V2315CF to zero if the Home switch of the drive is on, but that doesn't keep the V2315CF and 2310 in sync for other movements. I also made changes to track the interlocked signals between the 2310 and the IBM 1130 disk controller logic, but I still experienced mismatches. 

REPORTING CURRENT CYLINDER ON DEBUG OUTPUT OF V2315CF

The V2315CF sends debug information out on a USB serial link, which I modified so that periodically it reports the current cylinder that it believes the arm has reached. That will help me compare what my instructions executed on the IBM 1130 produce in terms of V2315CF cylinder location. This required a new version of the PICO software. See my prior post - the toolchain is on strike so this is pending.

WATCHING THE 2310 ACTUATOR POSITION DIRECTLY

With the top cover removed from the 2310 disk drive, I can view the scale on the side of the disk actuator which points to the current cylinder location of the arm. That will help me compare what the instructions executed on the 1130 intended with the achieved location of the arm. I need to know what is misbehaving - 2310, 1130 disk controller logic, V2315CF or some combination - before I can formulate a correction plan. 

RESULTS OF THE OBSERVED MOVEMENTS VERSUS MY INTENTIONS

The actual movement of the disk arm exactly matched the positions I intended. Given the 2310 and the IBM 1130 were in sync, I did a few more tweaks to the FPGA logic for the V2315CF. I finally got code that seemed to always stay in sync and be correct. I tried many variations of seeks followed by reads which were all correct. 

I hand entered a program to repeatedly seek in and out by a configured number of cylinders, letting the disk move the arm as fast as it could back and forth. This seemed to also stay in sync with the V2315CF. This raised my hopes that the problems were solved.

I LOADED THE 309 DIAGNOSTIC AND RAN IT AGAIN - STILL ISSUES

In spite of the correct operation for all the seek patterns I threw at the system, the diagnostic still failed the seek testing. The diagnostic does a seek from what it records as its current position to a target cylinder, then reads a sector from that location to check the relative sector number in word 1. 

The first error reported that in an attempt to seek from cylinder 0 to cylinder 199, the sector read proved the arm was at cylinder 196. The code then kept trying to get to 199, with a succession of failures. From 196, where it believed it was to 199, but the sector showed it reached 200. From 200 back one cylinder to 199 but the sector read showed it was at 198. From 198 up one cylinder to get to 199 but the sector proved it was at 200. 

I am particularly confused by the pattern that occurs after the first seek comes up short. Once it is within one cylinder and overshooting, the V2315CF would have to be doing something really bizarre to act that way. There is a signal line 10-20-mil that controls whether the drive does a single or a double step for each seek. The 1130 controller logic will attempt a 10 mil step if the count to move is odd, followed by 20 mil steps until the total movement count is achieved. 

With the one cylinder movements, the only seek will be a 10 mil step, yet the V2315CF seems to be seeing these as 20 mil steps. The initial long seek seems to be counted as an even number of steps, yet the program should have requested 199 steps thus generating an initial 10 mil step followed by 99 steps of 20 mil. For it to believe it got to 196 means it missed one 10 mil and one 20 mil step entirely but saw 98 correctly. 

The diagnostic 309 works correctly on an IBM 1130 simulator thus it is unlikely that the code is incorrect when running on the real machine. I am assuming that the 2310 disk is going to the intended cylinder properly, but I can't verify it while the diagnostic is trying to move the arm to 199 because the action is too quick for me to spot. 

New Power Distribution Board built; battles with toolchains to build Pico code

NEW PCBS ARRIVED AND PARTS INSTALLED

The latest design of the Virtual 2315 Cartridge Facility's Power Distribution Board is now ready to use. The PCBs arrived yesterday and I built two of them today. This board handles the routing of power from battery, IBM 1130 main power supply, ride-through time delay relay, battery charger/maintainer out to the power supply board for the V2315CF. 

It also provides for detection of loss of 1130 power, triggering the V2315CF to store the contents of a virtual cartridge back on the microSD card media. This preserves any data written to a virtual cartridge whenever an orderly unload is not completed before power is lot. 

RASPBERRY PI PICO TOOLCHAIN CONTINUES TO CAUSE NEEDLESS PAIN AND DELAY

The V2315CF main unit has an FPGA and a Raspberry Pi Pico which cooperate to provide the functionality. I use a couple of toolchains for the FPGA, Vivado and IceCube2, but need a way to compile the C code for the Pico. Putatively the straightforward way to compile the code is to use Visual Studio Code with some extensions provided by the Raspberry Pi people. 

I have slammed my head, figuratively, into a wall trying to get this Visual Studio route to work for me. Since I was developing another project using Raspberry Pi 5 units, which run under Debian Linux, I was able to use an alternate process to compile the code under Raspbian (Debian for Pi). 

Once I completed the other project, I moved the Raspberry Pi 5 unit to my workshop. The design I created on the Pi 5 included a locked down networking environment to work only at the Museum where the units are installed. This means that the unit does not easily connect to the Internet, plus I don't have internet access at the workshop. I can use my iPhone to create a wifi network in the shop, but the Pi still would need to have all its networking hardcoded configurations removed to make use of the connection. 

All I wanted to do was to compile changes to the Pico code, using the Pi 5 which had done this successfully for weeks before. However, suddenly the toolchain decided it needed a new version of a bit of code (Picotool) and attempted in vain to pull it down from Github. I can't get it to compile any more because it is obsessed with this sudden need to update the tool. 

Whether I fight my way to success with Windows and Visual Studio Code, or I fight my way to success unraveling all the networking configuration changes of the Pi 5, it will mean wasted time and annoyance. Toolchains - the bane of my existence. Imagine if a screwdriver or a hammer were to suddenly refuse to work. Documentation, guides and how-tos often fail to help because the toolchain code in question is frequently morphing, changing from the version used when writing the guides. 

Not a huge headache, but more inefficiency and waste of my time that could have been invested in developing new projects or refining existing ones. 

First of two new gears for 2501 card reader arrived

RESTORING 2501 CARD READER FOR VCF - INFOAGE MUSEUM

The Vintage Computer Federation sent a 2501 card reader for restoration. It attaches to the IBM 1130 system I recently restored for them, in addition to the 1132 printer that I am working on. The intent of the restoration is for them to have a fully working system they can demonstrate at the museum. 

The most significant issue I discovered on initial inspection was the disintegration of two gears inside the machine - a failure mode seen by other museums owning these readers. These two gears were constructed of plastic attached to a metal disk but the material degraded to become so brittle that it crumbles to the touch some sixty years after manufacture. 

I had replacement gears 3D printed by an outside service (CraftCloud), using automotive part grade materials and printing methods. The first of the two gears arrived and I inspected it. Oddly, the part did not match the STL file I sent in regards to the height nor the recessed area that would fit around the aluminum disk to which it attaches.

The part I received is symmetric - no recess on either side - and not the full 12mm height of the STL file. 

CraftCloud is a broker that connects requests for printing with various providers who do the actual printing, so I don't believe this is representative of all CraftCloud work, just the particular printing service. The other gear, which I am still waiting to receive, was manufactured by a different provider; I expect it to fully match the design file I sent, unlike the first gear. 

I was able to press the gear on the aluminum disk as you can see above. After I clean up the disk and glue it on, it will turn on the shaft. It should overlap the lip of the disk rather than sitting fully on one side, but after a test fit I believe I can work with this gear as it is.

The test fit above shows how the gear plus disk would fit. I turned the mechanism and found that it worked properly. This gear turns an eccentric cam which moves a 'joggle' plate side to side inside the output card stacker. 

I will put a washer between the aluminum disk and the hub it attaches to, moving the gear outward just enough to fully match the metal gear driving the plastic one. I am cautiously optimistic that this will restore the output stacker operation properly. 

The other gear drives the picker knife that selects one card at the bottom of the input hopper and slides it into the machine towards the first card station. That gear will have more force applied to it and must fit perfectly on the hub that spins it. A version of the design was made by a museum and appears to work properly, although they are still in the midst of their 2501 restoration. 

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.