SAC Interface cleanup, a discovery and adjustments underway - coming along quite nicely

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

When I got a chance during a very busy workday, I stopped by the workshop and looked into the circuit problems I found yesterday (driver circuit 40 and receiver circuit 18).

I also did some thinking about the problems loading the fpga bitstream into the flash on the Ztex board. While reviewing everything I did notice that the UCF entries for the flash, which are fpga pins that are also used for the data stream between PC and fpga logic, had a slightly different configuration.

I will change that configuration, reload the fpga and then try to load the bitstream again. At worst case, I will have the messages and sequences documented to post to the Ztex wiki. There are a few possibilities, such as the possibility that the flash chip is bad, but also the chance that it just needs an erasure or other special reset, or that there is a different problem. If the chip itself is bad, replacement is easy but diagnosis should be finished before I start removal and soldering on the fpga board.

The error continues - timeout trying to write to the flash chip. I might be able to check out the ability to read and write to the flash via the libjava library and the SDK API they offer, but it will take a bit more study.

At lunch hour I got to the machine, discovered that a trace was not connected on receiver circuit 18, and made a repair. However, my suspicion is that the chip serving driver circuits 37 to 41 is bad. i am whipping up a small board with a chip on it, to which I will hook up these circuits, which should at least validate the source of the problem.  Construction took a little while, but then I was ready for the testing.

The results were still odd, which means I may have a problem in the 1131 or there is something unusual about these links. I removed one of the lines from the driver and checked its voltage levels - it was at SLT 3V! The pullup/terminator was operational on these four of the lines when I checked. I popped off the resistors on my driver board and these now behaved properly. I pulled one of the lines off a different chip on the driver board and found it too was pulled up just as I originally expected.

Somehow the four interrupt request lines were different, requiring drivers with pullup on my side, but the  bulk of the other lines that are inbound to the 1131 are properly terminated and pulled to 3V. Time to go through these one by one and figure out a few things:

• Which of these don't have pullup to 3V and may need the resistor on my end
• What is different about the lines that don't have pullup - card type?
• If all lines should have pullup, figure out what is wrong on the 1131 side. 

It appears that the occurrences of lines without the pull-up to 3V is sporadic, no clear pattern but quite a few have this problem. If it were associated with all the bits of a given register, such as all the Channel Address Register bits, it might make sense, but at this point I have to assume there is a widespread failure of the pullup resistors on a variety of cards inside the 1131. 

I will look at the system in future days to see whether it is feasible without high risk or effort to just replace the resistors on the cards. In some cases, IBM used resistor packs where one component implemented several resistors - that would make the task a bit harder since I am unlikely to find a ergonomically similar resistor pack. For the immediate purposes, I will just leave my pullups for any line that needs them. 

I can use the resistance of the output from the driver board with the resistor hooked up to tell whether there is a pullup on the line or not - there are two cases, resistance around 66 ohms and up over 100. The low resistance indicates the pullup is in place on the 1131 end and I should remove my resistor. 

When I straighten out the driver side issues, I can then go back to looking at the cycle steal requests, response and X clock signals. I found about 40% of the lines did not have a working pullup resistor, at least so far. I am about 3/5 of the way through all the circuits as the sun sets and I go back inside. 

SAC Interface box physical circuits and PC transport link getting near end of quality assurance testing

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

The problem with the use of the wrong two leads on the C-D side cable has been corrected. I removed the two inappropriate lines, which were connected to the 3.3V supply on the fpga, and connected the two leads which are my chosen replacement, which were left full length when I originally manufactured the cable.

I cleaned up the few mixups in the fpga logic and in the PC side program, thus ready to commence testing as soon as it was light enough outside. I also converted the power connectors on the three old boards into fixed connections, since the connectors were all too prone to pop off.

I had a good morning steadily resolving issues and validating signals. The toughest inbound signals to test are those that occur fleetingly, such as the X-clocks and CS level signal, or parity stop that requires me to force a parity check. Slightly tougher are the XIO E1 signal and the other three (2, 3 and 4) interrupt levels, but there are means to drive the system to get to these states.

The incoming signal wires for bits 0 and 1 of the B register were touching together on the receiver board, which I easily corrected. I also found that the wires for Parity Stop and X2 are reversed relative to my documentation, as far as which circuit on the receiver cards each is wired to. A simple matter to adjust the FPGA logic and the documentation, correcting this flaw.

I found that my wiring for the signals for bits 12, 13, 14 and 15 of the B register doesn't correspond to my documentation, nor the fpga logic, which required some investigation. The bits are wired to rows 13 and 14 of connector A-B, but I was looking for them at rows 24 and 25.

I updated the documentation and then the FPGA logic during my lunch break, then went out to test again. I now had 15 of the 16 bits working properly, but when I looked at voltage levels on board 2, they ran a bit low. Further, the signals were noisy and muddy. This was the board that had the ground pin unconnected, which I tried to fix by hooking a wire to a via pad that was attached to ground. It is obvious that this introduced too much resistance, bouncing the ground level up and down to the detriment of good signal behavior.

