Physical construction work for IBM 1130 console display panel alternative lighting

Mounting the power supply components

I have four components to the power supply for the panel, three of which can be mounted with a screw onto the posts conveniently provided on the swing-down rear door of the panel enclosure. None of the holes in the components line up well with the posts. The fourth component is a fairly large filter capacitor, a cylinder shape without mounting points of its own.

The classic method to mount the filter capacitor would be a clamp that circles the capacitor and provides screw holes. The cylinder would project upwards from the door, the axis of the cylinder at right angles to the door, way too tall to fit inside the relatively shallow enclosure. Instead I want a mount that places the axis of the cylinder parallel to the rear door, so that the capacitor projects outward only by a bit more than its diameter.

The challenge will be fitting everything between the board and the swing door. There is a bit less than 2" clearance from the back of the PCB to the swing door, but the posts and a raised lower ridge on the door eat into the space by up to 5/8".

Assuming that I can fit the capacitor between posts, a clamp can be attached to one of the posts to secure it in place. These are 1 3/4" diameter capacitors, which can be mounted with a bracket that I just ordered from Digikey. These should just fit. In a few days I will have the hardware here and can mount the capacitors onto their final position on the swing door.

Filter capacitors used for power supply

The two buck converters needed adapter plates since neither of them have mounting holes that directly match the posts on the rear swinging door of the 1130 enclosure. I am having the adapters laser cut at Ponoko out of 1/16" plastic.

Interfacing with the computer wiring system involves connection to the 7.5VAC main lighting power, ground and the 155 discrete signals for 154 lights and the lamp test control. There is a terminal strip on the left side of the enclosure (viewed from the front) which provides the 7.5V on the top two lugs, common ground on the middle two lugs, and lamp test signal on the bottom two lugs.

The way that IBM designed the 1130 computer, they have a 7.5V AC transformer wired with one side tied to ground, so that the other side swings to both positive and negative excursions during every cycle. This does present problems with my initial power supply design, which was going to use a full wave bridge rectifier to give me DC for the buck converter boards. However, if one side of the input is tied to the negative output, the full wave design won't work properly.

AC feed tying one side of transformer to ground

Supply connections inside light panel enclosure

Instead, I must use it as a single diode of the component to rectify, producing only positive half cycles. This requires a filter capacitor to smooth out the more substantial ripple I will be experiencing.  I selected 9000 uf caps for the output of the rectifier diode and again for the output of the 5V buck converter.

To attach properly to the barrier strip inside the 1130 enclosure that provides the 7.5VAC, ground and lamp test signals, I have to create wires with lug ends to fit on the strip. My wire has to be bigger than 20 gauge (or two somewhat smaller wires, each attached to a barrier strip terminal) to properly carry the max current. I chose 18 gauge stranded wire.

The lamp test wire can be much thinner, since I am simply detecting the voltage level with a PCA9505 multiplexer chip. I do need to put a push-on connector for the lamp test to fit it over the pin on my PCB for this connection.

The power connections are flat solder plates thus only one end of the ground wire needs a lug end. The other solder plates run to the buck converter boards supplying 3.3 and 5 VDC. A lug plate is needed on the wire to provide the AC to the rectifier diode. The two filter capacitors need lugs on one end of the wires connecting them to the rectifier and the buck board, otherwise connections are soldered.

Since I must wait for the adapter plates to mount the two buck converter boards, I figured I could complete everything else and wait for the final physical assembly when they arrive next week. I installed the rectifier and two capacitors along the swinging rear door, but left the two converter boards dangling so they can be screwed onto the plates later.

Adding insulation and support material to the rear of the panel

The honeycomb behind the front panel is actually a number of blocks that are glued together and then anchored to the face plate by two threaded studs rising along the mid-line of the face plate. A metal plate extends across the mid-line and is held in place with two screws.

The PCB has solder mask and no components along the line where it will sit atop the metal plate and screws, but with time the screw heads may dig into the solder mask and eventually short. Further, since the PCB is planar but the screw heads make elevated points on the rear of the honeycomb, the PCB wobbles and won't sit flat.

My solution is to overlay the metal plate and screws with a long narrow foam strip. Small pieces of the foam will be applied at various points on the rear of the honeycomb to cumulatively provide a planar support onto which the PCB can rest.

Padding/insulation between honeycomb face and PCB face

Minor repairs to the IBM panel before installation

The IBM panel is a plastic front with honeycomb segments glued to its rear. Two plastic blocks are glued to the sides of the honeycomb outside edges. These are screwed onto vertical metal brackets to hold the light panel in place inside the enclosure. Both of the plastic blocks have broken free from the honeycombs due to deterioration of the glue used for manufacturing at IBM.

