Thursday, March 20, 2025

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. 

Wednesday, March 19, 2025

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. 

Tuesday, March 18, 2025

Testing Real mode for Virtual 2315 Cartridge Facility - part 1

RESOLUTION OF PRIOR DAY'S TESTING ISSUES

I found a couple of errors, one a hardware issue and the other a design flaw in my Verilog for the FPGA. A pin was bent on the socket that the cable connects into on the 13SD disk drive - it was the pin for File Ready status, coincidentally. My logic that simulates the 90 second spinup of a disk drive for the pure virtual mode was blocking the signals from being passed along to the 1130's disk controller logic when in real mode. 

I loaded new bitstreams into the FPGA and some cleaned up code into the PICO processor, then resumed my testing. I still did not see any sector number changes on the device status word (DSW) on the 1130. The drive remained in Not Ready status. 

ELECTRICAL SIGNALS FROM THE DISK DRIVE ARE CORRECT

I checked the electrical signals from the 13SD internal disk drive into my Virtual 2315 Cartridge Facility (V2315CF) interface board. They were all present and correct. The issue seems to exist in my Verilog code in the FPGA. I will set up for some diagnostic monitoring so that I can track down the issue.

AFTER UNLOADING A VIRTUAL 2315 IMAGE, UNLOCK LAMP BLINKS

The Unlock lamp on the V2315CF monitors the Unlock detection signal from my interface board, which will have a transistor detecting whether Unlock is 48V or 0, the latter representing a lit lamp. However, since the circuitry in that portion of the interface has changed, I didn't have the Unlock wire from the disk drive connected. 

The result was that random noise on the line produced on and off values in the FPGA. Depending on the timing of when the PICO code asked for the Unlock status, it either saw it as off or on, producing an alternation - blinking. The temporary solution is to ground that input to the interface board, while the longer range solution is to wire in the circuits related to Unlock on that board. 

THE HOT BIT IN THE ACCUMULATOR IS AN ADDER ISSUE - TRIED CPU DIAGNOSTICS

I used the core memory loader to install the CPU diagnostic which runs through all the instructions with their variants and edge cases. It quickly flagged an error in that relative branch instructions (MDX) were producing the wrong result. 

The MDX instruction, short format, takes the last eight bits of the instruction word as a signed integer. It adds that to the address in the Instruction Address Register (IAR) which points at the next instruction to fetch and execute from memory. Thus MDX can branch about 128 words on either side of where the MDX instruction sits - IAR plus 0-127 or minus 1-128. 

If the accumulator has a hot bit 10, then the addition of IAR and the signed integer may produce the wrong answer - depending on whether the correct value also has a 1 in bit 10 or not. I will have to diagnose and repair this fault before I can run any code containing relative branches, addition, subtraction, shifting, etc. 

Sunday, March 16, 2025

Continued testing Virtual 2315 Cartridge Facility in real mode, using the IBM 1130 internal disk drive

BELT TENSIONED AND DRIVE NOW SPINNING UP

I discovered a much better access method to reach the motor bracket bolts for tensioning the drive cable. It involves opening the back cover, swinging both logic gates completely out, then crawling into the machine from where the gates normally sit. The adjustment went smoothly and now the drive spins up properly.





I set up again to run the disk tests with the Virtual 2315 Cartridge Facility (V2315CF) in real mode, using the physical disk drive in addition to the virtual cartridge image. The 1130 powered up, the V2315CF loaded the cartridge image, and I flipped on the disk drive power switch to start it spinning. 

SENSE BIT TESTING BEFORE HEADS LOAD

Before the drive was turned on, I performed an XIO (eXecute Input Output) instruction of type Sense DSW to see the status bits for the device. They showed it not ready (bit 2 is on) with the arm at the Home (cylinder 0) position (bit 4 is on). I didn't see the sector count changing, which they should be doing as the drive spins up. 

HEADS LOADED BUT NO FILE READY INDICATOR

When the File Ready lamp turns on, another Sense DSW would show the drive with only the Home bit turned on, plus the bottom two bits would indicate the sector approaching the heads at the instant of XIO execution. The ready lamp never lit. 

When I issued another XIO Sense Device, the drive still showed not ready and at the home cylinder, but also bit 0 was turned on. This is the error status and it has several causes:

  1. During a read or write operation, the error checking bits indicated an error for at least one word
  2. The drive was still doing a read or write sector when the next sector arrived under the head
  3. A write select error occurs when both heads are selected for writing or other electronics failure
  4. The drive set the power unsafe latch usually due to inadequate RPMs but also if power sags

Since we had not attempted either a read or a write, we are left with either electronics failure (3) or the power unsafe latch being set. During my tabletop testing of the drive, I saw this failure which was a consequence of omitting a jumper between 48V and system ground on the back of the disk drive.

WILL MONITOR THE LOGIC SIGNALS COMING FROM THE INTERNAL DISK