I hauled out the reflow oven, a spare board blank and my remaining components. I had enough to build a board with all twelve receiver circuits, with a board that has good ground connectivity. Using my paste mask, I spread paste solder onto the pads for all the components, then painstakingly placed 96 teeny surface mount parts in their proper locations. The board went in the oven to reflow, then after cooling I hand soldered all the headers on that provide the connections on and off the board, plus power lines.

Replacement circuit board for board 2 - receiver circuits

Time to cut 27 wires away from the existing board 2, install them on the replacement board and place it in position inside the SAC interface. Right now the four boards and the fpga are loose, allowing access to all the cabeling and the signal pins, but once I am done debugging the signal paths from fpga to 1131, and reverse, I can mount them and close up the box.

Boards connected but not mounted in position yet

I still have the problem with the failed ROM on the FPGA board from which it should load its bitstream on power-up. Presently I am manually loading the bitstream each time I turn the box on, but this has to be fixed in order to really close this up and concentrate purely on logical reconfigurations via USB.

After replacing board 2, I have accurate capture of the B register and the other signals to the extent that I can check them. Here are the anomalies to investigate, some of which may be intended behavior:
  - Meter Out is active whether the machine is running or not
  - Inhibit Cycle Steal is erratically delivered

I want to do tests to verify the following, all of which require a bit more cleverness or some additional logic in the FPGA to drive certain conditions:
    - Verify that Parity Stop is flagged when we experience a parity check
    - Ensure that XIO E1 is raised at the appropriate machine cycle
    - Trigger interrupts on the four levels and verify the proper line is on in return
    - Trigger cycle steal and verify CS Level is returned, reads from loc 0 and contents in B
    - Verify the states X0, X2, X4 and X6 during cycle steal, in proper sequence
    - check to see that Chan Write Gate is activated by fpga

I have a few open lines to the FPGA that I can use with switches, in pullup mode, to select specific conditions to test. Wiring them in, I did my first set of tests, verifying that I can trigger interrupts on levels 2, 3, 4 or 5 and correctly see that status back from the 1131. I began to work on use of the switches to trigger cycle steal, allowing me to verify several other signals as well as the proper activation and status signal.

The switches didn't trigger any behavior I could detect - although if cycle steal is a single shot trigger rather than continuous requests, then I would need to watch with the scope to catch the cycle as it is full speed, 3.6 microseconds in duration. Some study required to formulate the best testing regimen.

I checked my driver board circuits for the four signals I was trying to drive - cycle steal request, channel write gate, block clock advance and advance entry - discovering that one of the circuits is not working properly. It should be up around 2.8 or 2.9V until I pull it down to zero when activated, but this is down around a quarter volt whether the input is on or off. I suspect this is the cycle steal request line, but whatever it is, something is not right.

I did figure out how to force a parity error - pretty easy, actually. Single Step the machine up to T2, by which time it will have read the contents of the core location, but not yet rewritten the location. Reading core is a destructive process, requiring the data that is read to be written back if you want the location unchanged.

Since I stopped it at T2 and did a reset, we had zeroed out location 0 but not yet written back data. All zeroes requires that the two parity bits P1 and P2 be set to achieve the odd parity level for each half. When we read it out, it reset all 16 data bits and both parity bits.

The next time the contents of the location are read, when that value is checked for parity, the processor detects an even number of 'on' bits and goes into a Parity Check stop. That condition is clearly reflected on card 1 circuit 11, turning on for a parity stop and off when the system is in normal state.

I then hand coded an XIO Sense Device instruction and stepped it in SMC mode until I was in the E1 state of the instruction. At that point, I validated that the XIO E1 signal is properly detected. More solid progress!

I looked at the Inhibit CS signal which seemed to be active according to my PC program, but shouldn't be. Putting a voltmeter on the signal from the 1131, I can see that the signal is not activated, yet my circuit is putting out 3.3V when it should be down near zero. This is on the newly rebuilt board, but is similar to the erroneous behavior with the old. This tells me I have a  problem that needs some investigation.

I will be prioritizing the diagnosis of the driver circuit and the inhibit CS signal receiver circuit, since I can't really test the cycle stealing related signals until the driver is working. I am in from the workshop and doing some FPGA logic development, preparing for using the PC link in two way mode. My first function from the PC will be a simple 'write this word in this address' command using the cycle steal circuitry. 

SAC Interface (re)wiring finished and testing underway

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Saturday morning saw the wiring of the driver circuits to the new driver board finished up. The fourth old style interface card was completely removed, as I only used the driver circuit side of the card. At this point, all 41 outbound signals to the 1131 are wired to the new driver card with the twisted pair style ribbon cable and that card is hooked to the flat ribbon cable to the C-D side of the FPGA which controls all the output signals. It took from 8AM until almost noon, with a few short breaks to ease out the aches from hunching over doing all the wiring and soldering.

Once I wired the power connector for the new driver board into the SAC Interface box, it was time to do some short circuit testing on the new driver board connections. As well, I began working out the final mounting method for the three old style interface cards, hosting the 36 inbound signals from the 1131, plus my new driver board.

It was time for a power-on test of the box, with the FPGA hooked up and linked to the PC. I was expecting to see the 1130 working normally, without interrupts being triggered, and to see the appropriate state of the inputs reflected on the PC program. The drivers were not triggering spurious interrupt levels, which is a big step forward, but I still need to methodically work through tests to ensure all signals are working properly