Edges of honeycomb where plastic blocks detached due to adhesive failure

 The bracket is attached to the top and bottom of the enclosure and has two screw holes facing sideways into the plastic blocks. However, getting a screwdriver in the enclosure to install or remove those two screws is quite difficult.

Plastic block attached to its bracket

The only effective method is removing the two end switch panels to get access. These metal plates have threaded studs on the rear that fit into an enclosure hole and are tightened with a nut you can reach from the rear. I have to remove the 4 nuts and swing the two plates out of the way, allowing me to put a stubby screwdriver in from the front and access the screw holes for the plastic blocks.

Re-gluing the plastic blocks to the honeycomb sides using epoxy

After removing both plastic blocks, I used epoxy to glue them onto the honeycomb sides. Once this was firmly set, and the standoff insulation applied to the honeycomb rear faces, it was time to reinstall the honeycomb.

Light profile tweaking for IBM 1130 console replacement display

Improving the incandescent simulation

I chose to wire up one of the incandescent lamps from the 1130 and subject it to testing, using both direct visual comparison and a light sensor to record the brightness over time. I picked up a TSL2591 light sensor module from Adafruit, which operates over an I2C link to an Arduino. I configured it to record the intensity of the light as ran the lamp through its paces.

1. Turn the lamp full on from a cold condition, recording the brightness curve
2. Turn the lamp off from a fully on condition, recording the brightness curve
3. Iterate with 1 to 60 half-cycles of power out of each second, at a steady state
4. for each state above, record the brightness
5. For each of the states, adjust the color of a Neopixel until they subjectively match
6. (optional) Test that the incandescent performs the same whether the on half-waves are contiguous or spaced throughout the second; verify that the only factor is number of on half-waves

The incandescent lamps are installed onto long narrow PCBs that host the SCRs used with the IBM lighting circuit. They are all soldered to a common wiring harness, thus I will be powering all 154 lamp positions in this test, but only energizing one of them.

The boards receive common voltages of .ground reference, 7.5VAC and lamp test state. The lamp test state biases the gate of the SCR thru an internal 6.8K resistor in each SCR package. The logic signal that controls the gate is fed through a 6.2K resistor external to the lighting PCB.

This set of resistors forms a voltage divider delivering 52.4% of the signal voltage to the gate of the SCR. It is built that way because when Lamp Test is desired, the voltage on that rail is +3V, thus even with a logic signal that is off (0V), the resulting voltage divider delivers about 48% of the 3V on level.

Thus, with the Lamp Test rail held at ground, all logic signals are either 0V or 1.572V at the gate due to the voltage divider action, but when the Lamp Test rail is pulled up to 3V, all gates are either at 1.44V or 3V depending on the logic signal state. This ensures that all bulbs fire when LT is on.

I only need to connect the 7.5VAC wall-wart transformer to the 7.5V and ground reference terminals of the lamp boards, while tying the LT rail to ground. Then, if I apply a voltage level above about 2V to the input pin of any SCR, it should fire the attached bulb. My Arduino provides the 'logic signal' to control the SCR.

My test circuit to drive IBM incandescent lamp boards

My first runs were with the naked eye (and video of the bulb). These do allow me to figure out the bloom and fade time of the bulbs. Capturing video on my iPhone and trying to time it, the speed of the fade is noticeably slower than the time to bloom on. That makes sense, as the filament has to lose heat primarily by radiation in order to cool back down, while turn-on involves the increase in resistance as the bulb turns on. The surge in current causes relatively rapid heating.

I wanted to hook up the sensor board and record the actual brightness curves to get a more accurate view. I quickly discovered that the Adafruit TSL9251 board is far too slow to capture enough slices during the bloom and fade. It appears to take about 100ms, reducing me to a slice each 1/10th second in a process that may be complete in less than a slice for bloom and just over two for fade. Not a big loss at $7 for the board.

The outcome of this testing was intended to produce a table of the brightness and color for all 31 levels, from 0 to 30 half-wave cycles on per second. Further, I had the brightness curves for a full turnon and a full turnoff to compare against the values of the 31 levels.

With the maximum brightness of the LEDs dialed down, so too the current consumption dropped. The Arduino testing, with all positions lit to full on state, drew under 3A total. This is a side effect, although the power supply is capable of driving full white brightness of all LEDs.

