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. 

Testing Real mode for Virtual 2315 Cartridge Facility - part 2 - Success

KEY TO CONTINUED TESTING IN REAL MODE IS TO WIRE UP UNLOCK SIGNAL

In real mode, the cartridge can't be loaded until the disk Unlock lamp is lit (on the 1130 console as well as the UNLK lamp on the Virtual 2315 Cartridge Facility (V2315CF). This is done by a sense circuit on the 2310 Interface Board that provides a logic high to the main unit of the V2315CF when the Unlock wire from the internal disk drive is pulled to ground by the drive electronics. This would normally be directly wired to the Unlock lamp on the 1130 console that is attached to +48V on its other side. 

When the disk drive turns off Unlock, it releases the line which would then jump up to 48V. The circuit on the 2310 Interface Board senses that voltage and grounds the output line to logic low which causes the V2315CF UNLK lamp to turn off and the unit to believe the disk drive is now spinning (locked). 

In the original IBM design, the unlock wire from the drive is connected to the lamp on the console. This works well for the real (normal) mode of the V2315CF, but when we are running in virtual mode the disk drive is not used at all. It therefore does not turn off the Unlock lamp. 

The 2310 Interface Board has a relay that connects the drive unlock wire to the Unlock lamp for real mode, but reroutes the lamp to a MOSFET on the board for virtual mode. The logic in the V2315CF can therefore turn the console Unlock lamp on and off based on simulating the disk drive. 

I am still waiting for the version of the 2310 Interface Board PCB that houses the relay and MOSFET, so I was not yet controlling the 1130 console Unlock lamp in the scheme above. I did cut the wires between the drive and the lamp, so that the circuit will be controlled by the relay and MOSFET. 

What I hadn't done was to wire the unlock wire from the disk drive to the sense circuit on the 2310 Interface Board, giving the V2315CF notification of when the lamp is logically lit or extinguished. This becomes important for controlling the loading a cartridge and making the drive ready for access. 

TESTING AGAIN

After ensuring the wiring was corrected for the Unlock lamp, that the power supply sense wire to the V2315CF was jumpered to ground, and that we had a new undamaged PICO installed, I restarted my testing of real mode disk operations. I loaded a virtual cartridge and flipped on the motor switch to the internal disk drive on the IBM 1130.  Prior to the drive readying itself, the V2315CF showed the PWR and RO lamps after I toggled the Read Only switch. 

The drive came up to speed and the File Ready lamp illuminated. The V2315CF was ready to emulate a disk drive in its hybrid mode where the physical disk rotates and its arm seeks in and out in concert with our emulated drive. All data flows from and to the 2315 cartridge image file on microSD card.

CHECKING SENSE BITS BEFORE DRIVE GOES READY

The drive should show bit 2 (not ready) and bit 4 (home cylinder) plus the bottom two bits reflect the next sector to arrive under the heads. That number will be changing every 10 milliseconds as the platter rotates in the drive. 

You can see the first XIO Sense DSW returned sector 3 and the second time I did it, the sector coming up was 1. The drive continued to be not ready since the 90 second timer in the disk drive hadn't elapsed. That timer allows the disk platter to stabilize its temperature and for any dust in the drive to be blown out before the drive attempts to load the heads down on the surface of the disk platter. 

SENSE BIT TESTING WHEN DRIVE IS READY

Once the File Ready lamp turned on, another Sense DSW shows the drive with only the Home bit turned on, plus the bottom two bits indicating the sector approaching the heads at the instant of XIO execution. The RDY lamp on the V2315CF was illuminated as well as the green File Ready lamp on the IBM 1130 console. 

 During the course of my testing, we saw changes to the sense bits and validated their correctness. When a disk command was issued by the IBM 1130 - seek, read or write - at the end of the operation the disk controller turns on the Operation Complete bit (bit 1) and raises a request for an interrupt on level 2. 

Interrupt level 2 was entered

