Thursday, March 26, 2015

Issue with SAC Interface driver circuits diagnosed, developing the fairly easy resolution


I huddled with other antique computer restorers at CHM yesterday to think through my options to repair the punch feed wheel whose ceramic rim has fractured leaving a missing section of the 'tire'. Materials like hard rubber or plastics are going to be easier to fabricate but with repeated operation they will 'polish' away any gripping features I mill into them. The original wheels have a gritty ceramic, reminiscent of a grinding wheel, because of the challenge of wear over time.

No perfect solution but at least I have some clearer thinking about what sorts of repairs will be suitable and what the requirements are for the repaired part.


I really wish I had card schematics for the SLT cards that drive and receive over the SLT cable - given the debugging situation I face. There is also a manual IBM printed with diagrams and relevant facts, but I only know of one physical copy, on the other coast, and no scanned version. I am not seeing the behavior I expected on the ends of the signal lines, but they are pretty consistent across large numbers of these signals going into the 1131. Either I have the same failure on all of them or my interpolated circuits are way off.

In order to check further, I looked at the resistance on the cable pairs which were to be driven - they were effectively open circuits, which meant they looked like the standard SLT input which has a diode isolating it. When you pull the line to ground, current flows through the diode, changes the biasing of the  transistor in the receiver in the 1131 causing it to switch states. However, unlike the circuits I found for other drivers which had the 1131 pulling the signal up to +3V with a 100 ohm terminating resistor, these do not!

To check out my theory, I found and unhooked six driver lines - interrupt request for levels 2, 3, 4 and 5, plus cycle steal request and channel gate write. I found an old TTL open collector hex chip, the 7406, hooked these six up to the outputs and drove the inputs from a TTL breadboarding console I had. Immediate success with all the interrupt levels no longer triggered when I ran the 1130.

After a minute or two, I began to get triggering on IL3 but no other - this could be a flaky gate in the junk box chip I used or it could be the lack of a pull up resistor and good impedance matching. I really wish I knew the exact circuit inside the receiver circuits, e.g SLT card 7196, but will some experimenting and scoping of a fast enough signal to ensure I have decent impedance matching.

Once I am sure I have a properly working driver circuit, I will whip up a card that will drive the 41 output signals. The wiring will be detached from the four existing boards, which work fine as receivers of signals coming from the 1131 to me, then put on the new board that will drive signals out to the 1131.

My test using a 100 ohm resistor pulling the line up to 3.0 V, which is what I though was being done on the 1131 side, produced the results I expected and stopped the errant interrupt on level 3. The working plan is to select a chip that provides open collector output, so I can pull the line up to SLT levels (+3), with input specs that allow it work with the FPGA operating at LVCMOS 3.3 voltage levels, with a fast enough operation that it doesn't delay my signal changes too much, and ideally supporting a 3.3V supply since that is readily available in the current SAC Interface chassis. Finally, it should be able to sink the max defined for SLT, 30ma per channel.

I have found quite a few hex inverters or hex buffers but they either require TTL input levels, 5V supply, or are tristate with a very very long delay in popping up to high impedance mode. A DIP chip with hex gates is also pretty handy since once board will let me handle all 41 signals. A bit of research and then on to order parts or drive over to Anchor Electronics. Since Anchor closes at 4PM most days (earlier other days) and isn't open Sunday, it doesn't match the most natural times when I might be heading out to pick up parts.

I have the paperwork for the field engineering change that installed the SAC onto my 1130 system - I am hoping it is detailed enough that I can verify that there isn't some simple problem, like a loose wire from a string of 100 ohm resistors, that could be fixed inside the 1131. Once satisfied that the pullup to 3V is needed at my end, I will move on to parts ordering and construction.

After reviewing everything, I went ahead and selected the 74LS06 or 74LS16 chip because it meets all my requirements other than requiring +5V supply. The PC power supply I used in the SAC Interface produces that voltage, it just has to be connected to the new board. I will run over to Anchor Electronics and pick up what I need.