Frankly, during the time  a couple of days ago when I did the validation tests of the need for a pullup to SLT +3V, I lost my labeling on two of the four interrupt level wires and between the cycle steal request and channel write gate wires. Thus, I will need to determine them experimentally and modify, if necessary, my programming of the FPGA and documentation of the signal assignments to boards, circuits, and connectors.

My first tests showed a flaw in how I had wxPython render the value of the B register, but in my initial diagnostics of the PC side program I could see it was a rendering problem. Too, I found some apparent slight wiring swaps of a few signals, such as the T clock times. It was important to get to the bottom of these, thus I began monitoring all the signal values coming in from the 1131 with voltmeter (and oscilloscope as necessary).

I found that I physically wired the T clock signals in order from circuit 1 to 4 of the first board, thus any mixup in detecting which is active may be a problem in the wiring to the fpga, inside the fpga logic or in my PC side program. Upon investigation, it became obvious that the connector from the flat ribbon cable to the fpga flipped rows A and B, thus scrambling all the signal assignments I was using.

I am laboriously working through the FPGA logic to compensate, but also updating all the documentation as otherwise it will be very very confusing if I have to look at anything in the future. Another problem I found was that I had wired the driver circuits using a pair of pins on the FPGA which are a constant 3.3V (logic level 1).

I reassigned some lines and rewired the two signals that had been misconnected to C18 and D18, hooking them up to C15 and D15 instead. It took quite a few hours to straighten everything out.

The signal OSC Phase A runs continually, whereas I assumed it was the gated phase A signal that drives all the logic. That latter signal would not change state when in single cycle or stopped mode, and would jump high when the Start key is depressed in SS mode and jump to low when the Start key is released in that same mode.

I don't see the DC Reset signal coming through when I push the reset button on the 1131 console - needs a bit more investigation. Otherwise most signals are coming in just fine. I did spot one wire on a receiver board that was not well soldered and corrected it.

I feel I should continue testing in this mode, signal by signal, until I have high confidence in the signal transit between 1131, my interface box and the PC. Making good progress debugging and proving out the signal integrity.

It is definitely working better, although I still have a few small mixups to resolve. The daylight ran out and I had to close up the garage, looking forward to further improvements tomorrow.

New driver board installed in SAC Interface box, wiring almost complete

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I visited Anchor and returned with the parts to build my new driver board. I set up the work table outside the opened garage and went to work. I worked at a decent but careful pace, ending with seven hex inverter chips, their power condition capacitors, 41 pull up/termination resistors, headers for the 41 input and 41 output signals, plus the power supply connector in place. This took me until late afternoon.

New driver board, during wiring into the SAC Interface

It was then time to carefully remove all the driven signal wires from the four interface boards which are now exclusively receiver circuits. These were being extended and connected to the new driver board, along with the wires to the FPGA board. To extend the twisted pair signals coming from the 160 pin connector, I used some twisted pair ribbon cable I recently bought, which is normally fastened to IDC connectors but I separated the leads at both ends.  I individually connected the leads to my new board and to the twisted pairs from coming the big connector.

Twisted pair ribbon cable used to connect driver board to 160 pin connector signals

By the end of the day, I had the entire set of circuits from the first board - 12 signals - wired up to the new driver board and their associated lines going to the FPGA board. Further, I had removed all twelve of the 1131 side signals from the second board, labeled them, but had not begun wiring them to the new board.

After dark, I brought in the rest of the ribbon cable stock and finished separating the leads and preparing them to make the actual wiring go much faster tomorrow.  I then moved all the fpga-side wires off of the receiver board 2, hooking them to the new driver board. The new ribbon cable was hooked to the 1131 side lines I had previously removed.

Ribbon cables prepared for wiring up circuits from boards 3 and 4

I have one more full old style interface board that has driver circuits to relocate to the new board, twelve more 1131-side signals and their fpga-side analogs. The final old style interface board is used to implement five driver circuits, thus when they are relocated to the new driver board, that fourth interface board will be removed entirely.

After this modification, the box will still have four boards for interfacing between 1131 and fpga, but three are used for the 36 incoming signals and the new board handling all 41 outgoing signals will be the fourth. The extension of the outgoing signal twisted pairs over the twisted pair ribbon cables will give me more room to mount everything in the box, also facilitating debugging and maintenance as needed. 

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

1442 CARD READER/PUNCH RESTORATION

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

DATACENTER SHED CONSTRUCTION

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. 

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

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

1442 CARD READER/PUNCH RESTORATION

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

DATACENTER SHED CONSTRUCTION

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

DATACENTER SHED CONSTRUCTION

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. 

SAC Interface PC link testing

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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. 

Battling new fpga card toolchain and building PC side program for first SAC interface debugging

Another very long day with not much free time.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Just cleaning up logic and starting in on the PC side quickie program to display the status of all the signals being detected from the 1131 processor over the SAC cable. Hoping to have the signals reflected to the PC by sometime today, when I can fire up a test of the interface and do some debugging.

The toolchain was quite a pain - installing JDK, SDCC, MinGW, the ZTEX toolkit and other parts all independent and most only lightly documented. Finally stitched it all together and loaded my firmware on the fpga board's USB module. Next up, I loaded the Spartan 6 bit file to the board EEPROM.