At this point I have some design decisions to make. I can cheat a bit since lamps which have a mix of logic states applied during a second might be matched to the average brightness and color of that average value. Thus, for lights that are flickering, I would get a realistic appearance this way. However, this won't work for rapidly brightening or fading lamps, particularly the edge cases of full on to off or full off to on.

I am toying with changes to the algorithm, such as taking dimming steps of the index value 3.5 times slower than brightening steps. This would adjust for the differences in bloom and fade speed of the filament. If I sample the logic states 38 times per second, then I can step up the index value for brightness 7 levels when the logic level is true and step down 2 when the logic level is false. That gives me a full bloom of about .13 seconds and a full fade of about .42 seconds.

The other change I have to make is in the color of each level. I am going to drive the incandescent to roughly 32 steps of brightness from off to on, then use the Arduino to tweak the LED color and brightness to match by eye. This is going to be a bit more complicated test setup, but I should be able to complete this by the end of this week.

more refinements of the replacement console panel lighting for the IBM 1130 - bitstream, PS test, fidelity test

Loading the FPGA bitstream

I had completed the logic design (VHDL code) while on holiday, checking its operation with the simulator, so I was ready to configure the Spartan 7 based board that will drive the console lights. The toolchain provides everything needed to load the board, so it was a relatively quick and easy process.

Power supply testing

My power supply takes the 7.5VAC from the 1130 lighting circuit, rectifies it and, using two buck converters, generates both 5V and 3.3V to power the LEDs, I/O multiplexer chips and the FPGA board. The cumulative draw of 154 LEDs comes to 7.4 A with them all at full brightness during a lamp test; if they were turned on to white instead of yellowish the draw would be more than 9.24 A.

The enclosure on the 1130 that houses the control panel has a swing down door on the back for access. I will mount the power supply elements on that swing down door, making use of several raised posts with screw hole taps that are spread across the rear of the door.

I first set up a test of the power supply components I will be using. I found a wall-wart transformer that outputs 7.5VAC, allowing me to power the big bridge rectifier and the two buck converters that generate the 3.3 and 5.0VDC for my PCBs. The test confirmed that everything was good up to the current limit of the wall-wart, which is far too low to power the fully lit display panel but does permit a limited number of LEDs to be active.

Testing rectifier, buck converters and such driven by a 7.5VAC wall-wart

Next up, I hauled out the scope and monitored the ripple and noise on the DC power, both from the bridge rectifier and from the buck converter boards. While the output of the converters was good, as I expected, I do need to add a filter capacitor on the outputs of the main 5V converter. It will also provide some buffering of power closer to the LEDs that running through the 1130 all the way back down to the 7.5VAC supply.

Mechanical assembly

I had to add an extension that will raise daughter board higher off the rear of the main PCB, This gives me room to fit the signal wires from the 1130 logic onto the pins on the main board underneath. I simply used a set of Arduino shield socket strips to form the extension.

Daughterboard raised with extensions to allow access to signal input pins below it

Establishing the realistic filament characteristics

My first check of the reasonableness of the incandescent behavior simulation was to switch various LEDs on and off using an Arduino program. The effect looked good, in real time, to my eye and memory. The next check was to display all 32 steps from full off to full on, letting me judge the color shift and apparent brightness changes.

Displaying the 32 steps from full off to full on

Finishing the 1130 console display board

Building the main PCB

The board was complete except for mounting the 154 LEDs, but my vacation got in the way a bit. Now that I am back, I began soldering it chains of LEDs. These are installed and soldered over the honeycomb assembly, which ensures that the PCB with the LEDs will fit properly when all done.

I did the first chain, which has 15 LEDs for the IAR register, another 15 for the SAR register, and 8 LEDs for the T clock states T0 through T7. After examining the solder joints under the microscope and testing for shorts or unusual conditions, I was ready to drive these with a simple test program running on the Arduino.

I did see all positions light, but there was some color shifting late in the chain which I attribute to inaccuracies in the timing of the Arduino driving the serial data. The library for the Arduino was made for a faster controller chip than the APA106 used in my bulbs, but in addition the timing requirements of the controller chip are different.

A few bulbs in a row will tolerate the inaccuracies bu these multiply as the chain grows longer. When I adjusted the library parameters to emit at a 400KHz rate, consistent with my chips, the outcome was perfect.

I moved on to solder in the second chain, which implements 16 LEDs for SBR register, 16 LEDs for the AFR register, and 8 LEDs for the X clock states X0 through X7. My test program drove these to validate the correct operation of all the new lights.

The third chain implements 16 LEDs for the ACC register, 16 LEDs for the EXT register and 8 LEDs for the DEBUG lights. Again, using the test program I drove these to confirm the wiring and solder joints. My test program produced one serial output but I jumpered them together to the three chains, so that the lights on all three chains behaved identically. This helped me test out all the bulbs and the behavior.

