Thursday, April 10, 2025

Mystery smoke when testing second V2315CF main unit

TWO UNITS BUILT FOR TO MUSEUM MACHINES

I had constructed a Virtual 2315 Cartridge Facility (V2315CF) for the IBM 1130 I am currently restoring on behalf of the Vintage Computer Federation's InfoAge museum. I had previously restored an 1130 for the System Source Museum which I plan to upgrade with a V2315CF as soon as I finalize the testing.

NAGGING ISSUE WHERE LOGGING IS NOT WORKING

The design of George Wiley's RK-05 Emulator upon which I based the V2315CF included a capability to log read, write and seeks over the debugging serial link. That is, by typing an L into the serial terminal connected to a V2315CF, it should print a line for each seek, read or write performed. It sets up an interrupt handler when the command is processed. 

The FPGA has an output line which has a pulse emitted by my Verilog code whenever I am beginning one of those three actions. This line is connected to an input pin on the PICO whose code sets that pin up for interrupt detection upon any leading edge. This should enter a handler to fetch details on the operation from the FPGA (over the SPI link that bridges the two) and then print a line to the debug console. 

This had been working in earlier iterations of my design, but at some point it stopped working. Among the events which had occurred to the unit was an inadvertent connection of +12V to a Pico input pin, frying the processor, as well as my code adding another input pin to receive a signal when the IBM 1130 power supply drops out. I have replaced the PICO hardware. 

This latter signal triggers my code to drop File Ready on the disk and unload the potentially changed contents from the RAM chip on V2315CF into a file on the microSD card which holds the virtual cartridge image. This should have nothing to do with the logging scheme. However, there may be some subtlety in how the Raspberry Pi PICO software development kit handles the interrupts or input pins that led to the cessation of the logged action print lines.

SWAP OF V2315CF MAIN BOXES

Just in case a damaged component on the V2315CF main unit has caused the connection between FGPA and PICO to not work, blocking the pulse that triggers the interrupt, I removed the box I had been working with and connected the second V2315CF box I had built. These have had power applied many times as I update the FPGA bitstream with design changes.

MAGIC SMOKE RELEASE TO MY SURPRISE

When I powered up the IBM 1130 with the second V2315CF box installed, I saw white smoke puff away from the inside of that box. I immediately powered off the 1130 system and removed the box for inspection. 

At this point I don't understand what caused this to occur. The wiring to the 1130 was unchanged other than plugging the new unit in place of the first one. Looking physically at the unit I see indications that chip U20 was what released the smoke. 

Signal line T2 on the cable is BUS_UNLOCKED_LIGHT_H which should drive the MOSFET that lights the Unlock lamp on the 1130 main console when the V2315CF is in virtual mode. The line on the cable is connected to the gate of the MOSFET below to pull it to ground when the signal is driven by U20. 


As you can see the design is will work since the 2310 Interface Board has this pulled down to ground when not activated, and U20 works by either pulling it to ground or leaving it float. The terminator board has resistors to +5 and to ground, thus this line will float to 3.3V when U20 is not conducting, enough to fire the MOSFET.  In real mode, the MOSFET is bypassed by a relay and the lamp is hooked directly to the signal from the 2310 (13SD) disk drive unlock switch instead of to the MOSFET. 

In any case, I don't see any way this should short out U20 to cause it to fail. I will need to look for solder bridges or other shorts that are exclusive to the second V2315CF main unit and not the first one. That U20 chip did not fail in the first box I had connected as far as I know, although it could have failed silently without smoke I guess. I will have to investigate this, find the cause, fix it and replace at least U20 to restore the second box to functionality. 

When I power it up unattached to the IBM 1130 it does come up with its logo on the OLED screen on the box and appear to be working okay. I know that U20 is shot but that only drives the one signal for the Unlock lamp in virtual mode thus it can be replaced when the part comes while still being tested today. 

No comments:

Post a Comment