I then whipped up a quick program using wxPython and PyUSB to receive the stream of signals I am transmitting and display them on a very simple GUI. It is not debugged enough to run with the 1130 powered up yet, but getting close to a first power on test.

Looking at options to repair feed wheel of 1442 reader, while continuing SAC Interface construction

I am out of the house attending a conference this week, plus some other obligations while home, that will limit how much I get done until the end of the week.

1442 CARD READER/PUNCH RESTORATION

The feed wheel 'tire' which sustained damage during dis-assembly will be a challenge to repair or replace, but essential if I want this unit to be able to punch cards. This component has a pair of wheels on a common axle, the wheels have some kind of ceramic 'tire' around the rim with a gritty surface to grab card stock well when the pivoting metal roller is squeezing the card onto the feed wheel from the other face of the card.

The diameter is important in determining the distance between columns during punching, while the degree of grip must be consistent between the two wheels to avoid any skew in the card motion as it moves from column 1 down to column 80 during punching. I am afraid I may need to symmetrically replace the tire on both wheels to ensure the consistency, but that is not certain yet.

The undamaged feed wheel

Ceramic like material split at the point where it had the grit added to the binder

Edge on view

Another view of the damaged 'tire'

Mark Sims has offered some advice on possible repair methods, all of which are being considered.


SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Working with an entirely new FPGA board with different firmware for the USB chip, a new toolchain for that USB device, changed pin assignments and a different way of communicating from the fpga require quite a bit of time to study, design and implement the system and begin testing.

Toolchain I will use - there are also web server and java interfaces

I got the VHDL for the board to the point where it would push the state of the signals coming in from the 1131 out to the PC and it set the outgoing signals to their default idle values. This will let me power up and verify some very basic functionality. Now fighting the new tools to get this all synthesized, turned into a bit stream, pushed onto the EEPROM on the board and to get the USB processor firmware I wrote downloaded.

Removed stiffness in feed wheel roller pivot on 1442 reader, moved some equipment into the data center and worked on SAC interface programming

1442 CARD READER/PUNCH RESTORATION

After quite a bit more disassembly, I had access to the pivots and rubbing areas for the pivoting roller that was so stiff and sticky. With plenty of lubricants and work, I have it working so much better that I believe that all it will take is some time with NPRO and reading cycles to have this as good as new.

Now I need to figure out what I do about the broken feed wheel tire, which cracked off along part of the circumference. If I can get this refurbished I can get this punch together, installed and nicely operational.

I didn't do anything on the cornering station and stacker issue since I can't test until the punch is re-installed.

REPLACEMENT DISK HEAD FOR CHI DISK DRIVE

As you may remember, the 2310 compatible external disk drive I brought back had suffered a head crash, so that both heads are all scraped up and damaged a test pack when I spun it up. I noticed an eBay auction for a 2314 disk head and it seemed to be usable as a spare, so I bought it for a nice small amount.

Look at the picture side by side, with the head I just bought on the left and the crashed head on the right - looks like it is possible to move the main part of the head over and use it. The head is backwards relative to the other head, but I might be able to mount it on the other arm not this one in the picture. Now I just need to find one more head.

New head on left, bad head on right, looks like it can be remounted  on the long substrate

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I installed the toolchain for configuring the Ztex FPGA board and began configuring the USB side to meet my needs.

As well, I began changing the VHDL files for the SAC interface to make use of the Spartan-6 based chip on the board. There is quite a bit to modify but I did make good headway today.

DATACENTER SHED CONSTRUCTION

The new GFCI breaker was installed in the panel, I plugged the shed cable into the outlet and successfully tested the outlets inside. I am now ready to move some of the gear clogging up the garage out to the data center. First out were the Documation card reader and its control unit, placed on an 8 foot folding table. Next were my paper tape reader and punch units and the plotter.

I was eager to move the 029 keypunch out to the shed as well, but its weight and cumbersome size was an issue since the shed floor is more than a foot off the ground level. Fortunately, I figured out how to do this without too much sweat and now have plenty of extra moving and working space in the workshop. 

Tearing down the punch unit of the 1442, wrapped up construction of the SAC Interface box, on to programming and debugging

1442 CARD READER/PUNCH RESTORATION

I oiled the pivots and greased the cams that activate the pulleys involved in reading and moving the card to the pre-punch position. I then began disassembling the punch eject assembly, because the roller pivot was quite wobbly which has to be diminishing the force of the ejection into the cornering station.

Removing the pivot was quite a bit more challenging than I thought, because the Screw won't releease the rubber wheel, forcing me to partially disassemble the bearing, shaft through the frame and gear/belt on the other side.

I still have too much drag at the cornering station. I just don't understand it - I am polishing the metal constantly and the plastic cover too. I will play with the 'bite' of the rollers that suck the card away into the stacker stations.

I am also studying to see what kind of effort is involved in stripping the punch down and rebuilding it. So far, I have removed the Incremental Drive, the restore assembly, the magnet unit and some access plates, but still looking into how far I can safely tear it down.

I can see that the punch and interposer mechanisms work well, which is nice to know. There is still the sticky pivot for the feed wheel roller, which seems to require even more disassembly.