I will check the logic state (voltages) for the signals coming from the 13SD internal disk electronics, ensuring that they are reasonable for the state of the drive. I can monitor the sector and index pulses plus test the power unsafe latch condition. I ran out of time today as I had to spend most of the day at the Sands History Center working on the museum display systems. 

INTERRUPTED THE UNLOCK LAMP WIRE IN ORDER TO SUPPORT VIRTUAL MODE

The Unlock lamp is wired to 48V inside the console of the 1130 and the other end is a wire that connects to the disk drive. When the drive is not turning, the unlock solenoid is activated by a circuit pulling one end of it to ground. The same circuit also pulls the wire to the unlock lamp to ground. This causes the lamp to light when the 13SD internal disk drive is not spinning.

For virtual mode, we will not have the motor of the physical drive turning, thus the unlock solenoid will always be at ground. In virtual mode, we want to turn the 1130 console lamp on and off based on whether we are simulating the drive turned off or simulating a spinning drive as a cartridge is loaded. 

To do this, the Virtual 2315 Cartridge Facility (V2315CF) interface board has a relay that is activated by the virtual position of the real/virtual switch on that board. When the relay is not activated, the wire from the physical drive is connected to the console Unlock lamp. When activated, the relay connects the Unlock lamp to an FET on the interface board. The FET is turned on and off by a signal from the V2315CF logic, either grounding the lamp to light it or leaving it floating (off). 



Saturday, March 15, 2025

Starting restoration of an IBM 2501 card reader for VCF 1130 system

STARTING RESTORATION OF THE VCF IBM 2501 CARD READER

The Vintage Computer Federation's InfoAge museum sent down the 2501 card reader and 1132 line printer that will work with their IBM 1130 of which I am currently wrapping up restoration. My first visual inspections suggest that the 1132 will be straightforward, just involving a ton of disassembly, frozen lubricant removal and loosening of all the myriad moving parts. The 2501 has some rust issues but still seemed feasible to be restored.

RUST IN VARIOUS LOCATIONS NEEDS TO BE REMOVED AND ADDRESSED

There was rusting on a few spots where it matters mechanically. Most importantly, there is a cylindrical rod that the output card hopper slides along as cards fill the hopper, but it is rusted and thus the slider barely can move over it. At worst case a replacement cylinder can be built, but I suspect I can knock down the rust and convert it leaving the surface good enough for operation. 

RUBBER BELTS AND OTHER PARTS SEEM IN VERY GOOD SHAPE

This reader uses several rubber drive belts to convert the motor rotation into rotation of various axles that move cards through the reader, motion both side to side and front to back. They appear to be in excellent condition, not worn and with plenty of spring left in the rubber. Other parts and wiring look undisturbed. 

TWO PLASTIC GEARS HAVE DISINTEGRATED

IBM chose to use some type of plastic, perhaps a nylon, for two gears in the machine. The rest are metal or Bakelite. The plastic gears are an outer ring that is fitted onto aluminum disks. The material chosen did not hold up well with age. Apparently key chemicals like plasticizers have evaporated with time, changing the characteristics of the material. 

What I found when I opened the 2501 was many fragments of gear teeth lying inside the machine, with just small arcs still connected to the aluminum disk for the output hopper gear. This gear turns a cam that moves the joggle plate side to side, keeping the cards separated as new cards are ejected from the reader into the hopper. 



A second gear is hooked to the outside of the CB (Circuit Breaker) wheel and drives the rollers that pull a card into the machine from the input hopper. IBM uses the term CB to mean multiple things. In this case, it means three magnetic coils that receive impulses from a permanent magnet glued to one point on the rotating aluminum disk. 

CBs are used by IBM to indicate a rotary position, either closing microswitches or in this case triggering a pulse in a coil. The speed of the 2501, at up to 1000 cards per minute, 16 2/3 rotations per second, dictates that the signals for the three coils (CB1, CB2 and CB3) are very short, in the range of 3-4 milliseconds duration and with on and off time requirements in the range of 100 microseconds. Coils with pulse shaper electronics easily achive these requirements, physical switches not so well. 

The teeth on the gear at the input hopper had turned to dust, rather than fragments, although I suspect that there are some small arcs of the teeth down inside the housing where I can't currently see. 

HELP FROM A MUSEUM IN EUROPE WHO HAVE A 2501 WITH THE SAME ISSUE

Friends at a museum in Europe who have a running 1130 system found the same gear disintegration in their 2501 reader. They created a 3D model for gear replacements and were able to achieve useful results for the input hopper gear using a 3D printer. 

Unfortunately, the output hopper gear has 211 teeth around a circumference of roughly 32 cm. The pitch between teeth is therefore about 1.5 millimeter. The precision of their 3D printer and the material used was not good enough to produce well shaped teeth spaced this closely together. The feature resolution needs to be about.1 mm, I suspect, for this to have a chance of working. 

I will see if I can find a 3D printing service that has a material and printing method that can give me a decent gear to use with the output hopper. The force of the cam moving the joggler plate back and forth won't be very high, but the teeth have to mesh well enough to turn the cam and not bind up.