The last chain was completed and tested. It supports all the miscellaneous lights:

• 5 LEDs for op code
• 5 LEDs for the tag bits
• 3 LEDs for the index register
• 6 LEDs for the interrupt levels
• 6 LEDs for the cycle counter
• 2 LEDs for Carry and Overflow conditions
• 1 LED for the wait state
• 2 LEDs for parity bits 1 and 2
• 3 LEDs for ADD, Add control and Subtract control states
• 3 LEDs for the conditions ZR, TC and AS

Board completed with all LEDs soldered in place

The PCB with the LEDs rests atop the honeycomb, but across the middle of the honeycomb is a metal plate joining the top and bottom halves together, plus two metal screws that attaches the plate to the rest of the console panel. 

Honeycomb structure with metal plate and screws across the midline

PCB with LEDs inserted into honeycomb

I chose to put an insulating layer across the top of the plate and screws. A few other points on the edges of the honeycomb received matching spots of insulation to provide an even surface for the PCB as it is placed against the honeycomb. 

Watch a video of the Arduino test program stepping each chain through all lights then simulating flickering partial illumination - Click here for video

Designing and testing the FPGA logic for the 1130 control panel

Writing VHDL for the FPGA

During my holiday away in the Bahamas and Florida, I wrote all the VHDL code for the FPGA. It consists of eight autonomous sections - four each for reading the state of 1130 logic signals and for driving the four chains of LEDs on the panel.

Coding in the Bahamas

The logic signals are read using PCA9505 chips that have 40 input pins connected to up to 40 of the 1130 logic signals. These are read over an I2C chain, which I implemented using some open source I2C master code and layering on the protocol to address and read from a chip.

As I read the signals, I use the state I just read to adjust the lamp level index. This is an integer running from 0 (fully off lamp) to 31 (fully on). I sample the signals 60 times a second and increment the index when the signal is one, otherwise decrement it. Of course, I never get the value get below 0 or above 31.

The LEDs employ APA106 controller chips inside which implement a single wire serial chain. The protocol is pretty simple - a reset burst of 60 us of logic low level readies the chips, then I send out the stream in GRB order starting from the first and ending with the last LED on the chain.

Each APA106 latches in the 24 bits intended for that LED, 8 bits of brightness each for the Green, Red and Blue color. It strips off the 24 bits and passes along the remaining signal stream to the subsequent chips. Thus, a string of 480 bits will provide the brightness and color to drive 40 LEDs in the chain

By varying the duration of the on and off times of the serial wire, I am modulating either a 1 or a 0 bit value for each of the 480 bit cells above. I can control the timing very precisely to ensure fault-free operation.

I built up logic to generate a sequence of the reset interval then up to 40 LEDs worth of color/brightness, repeating infinitely. As I begin each LED, which represents one of the 1130 logic signals, I use the lamp index produced by the sensing circuit above to select the proper GRB value for the index level.

Thus, if I have calculated a lamp is off, I get all-zeroes, while any lit level gives me the GRB that simulates an incandescent bulb at that brightness.This also simulates the color shift towards red as the lamp is dimmer.

The final two parts of the code are the startup reset controller and the lamp test logic. I hold all the finite state machines in reset for 63 clock cycles, also generating a reset signal that runs out to the four PCA9505 chips that sense the logic state. When the Lamp Test signal is on, I override the selection of color/brightness data to produce a full on white value in all LEDs.

Testing using simulation

Since my FPGA is a Xilinx Spartan 7, I used the Vivado design suite as the tool chain to write and synthesize the VHDL into the bitstream for the FPGA. This suite provides simulation capability, which I used to debug the logic that drives the LED chains. I worked with a single copy of the LED driver logic until it was producing the correct output under the simulator.

Simulating in Florida

Once it passed muster, I replicated the logic for the other three LED chains. I designed the LED chains to match the four PCA9505 chips sensing logic states. I could have chained all the sense chips together on one I2C link and chained all the LEDs together on a single serial line, but chose to break it up into four independent sections because, with an FPGA, hardware is essentially free and this further reduces the chance that anything will operate too slow and cause erratic behavior.

I did take some time off to watch the SpaceX Falcon Heavy launch, ensconced at the nearest viewing site in Kennedy Space Center, just outside the Apollo/Saturn center and across the creek from launch pads 39A and 39B. It was an awesome experience, although I can't throw any shade at the rest of the trip.

building the IBM 1130 console display main PCB