Wednesday, March 25, 2015

Fixed up lighting in data center shed

I went to the Computer History Museum to meet with the rest of the 1401 Restoration team, work on some tape drive problems on the German 1401 system and spent a bit of time with the Ramac restoration team as they set up for their weekly demonstraton. They gave me some ideas about how I might find replacement disk heads to replace the two crashed heads of my CHI drive. That drive is a second unit, whereas the builtin IBM drive in the 1131 is working just fine.


A few transistors on board 1 for the driver circuit were not reliably soldered. I am scoping the signals and setting up various tests to determine the state of the driven signals and the 1131 response.


I installed a pair of wooden rails to span the two center roof trusses, placed the reflector umbrella in the center and then attached the light and its electrical support boxes. It provided a nice flood lighting with the bright portion roughly fix feet in diameter, which should be good enough for general task lighting inside the shed given the 7000 lumen total output. The umbrella rod stuck down below the level of the roof trusses but was quickly trimmed to size.

The data center needs some ventilation and humidity control attention next, but that can wait a while since it will be a minimum of a month and likely more before the 1130 system could be moved into the data center space. 

Tuesday, March 24, 2015

SAC Interface debugging work, finding bad solder points on interface cards


Upon investigation, what I discovered was that a power pin (SLT +3V) was loose in the connector to board three, which delivers 12 of the 16 bits from the B register, one of the most visible sets of signals and ones I used to make sense of the incoming stream. In addition, on board 1 which was hand soldered (out of impatience) before I finished my flow solder oven, four of the twelve receiver circuits had transistors which weren't properly soldered to the pads.

After a bit of resoldering on the four known transistor issues on board 1 and a reseating of the pin for board 3, I was ready to test again with the 1131 powered up. It did show me all the T clocks now, which had been masked by the bad transistor positions, but I see that one of the X clock signals coming from the 1131 isn't valid. I have to determine if this is a wiring problem in my connector, the cable or something bad back in the 1131 itself.

I am also triggering the 1131 to take interrupts on all four levels. Even when I reversed the logical sense of the signal I am emitting, the same problem happens. I am not sure what is causing this but will do more investigation. It could be residual junk from the FPGA logic that will control this lines in the future.

I turned my attention to the driver circuits on card 1, because it is on the top and easy to access. I found that, just as with some of the receiver circuits on that card, I had some bad solder points for the transistors on a few circuits. I did some resoldering of transistors and checking, at least until I ran out of daylight.

Monday, March 23, 2015

Partially reassembled 1442 punch, debugging on SAC interface and some datacenter progress


I began reassembling the punch unit of the 1142 card reader/punch, up until the point where I would need the feed wheel repaired. This work put the punch restore comb, springs and lubrication covers back onto the assembly, but I can't put the incremental drive back without the wheel, nor the punch chad chute that funnels the bits of cardboard down from the punch unit to the bucket at the base of the enclosure since the chute is in the way when installing the feed wheels.


After I cleaned up the logic for the link it became apparent that the signals are not getting through to the fpga board. Time to dig into this since it now appears I am sending the signals as received, they just aren't received. Scope and logic analyzer time.

The fpga board is unplugged so I can diagnose directly from the board. With the 1131 powered down I began verifying the signal level and integrity of all the inputs on the top board of the PCB stack. Right away I found differences between circuits that should all be in the same default condition with no power at the processor. Disappointing but perhaps there is a benign explanation.


My reflective umbrella arrived and I did a quick but blinding test using it. It does indeed spread the light down, although if you look up it is still about as annoying as a direct peek even in daylight. I realize that I have to install the reflective umbrella in between roof trusses and that means the light itself has to be held by a couple of wooden sticks spanning the two trusses. That would center the light unit underneath the center of the umbrella for maximum relection and minimized blinding of occupants. 

SAC interface to PC link established


I kept at it this morning, trying to achieve a good link between my fpga board and the PC program. After burning some more hours, I decided that I am facing too many unknowns here - is the hardware working, the libusb, the firmware correctly in the FX2LP module, the bitstream coirrectly in the fpga, my logic for writing out of the fpga working, the python pyusb binding working, and so forth.

