Monday, September 14, 2026

Final wiring of Virtual 2315 Cartridge Facility into the VCF - Infoage Museum IBM 1130

POWER FAIL PROTECTION FOR V2315CF INSTALLED

At the heart of the Virtual 2315 Cartridge Facility (V2315CF) is RAM that holds the entire contents of a 2315 disk cartridge. The persistent home for each cartridge image is on a microSD card inside the mini cartridge, but it is read into RAM when loaded so that the contents can be read and updated as IBM 1130 programs issue read, write and seek commands. After powering down the disk drive, the unload switch on the V2315CF triggers it to write the contents back to the mini cartridge thus the changes are persistent.

If system power were to abruptly fail, any changes that were made to the cartridge image in RAM will be lost since the user is unlikely to hit the Unload switch in time to have it fully written. In fact, it could produce a corrupted version, rending the mini cartridge contents lost. To avoid that risk, I designed a way to provide backup power for enough time to write the contents of RAM written back to the microSD card. We can't depend upon the operator to recognize the issue and flip the switch to Unload, so this process is automated.

I have dual power sources attached to the V2315CF main unit, one of which is a 12V motorcycle battery. The connections run through the Power Distribution Unit (PDU) PCB. A timer module is triggered by the falling edge of the 12V system power, which switches  the V231CF main unit to the battery for 45 seconds before shutting off. That is plenty of time to complete an unload of the RAM contents to the microSD card. 

A sensing circuit on the PDU pulls a signal wire down to ground at all times when the system 12V supply is on. When the power drops out, the signal is pulled up by the input pin on the PICO processor thus the code can detect the failure as soon as power drops. This does an emergency unload of the RAM back to the mini cartridge. The front panel of the V2315CF shows the unloading of the cartridge image back onto the mini cartridge. 

The final element of this power protection is a means to keep the motorcycle battery charged so that it is ready to support an emergency unload. A smart charger manages the state of the battery, doing trickle charges to keep it at the proper state of charge. That smart charger is plugged into a utility socket on the side of the 1130, inside the right side cover. This outlet is always powered, even when the 1130 system is turned off, as long as the system main power plug is connected to building power. The trickle charger does not impact the use of the battery during an unplanned power outage. 

The 1130 handling of power failures is quite compatible with this design. If the input power drops or the main power switch is flipped off, the main power rails sag rather rapidly. A sensing ciruit in the system detects this and opens a relay to disconnect the 12V and 48V supplies from the rest of the equipment. All of the bulk capacitors for the system's 12V supply are on the other side of the relay from the loads, so the power disappears quite crisply. 

There is buffering in the power supply module that converts 12V down to 5V for the V2315CF, enough to allow it to continue working while the time delay relay quickly connects the battery to the power supply module. The relay stays energized for about 45 seconds once it trips, then reconnects the V2315CF to the 1130 12V supply which is unenergized. The V2315CF turns off very soon after this. 

PERMANENTLY WIRED ALL THE PARTS OF THE V2315CF INSIDE THE 1130 SYSTEM

I placed the battery inside the 1130 at the base and secured it. I completed wiring the power supply module, timer and trickle charger together along with power down to the 2310 Interface Board. I have tested that this system works as intended thus it is time to make it permanent. I used 18ga stranded wire to make all the connections as neat as possible. 

I had worked out a way to wire everything together that only required two junctions to be made of wires; all the rest were interconnected on the power distribution board. The Power Distribution Board is designed to help with the interconnection of all these elements - 1130, battery, charger, timer, failure detection signal, 2310 Interface Board, and the V2315CF power supply module. I re-used the PCB for the power distribution board from an earlier version, but without the diodes installed. Instead, two wires tied together three holes to make the board fit the current design.

A short extension cord with a flat plug is connected to the IBM 1130 utility outlet and has the trickle charger inserted into its other end. All of the boards and components other than the 2310 Interface Board, battery and extension cord will sit inside the plexiglass enclosure that is mounted on top of the internal 2310 disk drive inside the IBM 1130. At the current time, I have not completed the enclosure so they sit atop the disk drive. 



TIGHT FIT IN FPGA REQUIRES BELT TIGHTENING OF CODE

The Lattice ICE40HX1X FPGA chip in the V2315CF main unit is limited in the capacity it provides for logic elements. Often when I make a seemingly small change in the Verilog code, during the routing and placement phases of the IceCube2 toolchain, I will get a message that the design needs more Programmable Logic Blocks (PLB) - a mix of lookup tables, flipflops and related elements. 

The chip provides 160 PLBs but recently I saw it request 167. If I work to remove some code in the FPGA that isn't strictly necessary, or recode some function in a way that needs fewer flipflops or gates, I can get it to fit. Often, it will initially claim that it needs 163 but is able to cram everything into the 160. It appears 167 is just too far over the limit for the toolchain to find a way to squeeze into 160.

This did slow me down in doing the write functional testing recently. I find that I suddenly blossom the requirements so that I can't generate the bitstream to load into the FPGA, when I whip up what should be a trivial change, such as routing a signal to an external pin or blocking the logic from considering an ECC (Error Checking Code) error to be a fatal disk failure. This just adds time and a touch of frustration to the debugging and resolution activities. 

No comments:

Post a Comment