In order to reset the Operation Complete bit, we have to have the reset bit of the Sense DSW set to 1. Thus, our first Sense DSW after we enter the interrupt handler will see bit 1 turned on but it will be off for any subsequent sense. With bit 1 turned off, when we exit the interrupt handler we are back in normal processing mode. 

Operation Complete (bit 1) and not Home

Interrupt levels are exited by a specific kind of branch command, one with bit 9 turned on in the first instruction word. This is called a BOSC (Branch Out) variant of the BSC (Branch or Skip on Condition) instruction. Once that was executed, a sense DSW shows the normal bit bits for next sector and shows Home only if we are at cylinder zero.

The Home bit (bit 4) will turn on only while the arm at at cylinder 0, otherwise the controller doesn't know exactly where the arm is. The Disk Not Ready bit 2 will come on when the File Ready lamp is off, otherwise it should not appear. The Disk Busy bit 3 turns on while a disk command is being executed and turns off at the completion. Thus, if we did a maximum length seek which takes over 1.5 seconds, bit 3 should be on to a Sense DSW executed in the interval. 

SEEK TESTING

I repeated the tests I performed in virtual mode. First a forward seek of 3 cylinders, which should leave the drive at cylinder 3 with the Home bit turned off. A set of three reverse seeks of 1 cylinder each should result in the Home bit only flipping on with the last seek. While the seeks are done, I should hear the 'grunt' of the physical drive moving the real disk arm and seek the Seek lamp on the V2315CF light briefly. 

DRIVE NOT PERFORMING SEEKS WHEN THE V2315CF PASSES ALONG A REQUEST

However, no SEEK lamp and no sound from the drive. When I did a read sector with the arm moved to a cylinder away from home, the contents of the sector matched the intended location. The issue was that my disk drive was not performing the seek, only the emulator. 

In the 13SD disk drive, if the cable to the CPU is disconnected, the drive goes into a CE (Customer Engineer) mode, where seeks are done by switches on the rear of the drive. The cable is shorting pin D07 to ground to indicate that we are NOT in CE mode. My interface board did not do this. 

CORRECTED DEFECT WITH A JUMPER ON 2310 INTERFACE BOARD

I soldered in a jumper wire between pin D07 going to the 13SD drive and ground, after which the drive recognized that it should respond to CPU requests for activity. When I did some seek testing after this correction, I could hear the drive grunt and the locations it reached were in sync with the commands issued. 

FINISHING SEEK TESTING

The next test was a move of the maximum 202 cylinders, which should cause the drive to do 101 steps of 20 mils, each lasting 15 milliseconds, placing the arm at the far extreme cylinder. The Seek lamp should be on for the duration of the entire move. a bit less than 2 seconds, and the debug console of the V2315CF should confirm the final position correctly. That worked properly. 

I then moved in reverse 201 cylinders. This causes the disk to do 100 steps of 20mils and a final step of 10 mils. The Home bit was off and the debug console showed we were back to cylinder 1. Another single cylinder reverse seek did turn on Home and got the real arm all the way to 0. 

Home bit back on at end of Seek

A few random seeks get done to see that the positioning, duration and reported final cylinder are consistent with what I requested. That wrapped up the seek verification. 

SECTOR READ TESTING

After getting the arm back to cylinder 0, I performed an XIO type Initiate Read. The buffer has its first word set to the word count 321. The read command specifies head 0 and sector 0. I verified that the contents put into the buffer matched what was on the virtual cartridge image and what I got during the virtual mode testing. Again, the status is bit 1 (operation complete) plus Home (bit 4) since that was our location. 

I repeated this for head 1, sector 0 of the Home cylinder, comparing the data as before. When this checked out properly, it was time to read a known sector. I performed a seek of 10 cylinders then did a sector read of head 1 sector 2. The contents are known to me and I compared what was in the buffer to validate correct reading. 

SECTOR WRITE TESTING