Near the end of the day, disaster struck. Somehow I managed to shatter some of the ceramic 'tire' on one of the feed wheels. These have a gritty ceramic applied to them, reminiscent of a grinding wheel surface, which grips the blank card stock and moves it forcefully to each of the eighty card columns during a punch cycle. With part of the circumference shattered off the wheel, I will now need to find some way of repairing this. This is not good.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

This morning I installed the two 50 pin IDC connectors and converted them from female to male. I had some header strips for Arduinos which have pins that are shorter on the side that fits into the Arduino and longer for mating with other connectors, but I wanted them symmetric, the same height on each side of the narrow plastic separator strip. I used pliers to carefully modify these and tested the fit between the IDC connectors and the FPGA board. It works well.

Ribbon cables with IDC connectors to fit on the Ztex fpga board

The broken ground line on board two was resolved by tacking a wire to one of the large pads for a ground via elsewhere on the board. I also installed a wire to pull the Meter In signal to permanently off, since this is only of interest when you want to bill by the CPU usage meter and care that a peripheral may continue operating a few seconds longer than the processor - squeezing every last second of billing.

I finalized all the wiring and mountings for the circuit cards, cleared up some 160 pin receptacle issues with socket pins that were too far back in the housing, then installed the SAC cable to the 1131. At this point, I need to configure the FGPA so that it asserts the proper state on all the command lines - such as interrupt requests - to make it neutral to the operation unless my logic changes things intentionally.

The Cypress FX2 USB module requires definition and compilation of the firmware to run the USB module. This module has an 8051 microcontroller inside as well as a fair amount of direct hardware to maintain quad buffered FIFO queues to support full bore 480Mb/second operation to the PC host.

I installed the toolchain and configured the USB firmware into the board, at which point it would also allow me to configure my logic definitions into the Spartan 6 FPGA via storing them in EEPROM on the board.

I had quite a bit of remapping to do, switching the signal assignments from the old Digilent FPGA board to the new Ztex board, as well as swapping out the USB link logic.

DATACENTER SHED CONSTRUCTION

I received my ground fault circuit interrupter breaker for the 240/120 20A link to the outdoor weatherproof socket. I can now plug in and test my interior wiring, once I stick in the breaker. Since it is dark out now, I would prefer to swap the breaker in the panel during daylight. Less chance of shorting something or worse. 

More work (and rework) on the SAC interface boards, plus continued work on the card reader.

1442 CARD READER/PUNCH RESTORATION

The lever was not loosening any more with repeated manual exercising, which suggests that I may be forced into a total teardown to make this right. The good news, sort of, is that after some study of the manuals last night, I realized that this error itself should NOT cause either of the reading errors I saw. The effect is for one of the two rollers for drive wheels to remain disengaged. The only time it needs to be engaged is when we are punching cards.

Since there was a lot of crud in the throat of the punch unit and along the bed, I will make a working assumption that my problems came from the drag, which should be gone now. I temporarily reinstalled the punch unit, in order to work more on the reading side of the 1442.

What I found was that the drag from the bad roller pivot was enough to slow the good one down. I removed the pushrod to the bad pivot, which remains up and out of contact, allowing the good pivot to work as intended. However, this was not a usable change because the bad pivot does ooze downwards, even if it is too slow for normal operation, it is fast enough to jam the path within a few seconds. Back went the pushrod.

Reads now completed just fine, but the card wouldn't move through the punch station on the next cycle. There is some grease and gunk jamming the cards, but I worked that out using a few sacrificial cards.

Finally, the card reader is reading cards, getting occasional read checks due to draggy operation of the punch pivot, but mostly reading just fine and transporting cards right to the cornering station. If I release a bit of drag by slightly lifting the plastic cover on the cornering station, cards leap right to the stackers just as they should.

The punch pivot is exercised every time I operate the card feed cycle, so running the mechanism with the NPRO key will be enough to work it dozens to a hundred times for a reasonable length of NPRO operation. I can repeat this over and over until the pivot behaves as it should.

I will try adjusting the cover height for the cornering station to see if I can get the reader to be more dependable moving cards into the stackers, although I won't work on this today because the daylight is running out.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I spent the first hour this morning going over all the documentation and diagrams of the connections to be sure I had everything straight for what signal from the 1130 goes to a specific card, from the card to a cable wire, from that wire to a connector on the fpga, and from that connector to an FPGA logical pin. This will greatly improve the quality of my work going forward.

I sat down and finished wiring another six signals to the FPGA cable, making board two complete. As I got ready to move to board one to hook up another twelve signals, I had a sudden thought. Remembering that my first check of the driver circuits didn't look successful, while looking at the circuit board, I realized that I had taken as gospel the printed solder mask that had the cathode band of the diode marked.

Since these are polarized components, they have to fit in the right orientation, but I just couldn't imagine that the preconfigured artwork in the printed circuit board tool I used, DesignSpark, would print this incorrectly. Further, each time I inserted and soldered the diodes, I mentally saw the cathode marking as the anode, since the schematic symbol for a diode is a triangle for the cathode and a bar across the tip of the triangle for the anode. The bar looked like the marking, but of course the bar on the diode is the cathode, not the anode. I should have caught the error on the silkscreen on my boards right away.  observe my reaction