Building main PCB

I had the final corrected board fabricated by AllPCB.com due to their relatively low pricing, good results I had with prior orders, and promised quick turnaround of 3 days to build and 3 days DHL Express shipment.

As I mentioned in the last post, something went wrong as they were cutting up the panel into individual boards such as mine. They started from scratch building the board at the point where it would have been heading out to DHL. That did cost a full three days delay in receipt of the PCB.

All the parts were here, waiting for the board to complete the assembly. In the interim, I wired up the power supply parts to install inside the 1130 console enclosure. The back door of the panel enclosure had a row of threaded standoffs along the width of the box, which were used in some models to hold small boards holding several SCRs.

I will use these to mount three parts of the power supply. The incandescent lamps of the IBM design are fed with 7.5VAC, through an SCR. This only allows conduction on the positive going half cycles, thirty intervals out of sixty in a second. If the signal from the 1130 logic is above 0.8V at the SCR input, it cause it to conduct during that half-cycle.

The filament integrates the power delivered during half-cycles to an average that determines how brightly the filament glows. In addition, the frequency of the light is determined by the average power; more power means hotter tungsten and a shift towards the blue. In practice, this moves the bulb between red-orange and almost yellow.

My first thought was to make use of the 7.5VAC supply, through a full wave rectifier and then a buck converter to produce 5V for the main board and another buck converter to produce 3.3V for the FPGA pin level shifters . This plan fell apart because of a few realities once I did some analysis:

1. 154 lamps, which can each draw about 45ma when fully on with a yellow-white color, draw about 7 amps of current
2. The buck converter I have is capable of delivering only 2A of current
3. I also need power for the FPGA and four multiplexer chips, but that is minor
4. The rectifier is rated at 50A which is sufficient but it yields an overvoltage without a buck converter or other limiter (see point 4 above)

I can still use the rectifier to produce DC since it has plenty of current handling headroom. If I had a higher capacity buck converter I could generate the 5V for the main board, but in any case I can use the other buck converter board to give me 3.3V for the voltage shifter reference.

In the worst case, full on white for all bulbs, the current requirement of the main board would be about 9.5A, 47 watts consumption. I found and bought a good buck converter rated at 12A/100W  which gives me plenty of headroom. I believe it will work well with the output of the rectifier, using a suitable capacitor to smooth the 120Hz pulsating DC.

I set this up on a testbench once the new buck converter arrived, watching and measuring to prove out my approach to powering the new display. First I fed 10.5 VDC from a bench supply and adjusted the buck boards to 5V and 3.3V respectively. That worked great, but there wasn't much doubt.

Later I used a 7.5VAC wall-wart supply to check the quality of the DC both into and out of the buck converters. Using a big electrolytic filter capacitor I selected across the bridge rectifier, I wired the buck boards up to power with AC.

The AC adapter produced about 8.5 or more volts AC. The two buck boards delivered the voltage levels they were set to produce. The scope showed that the inputs and outputs were free of excessive ripple or transients.

The PCBs boards looked great when I inspected them on arrival. Oddly, there were only 3 even though the minimum which I ordered was 5, but better to get 3 that work than be further delayed waiting on five. I can't recommend AllPCB.com due to my experiences with this order. With the parts collected around me, I began to solder up the board.

The first items I soldered on were the pull-up resistors for each of the four I2C based chips, since the SDA and SCL lines must have this to work properly. Next was the set of headers into which the daughter card with FPGA will plug.

Installing the 52 pin PCA9505 chips was the most demanding work due to the very fine pitch of the leads. I started on those first. For each one, after I verified that all leads were firmly soldered and that no visible solder bridges existed, I then did careful continuity tests to the end destinations as well as power and ground.

I hooked up an Arduino to the I2C chain of each chip as they were installed and used a quick and dirty program to show me the results as I set each input pin to high and low values. That verifies that each does work as intended.

I had apparently bad connections to some of the input pins, which I couldn't figure out since there was continuity. I then noticed that in all four cases it was pin 39 of the respective chip, the last pin, that was not detected. Now I suspect that the Arduino library I am using to do the quick and dirty is defective.

I tinned the power leads and tacked on temporary wires for testing purposes. Eventually these will be hooked to the power supply I am building. They must be able to handle 7-9 amperes. The main supply had electrolytic filter capacitors installed to complete the power input.

I had to install 155 individual header pins, as these are the connections for the 154 logic level signals from the 1130 computer plus the lamp test logic level. I had already verified connectivity to the expander chips so this didn't need anything more than a careful inspection by eye.

Board, ready to install the LEDs