Leaving the arm at cylinder 10, I prepared to verify whether I could write changed data back to the emulated drive. I changed a word in the buffer, as I had during virtual mode testing, then issued an XIO Initiate Write for head 1, sector 2. That should have updated the SDRAM in the V2315CF box with the changed word, all other words of the cartridge image unchanged. 

To see if this was true, I cleared out part of the buffer and issued an XIO Initiate Read of head 1 sector 2. The data that was returned was indeed the known sector along with my modified word. Real mode is now working as well as virtual mode. 

TESTING BEHAVIOR OF V2315CF AT END OF DISK SESSION

I flipped the Load/Unload switch on the V2315CF to Unload, but it did not respond since the real drive was still active with File Ready. 

However, as soon as I flipped off the drive motor switch on the 13SD drive, the virtual cartridge unloaded and the unit waited while the physical 2315 cartridge in the drive spun down to rest. 

When the platter was no longer rotating, the disk drive unlocked the handle to allow an operator to remove the physical 2315 cartridge. This also lit the UNLCK lamp on the V2315CF and returned it to its idle state waiting for a virtual cartridge to be loaded and the real drive turned back on. 

WILL RUN DISK DRIVE DIAGNOSTICS AGAINST THE V2315CF NEXT

IBM has a disk drive diagnostic that exercises the 13SD (internal) disk drive. I will load that code into core memory and started the program running against the V2315CF in real and then virtual mode. If it passes muster then my emulation is certain to be good enough for use running the IBM 1130 with disk images. 

PREPARING A NUMBER OF VIRTUAL 2315 CARTRIDGES FOR USE WITH THIS MACHINE

Using the IBM 1130 simulator on my laptop, I created a few disk images that would be useful to run with the real 1130. Most of them will require a line printer and a card reader to be operational before anything useful can be done, but we will be prepared for the time they are ready. 

Core memory issue resolved by reseating a card

USING AN OSCILLOSCOPE, I TRACKED THE ERROR TO A MALFUNCTIONING INVERTER

The inhibit line is asserted when we want to write a zero in a bit, since a write cycle will otherwise flip all the bits in the word to a one value. The line for bit 13 was not inhibiting properly, thus when we asked to write a 0 in the bit, we got a 1. The machine intended to write a 0, thus it calculated the parity bits for that value; the incorrect bit resulted in a parity check on the next read of the word.

Specifically, this occurred with bit 13 of words in the first 4K of the 8K core memory, pointing at only a couple of cards that were associated with that symptom. When I checked the inverter I found my error source. I pulled the card and reseated it, after which memory passed with flying colors in all 8K with any bit pattern.

Ordered 3D printed gears to replace disintegrated parts in IBM 2501 card reader

HOPPER AND STACKER GEARS DISINTEGRATED WITH AGE

Two gears inside the IBM 2501 card reader, a part of the Vintage Computing Federation's InfoAge Museum 1130 system, had turned brittle and disintegrated due to the effects of age on the materials IBM chose. 

These gears are plastic rings that mount on metal disks. They power the feed mechanism for the card input hopper and the joggler mechanism for the card output stacker. 

ORDERED STEREOLITHOGRAPHY PRINTING IN TOUGH RESIN

I chose a tough resin material, printed using SLA, which has accuracy to 0.2mm on a part that is around 100mm in diameter. This should be accurate enough and strong enough to turn the mechanisms involved in the 2501. These parts should arrive in early April where I can mount them on the metal disks and test them out in the card reader. 

Discovered a blown out GPIO pin 5 on the two PICO processors due to a test bench error

WHILE INVESTIGATING STARTUP OF V2315CF IN REAL MODE, SPOTTED ISSUE

The debugging log from the Virtual 2315 Cartridge Facility (V2315CF) helped me identify an anomaly. I had added a signal to GPIO pin 5 of the PICO, set it up as an input with a pullup, using it to monitor the 12V power supply coming from the IBM 1130. 

If that pin detects the loss of the 12V supply, it triggers the emulated drive shutting down and a quick rewrite of the contents of RAM back to the microSD card which holds the cartridge contents. It does this to ensure we don't lose the results of work done that writes or alters sectors of the disk, but before the user does an orderly shutdown of the disk. 