I now had to rework all four boards, removing 41 diodes which are backwards and installing 41 new diodes in the correct orientation. Made much more fun because the boards are in-place, mostly wired and therefore access is limited.

On some of the diode repairs, the signal trace from the PCB is no longer contacting the component lead. In most cases I could reflow some solder at the junction and restore connectivity, but in other cases I had to tack the FPGA cable wires to the diode when necessary.I am checking continuity of each end of the diode after it is replaced and handling problems appropriately.

I found that board two has no continuity from the ground pin on the power header to the ground plane - very odd indeed, must be a solder flow failure inside the via going down to the ground layer. I tried reflowing solder on the pin but it didn't improve. Fortunately, I have several larger than normal pads at vias bringing ground up from the ground plane to some component, which means I can tack a wire onto one of the via pads to get ground onto the board.

As of the end of day, I have all four boards wired to the FPGA board ribbon cables, but haven't installed the 50 pin connectors on the ends of those cables yet. I have the fix to the ground on board two, one new connection to a pin on board four, and the signal ground bus to connect to the box ground. More importantly, my original two ideas for how to mount the circuit cards aren't working out. I have a bit of thinking to do.

DATACENTER SHED CONSTRUCTION

Today I checked out the circuit to the outdoor outlet on the side of the house delivering 240/120 20A, which I will plug into when I am powering the shed. My goal is to get it verified so I can move some gear, such as my 029 keypunch, into the data center shed in order to make more working room in the garage.

I am not happy with the current breaker, as it is not a GFCI type which is required by electrical code and of course required to be safe with outdoor lines. The correct breaker should arrive tomorrow afternoon, my target for powering up the shed. 

Identified problem at root of the 1442 card reader/punch problems, meanwhile continued wiring SAC interface box

1442 CARD READER/PUNCH RESTORATION

It seems that cards are slowing or dragging as they move through the punch station. This causes both problems I am experiencing - a check condition as the card hasn't cleared the photocell area when it should have, and poor ejection into the cornering station for movement into the stackers.

I will remove the punch unit to get at the heart of the problems here - as was recommended by Peter Vaughan of the National Museum of Computing in the UK which has successfully restored an 1130 system.

Cable disconnected as first step to remove punch unit

After removal and examination, I discovered grease covered dust bunnies wedged in the card path, dust and oil mixture coating the bulk of the mechanism and an obvious problem. To describe the problem and my actions so far, I have to give a touch of background on the construction and operation of the punch station.

The punch station has a pair of very thin rubber wheels that will move the top and bottom strip of a punched card. A metal roller on a pivoting arm sits above each of the wheels - both rollers share a common arm. The arm is spring loaded to force the rollers onto the drive wheels, except when pushed out of the way by two pushrods coming up from the punch release lever. This is pushed manually to release cards stuck in the punch station, but also pushed by a long lever driven by a cam on the main card feed clutch axle.

In each feed cycle, the feed clutch axle will lift the rollers off the punch drive wheels at the beginning and end of a cycle, otherwise relaxing the pushrods so the card is squeezed by the wheel/roller duo and moves only when the drive wheel rotates.

When a card is heading into the punch station at the end of the feed cycle, the roller is lifted until the card comes to a stop at the right position for column 0, then the roller is allowed to press down on the drive wheel through the card.

When a card is moving out of the punch station and going to the cornering station, the roller is controlled to move the card out at the proper speed to stop precisely where it should in the cornering station .

On my punch unit, one of the pivot arms on the common axle is very stiff, too much for the spring to restore on its own, thus the roller is not properly moving to its two positions. This results in the improper card movement into the punch station, but also gives a weak ejection speed from the punch into the cornering station. If I solve this, it should solve both of the observed problems.

Punch unit out of the machine for investigation

Punch went here between the read station on left and cornering station on right

Front of reader where a belt powers the Incremental Drive which moves and punches column by column

I have been dripping oil everywhere that the gummy lubricant might be causing the excessive friction, but I have limited access to the inside surfaces. To pull this apart, clean it thoroughly and reassemble, I would have to almost completely disassemble the punch and incremental drive unit, which opens me up to a large number of very critical adjustments that will need to be made. I am going to hope I can free this up enough without having to 'go nuclear' and temporarily turn the punch into a large pile of teeny parts.

It may free up from a very large number of hand cycles of the pivot arm using both the release lever/pushrods and a screwdriver. I will work on this process for the next few days and hope I can restore normal pivoting.

As of the end of the day, I am guessing that it is about 20% looser than initially. Friction is still stronger than the spring force, but it is close to that point at least.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

My connectors for the FPGA to circuit card cables should be arriving Saturday afternoon, when I can finish the wiring. Today I repaired the two broken leads onto the 160 pin connector, as well as verified that no others appear broken off. I had spare pins which didn't make the task too hard, particularly since the two that snapped were near the top and easily accessible.

This is frustrating, because I specifically switched to stranded wire for the connectors in the 160 pin unit to avoid the problems I was having with solid wires in connectors. The solid wire would snap more easily, while the individual strands in the other wire type are able to handle the stresses with less risk of breakage.