I decided to build one of the example programs and run it, which would eliminate about half of the possible issues and help me zero in on any defects stopping me from sending data from fpga to PC. It ran perfectly from the Surface Pro - so that I know the libusb on the tablet works, the Java binding works and the hardware is good.

The python program is on a laptop with a different libusb, the pyusb binding and my own code on both sides. Still a lot to eliminate, so I thought I would hack the code in the example so that it talks to my fpga - if I can get data flowing from the fpga to the Java code on the tablet, it further divides the potential problem area.

Immediately I discovered the problem in my code to contact the fpga  board, made a small change and immediately I was receiving properly formatted messages. I turned on a bit of the code on my PC side program and began testing.  The data is flowing in properly, but I have a minor flaw in the display update of the GUI. Once I fix that, I then powered on the 1131 and test out the quality of the data capture by the interface cards and fpga.

It doesn't appear that I am getting the right data flowing up the link, but diagnosing and fixing this will be simple now that I have the basic transport working properly. I took the time to do some other cleanup of the logic before resuming testing.

Sunday, March 22, 2015

Long day, little progress on the USB link to the fpga board


I ran into an anomalous behavior when trying to load the latest fpga bitstream onto the board's flash memory - I get an error writing the first block and it won't recover or write anywhere else. If the flash is hosed, I have two options. One is to erase it with an fpga load then try again. The other is to replace the chip on the board with a new one of the same type.

A second way to write to the flash is through the device web server provided in the SDK - but this too fails trying to write to the flash. I may have a bad device, although I might be able to reach it via the JTAG interface.

I am temporarily blocked by this problem and can't move on to test the link from the PC nor the SAC Interface box itself, unless I can load the bitstream out in the garage with the fpga board powered up from that point up until I run the tests. The  bitstream is only in volatile memory at the present, which makes it hard to test with the PC since the tools on this PC don't include any loader that recognizes the board.

I moved the device out to the garage, bringing both the surface pro and the laptop to combine the tools for loading the bitstream and for talking to the fpga logic I wrote. The nightmare of petty barriers continued - my laptop has to be extremely downlevel on Java in order to have the broken code of EMC's Documentum able to work properly, yet I can't run the SDK as it is just too old. The machine that runs the SDK is a fixed deskside machine in the den, too far away to easily relocate. Now on to try to get my Surface Pro able to run the right Java, libusb and other stuff needed just to put the bitstream on the fpga board. Arggggh. Hours wasted on petty issues like this.

By four in the afternoon, I finally was able to run the program on the PC but was seeing continual timeout in reads from the endpoint. Time to look closer at my fpga code,as I may have made a mistake in the modification of the sample designs.


I tested the 7000 lumen LED array light and it provided a nice clear light even in daylight, although I don't like having it pointing where I can look up into the lens as it is somewhat blinding. I think I will use a bounce screen above the lamp to reflect the upwards beaming light downward across the shed. I also need a better enclosure for the LED power supply which is a naked PCB right now.

I have a photography umbrella reflector coming which will be perfect for the installation. I moved the light where it should go, but in the process broke one blade off the rotary cooling fan. I will replace this as it causes way too much vibration and noise in its damaged comdition. 

Friday, March 20, 2015

SAC Interface PC link testing


I spent quite a bit of the precious time I had today fighting some more with the various parts of the new solution, before I could power up the fpga with a PC program and feel I was seeing real data displaying on screen.

For example, to speak with the USB device using PyUSB means that various libUSB libraries and python bindings have to be installed, otherwise it just complains there is no back end. The unique vendor and product ID returned for the ztex default firmware won't install the right driver on Windows, so that special tools are needed to get that working. It just goes on and on, an infinite spiral of problems, products and needed study.

I did get the Python program talking to the USB controller on the fpga board, but am still working on the logic in the Spartan 6. It is close to working.