For performance reasons the contents of a virtual 2315 cartridge are held in RAM on the main PCB of the V2315CF, delivered to the 1130 during a read and capturing any changes written back by the 1130. The permanent home of the virtual cartridge is a file on a microSD card. When we load a cartridge, the V2315CF reads the microSD card and writes the data to RAM. When we unload after a drive is shut down, the V2315CF reads from RAM and uses it to rewrite the file on microSD card. 

My production version of the design has a circuit on the power distribution board for the V2315CF that senses the 12V incoming from the IBM 1130, pulling down the wire from the V2315CF to ground as long as the 12V is present. It is akin to an open collector gate, it pulls down the wire while the power is good and becomes and open circuit when power fails. The GPIO pin on the PICO has in internal pull up resistor so that the pin registers a 1 as long as the circuit is open, but when the power is good, the pin is pulled down to be read as a 0. 

I didn't have the final version of the power distribution board ready when I began testing, but I wanted to verify my logic to detect when that pin is a 1 and drive the rapid unload of a virtual cartridge. I used a jumper cable to connect that power fail sense wire however I hooked it to the incoming +12V which is NOT correct. The board will pull the sense wire to ground while power is good and release it to bounce up on its own to 3.3V when power fails. My testbench should have jumpered the wire to ground. 

By hooking it to +12V, I blew out the circuitry for GPIO pin 5. That includes the internal pull up resistor and the reading circuits, so it always appears to be at a value of 0. That lets the V2315CF run because it believes that power is good, but the PICO is now partially damaged and the power fail detection won't work.

Raspberry Pi PICO processors are inexpensive and I already had three spares on hand, so I am ready to replace the PICO in the V2315CF once I correctly wire the sense wire to ground in the testbench. 

Corrected the stuck bit problem in the IBM 1130, but have a core memory issue to resolve

DIAGNOSED THE HOT BIT 10 ISSUE ON THE IBM 1130

The problem was that even after a CPU reset, bit 10 in the accumulator register (ACC) and the accumulator extension (EXT) was always on. I prepared a list of signals to watch but I first took a look in the card cage, finding that card J4 which implements bit 10 looked a bit high and loose. 

RESEATED CARD, PROBLEM WENT AWAY

I reseated the SLT card and checked again. The problem was gone. ACC and EXT clear on a push of the Reset button and arithmetic and logic, which use the ACC, now perform correctly. I ran most way through the CPU Diagnostics, successfully, before I ran into an issue with parity check stops. 

PARITY ERROR DUE TO BIT 13 ALWAYS READING AS ON

This appears to an issue localized to the first half of memory, addresses 0 to 4095, where bit 13 is read back as a 1 every time. If it was written as a 0, then parity was calculated based on that. The additional 1 bit causes the error checking to detect the problem and issue a parity stop. 

I will have to look closely at the signals and which address ranges encounter the problem in order to zero in on the areas where the defect must be. The problem may be a failure to write the 0 value into bit 13, or a failure to write it back as 0 after reading it once, or an error that always reads it as 1. 

I am hoping this is not another sense line or addressing line failure within the core stack, as I had to fix a number of them to get the 1130 in shape over the past year. The core stack is a sandwich of core planes plus PCBs on the top and bottom. The bottom PCB just carries traces from edge connectors to central pins that stick through the SLT backplane to connect the signal to the rest of the memory electronics. The top PCB has a matrix of diodes that support driving current through the X and Y axis lines in two directions, one to write a bit value of 1 and the other direction to flip any bit to test for its previous value. 

The problems I had were all on the bottom PCB. Fortunately, no breaks in wires running through the cores or in the core planes, as those would be an order of magnitude harder to repair if it were even feasible. Several of the traces had failed open, all on the PCB itself. I found ways to route wires from the edge connectors out to the electronics on the backplane through alternate unused socket pins.