I realize my problems were caused by all the bending of wires I have had to do when unsoldering all the original boards, soldering the new boards, then resoldering the new boards to the proper points.I am going to try to minimize movement of the boards while I wire them up and then very carefully move them into their mountings.

I made up some colorful ribbon cable for the FPGA to circuit board connections. I wired up 30 of the 77 signals today, going slowly and carefully, As part of this task, I decided to reorganize my assignment of signals to FPGA pins, so that the cable is very straightforward and logical.

Ribbon cables being attached to circuit boards

I am using a 50 pin IDC connector to the ribbon cable, which is built as two rows of 25 pins, Knowing that the pin for row A, column 1 of the FPGA board is the leftmost wire on the ribbon cable, I could plan out the signals assigned to each wire. Some of the pins on the FPGA carry voltages or ground lines, for example pins 1 and 2 are 3.3V while pins 3 and 4 carry ground. I split the ribbon cable for most of its distance except for where it attaches to the FPGA as a single unit.

The first two wires are cut off, since they are 3.3V, and the next two were kept as a short pair for grounding. The next twelve wires are the signals going to board 1, so that group of twelve are together as a mini-ribbon going to board 1, the next twelve is another group that supports board 2, then I have a ground of six wires which are power and ground, another block of twelve for board 3 and then a few unassigned signals left alone for expansion.

Then, each mini-ribbon with twelve wires is split again for the last few inches near the circuit boards, into pairs of wires that match the double pin headers I built onto the circuit cards. I then began attaching the wire pairs.

Plodding through wiring and testing of SAC Interface cards, plus work on the 1442 read/punch

1442 CARD READER/PUNCH RESTORATION

I determined that the failure to read a boot card is because the read clutch isn't engaging at all - the feed cycle takes place but no sign of movement on the read clutch. I  studying the mechanism and logic in order to find the next few things to check.

What I discovered is that the read clutch should trip each time the feed cycle occurs, but it is not. The activator is a pushrod riding on a cam on the feed clutch axle. Time to look for missing or misplaced rods.

Yes, it was the staggeringly difficult to replace rod from a while back which had fallen out. I put in thirty minutes of contortions involving several forceps, hands bent through parts of the mechanism and with great luck, I got it back into place.

I did a boot read of a one card diagnostic which was read perfectly - no errors! I was eager to pull that card out and put in the cold start card, booting up DMS from the 1442 card reader and of course getting the job start page printed on the 1132.

In my haste to remove the card, I brushed against the read clutch lever, which instantaneously ejects the rod. I called myself every name in the book, went inside to calm down, then returned to wrestle that damned rod back into its position again.

Got it back into the machine and did a boot of DMS using a cold start card - the reader got a transport check but that is after the read is complete and thus invisible to the process of booting. Up came the monitor and out printed the header page.

I jumped on the 029 keypunch and put together a three card job to dump the LET to printer (that is a listing of the directory of the disk pack. Success! This further exercised the printer as well as validating that the reading functionality is solid.

Here is a sloppy, quick video because I didn't think about videorecording until the job was already running and printing away: Printing the disk cartridge LET on 1132 printer

Now I just have to work out the stale grease and other problems involved in moving cards through the punch station and out to the stackers. I haven't tested punching cards yet, so there may be some additional problems lurking there, but at least for now the only remaining issues are in transporting cards once read.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I began to test the boards with the 1130 hooked up, in order to verify the quality of signals and the behavior of my circuits. My first discovery was disheartening. Somehow I had mis-marked the input and output sides of my circuits, thus wiring the 1130 signals into the wrong side on all 77 circuits.

Checking the rewired inputs and operation of a receiver circuit

I first moved all 12 input and 12 output signals on the top level board, then hooked up the scope and 1130 again to see the behavior. The good news is that twofold. First, nothing was damaged by my Homer Simpson moment with the original connections. Second, the signals look fantastic.

Incoming 1130 signal on top in yellow, my output signal below in blue

I observed the T0 clock input while running a loop on the 1130, monitoring the signal sent by the 1130 and then my receiver/conversion circuit output as it would be presented to the FPGA. The output pulse has essentially zero delay on the timescale of the 1130 system and the shape of my output pulse is more ideal than the signal transmitted by the 1130.

I finished the rework of the first board, mounting new headers that will connect to the FPGA cable. It was then time to validate that all 12 incoming signals worked properly. The outgoing signals from this board are just the data lines that will be gated into memory when the software is reading from a peripheral supported by this box. As such, observing them will be a bit complicated. They are normally gated off and don't affect the B register until the proper cycle of an I/O instruction.

I was, however, able to inject a signal into my driver circuit using an external tool and monitor the resulting signal going out to the 1130, but don't see it activating. That was true for multiple circuits, eliminating the chance it is a construction or component error. More study is needed to sort this out.

I ordered all the connector parts I need to make up the final FPGA connection cable. The parts should arrive early next week when I can fabricate the cables and then finish physical construction of the SAC interface box.

My the end of my lunch hour, I had converted board two as well, and the partial board four, now having 53 of the 77 signals correctly installed. After work, I finished the third full board, the last one to do.

I discovered to my horror that wires had snapped off of pins on the 160 pin connector - two I can see - which would drop bits of data being read in from an IO device to the 1130 through this interface. I have to fix the problems, so a bit of unexpected work on top of everything else I have had to do on this unit.

Printed first page from boot up of DMS2 on newly restored 1132 printer

BROUGHT UP DMS2 ON 1130 AND PRINTED HEADER PAGE

When the 1130 monitor boots up it acts as if it processed a // JOB card and prints a header page, then goes to the primary input device (card reader) and waits to read in jobs. I booted up the system today, now that the 1132 printer is through its restoration, and saw that header appear on the paper.

Header page from boot of DMS2 on the 1130, printed by the 1132 printer

1132 Printer back together after restoration was completed

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I finished wiring all the signal lines to the boards and installed power connectors. I also worked on a new mounting method.

1132 Printer restored and fully operational, more wiring of circuit interface cards for SAC interface box

1132 PRINTER RESTORATION

I attempted to solder new wires to the connection points, to yield leads with continuity through the coil that can be soldered onto the main connectors on the magnet bar. This was easily accomplished and continuity verified before moving on.

New leads added to connection points inside coil

The coil had to be wrapped with a new protective layer to replace the wound plastic fiber that I removed to get to the connection point. I chose to use black electrical tape in narrow strips - after first covering the two connection

Wrapped with black electrical tape

The newly repaired coil was pushed back into place on the core and the leads soldered into place. With that done, it was time to begin reassembly. The magnet bar went on the magnet assembly. That in turn was placed on the magnet unit, then the armatures for the repaired bar was reinstalled. I tested each armature to make sure it was moving the levers that would release each cam clutch to print that column.

Coil pressed back into place on the core

New leads soldered into place and continuity verified

Magnet 'bar' installed back on magnet assembly

 The wires from the printer electronics were reconnected to the repaired bar. The magnet unit was slid back into the printer and tightened into place. It all looked good.

Magnet assembly reinstalled on magnet unit

Armatures replaced on repaired magnet bar

With that done, it was time to test the printer. I give myself an A minus grade, because while column 60 is now printing perfectly, column 3 wasn't. I felt the armature and discovered that something was binding. Should be a simple matter of pulling the magnet unit out slightly and then reinstalling it.

Doing a happy dance about the printer, even with the tiny bit of work left. I then loosened the unit, tightened it up again, and verified full correct printing on all 120 columns. I have put the doors back on the printer and will check this one off of the list of restoration projects!

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Today I continued wiring the new circuit cards to the 160 pin connector, targeting that all 77 signals are handled by the interface cards. The new FPGA will be connected to the four interface cards using the headers on the cards and the FPGA board, making use of ribbon cables for neatness and signal control.

The interface cards convert the voltages, thresholds and currents of IBM's SLT logic to 3.3V CMOS signal levels for use with the FPGA. Further, they match the SLT circuits well in terms of impedance, thresholds and other characteristics, modeling the circuits implemented inside the 1130 at the other end of the 160 pin cable.

I completed the wiring of boards 2 and 4. I skipped over board 3 because the last board sits on the bottom of the stack, had only five twisted pairs to connect and that would make the task of restacking boards 3, 2 and 1 much easier. Wiring these boards is laborious, requiring me to verify every pin connection is going to the proper circuit on a board, then collecting and soldering the 24 ground wires from the twisted pairs onto a ground bus wire for the card. 

Major progress on solenoid for print column 60 of 1132 printer

1132 PRINTER RESTORATION

After I published the last post, I went back into the garage and made major progress towards restoring column 60 printing. I took the magnet assembly off of the magnet unit (yes, IBM named them this way). That had its moments, with several frozen bolts, apparently tightened by a gorilla. A couple required high impulse to free, delivered with a off-center chisel and hammer, but they came out.

Magnet assembly after removal from magnet unit

The other half of the magnet unit, the levers that convert armature pivot to release of cam clutch

The assembly came off and allowed me access to three screws underneath and two on the ends that hold the top bar of 24 magnets onto the assembly. With it removed, I could move to the workbench to take advantage of the greatly improved access to the coil.

Magnet bar (not official name) containing 24 solenoid coils

What I thought of as wedges were instead dents created in the core to hold the coil on firmly. Using tiny screwdrivers on each side of the core, I bent the plastic bobbin away from the dented core and used a hook tool to pull up on the core. I was able to edge it up and off the core.

Coil removed from core - notice dents on sides to wedge the plastic bobbin in firmly

The coil was still an open circuit even with all possible manipulation of the leads. I then began removing the fabric covering to see the condition of the coil connections between magnet wire and the leads. It was a slow careful process to nip and unwind a few strands at a time to ensure I didn't cut the magnet wire leads coming out of the winding.

The bad solenoid for printing on column 60, an open circuit

Once there was full access to the two connections, the leads and their magnet wire end, I tested the continuity from the solder points of the connections. We have an intact coil - perfect 143 ohm resistance measured and no cut-out regardless of movement of the connections.

Magnet wire connection points have continuity - "Houston, we are go for liftoff"

All I need to do in order to fix this is to tack solder new leads to the existing connections and then carefully rewrap insulation around the coil. When that is done, it can go back on the core, the bar can go back on the assembly, and so forth until the printer is completely reassembled.