Friday, October 31, 2014

Still battling the keypunch, stalemate tonight, plus more assembly of SAC interface boards


After going over the inside of the keypunch and bending various SMS socket pins and relay panel pins to ensure there are no unintentional shorts, the keypunch appears to be working just fine by itself. I finished wiring up the new keypunch cables I began with better, more secure connectors and larger gauge (lower number) wire. I dressed it well along the panel and made the cable much more bulletproof and production level.

New reader cable DB25 plug - rugged wire bundle

Reader and Punch cable wiring dressed in place on back of wire relay gate inside keypunch

My reader (white) and punch (red) cables ready to plug into the interface box
In addition to replacing the cables and dressing them along the keypunch relay gate, I wired the power brick into the power supply so that it is switched on with the main keypunch power switch under the table. Finally, adding a DB9 extension cable to run up out of the machine, I now had the means to put the box inside the keypunch ready to close up the interface cover once debugging is complete.

Power brick cable converted to lugs to attach to the 029 power supply
Testing resumed but the keypunch is stuck in its state of refusing to recognize a card was registered. I will check over my wiring a bit but I am beginning to suspect this is just erratic operation from relay contacts that still have a bit of oxidation on them. However, I will also recheck the wiring to be sure it is correct.


I assembled more receiver and driver circuits onto the board today. I was able to finish one board and have three more to do. It is slow going to make sure I do it correctly. It has the +5V, +3V and ground power lines attached but does not yet have input or output leads.

One completed board for SAC interface, 12 drivers across top and 12 receivers across bottom


Several manuals are not available on bitsavers or other digital archives, but should be. I slowly (and I do mean slowly) get the pages scanned in between other activities. This manual with more than 180 pages has taken three days elapsed time so far and I am still only at page 150. I don't usually comment on the scanning but realized it was completely sub rosa if I didn't.

Thursday, October 30, 2014

Very light day working on the system

Between heavy work obligations and an afternoon at the dentist, I only had two hours to spend in the workshop today. Still, I did make a bit of progress.


I removed the added wiring inside the keypunch and began to wire it with the new preferred push on connectors, on the assumption that the old connectors were bridging to the wrong wires because they weren't very secure. While I was at it, I used larger diameter wire which I will install on a DB25 connector.

With all the wiring disconnected, the keypunch was still misbehaving. It worked fine with a card registered in the punch station but once there was a card registered in the read station as well, the card lever relay won't activate so punching or spacing is not possible. At least I now know this isn't a flaw in my interface design.

As soon as this is debugged and repaired, I can resume testing of the interface. While I am working on the keypunch wiring, I am also replacing the read cable connections as the pins I used are also insecure, very wide and exposed at the top where they can touch other pins.


I soldered a few more driver and receiver circuits onto the board, until it was too dark to see on the outdoor work table I use for assembly.

Wednesday, October 29, 2014

Successfully booted DMS2 from the internal disk drive and began building the SAC interface hardware.

Very busy with tasks from my day job, but I was able to grab a couple of hours with the system and made good progress in that time. starting manufacturing the logic/voltage conversion hardware that will interface the Storage Access Channel cable from the 1130 to TTL logic.


I checked over the cold start card data I had written down, spotted a couple of transcription errors and fixed them. After toggling the eighty words into core and readying a disk cartridge with the DMS2 monitor installed, I booted up the 1130! I head it seeking and reading multiple sectors and then drop into its I/O wait condition. The IAR read x002A and the accumulator (ACC) has x6000 which means the 1132 printer is not ready - exactly what would happen since I didn't have the printer powered up.

This is a very strong test of the system, both the 1131 processor and the disk drive, much stronger than the diagnostics I have been able to toggle into the machine so far. Once I have either the 1053 or the 1132 ready to print, I can run even more - DMS2 can be set to print on the console printer as an alternative to the line printer, plus the input commands can be rerouted from the 1442 card reader to the keyboard. I would need to have the 1132 appear ready, even if the hammers are not causing readable impressions, just to allow DMS2 to be ready to read. Then, I would have to nurse one card through the 1442, // TYP, which redirects input to the keyboard.

That would allow me to type in some job control (monitor) and supervisor cards. I could run programs, at least those that will allow all its critical input to come from the keyboard or keyswitches and don't need to print or read cards.


Until the disk heads can be thoroughly cleaned and inspected, I will not be putting any cartridges into the Diablo drive. I may experiment a bit to get sense DSW to respond for the disk drive and line printer device address that the interface implements.

I am not sure what addresses it uses, although the printer is called a 1405 which implies it may use the same area code as the IBM 1403 printer. Similarly, I expect the diablo disk to appear as one of the standard addresses that are used by DMS and the disk oriented utilities.


I am not happy with the security of the connections put onto the SMS socket pins, suspecting these are leaning over, shorting together wiring to cause the balky behavior of the keypunch. I found some push on connectors that fit much better than the current ones I installed. Once I rewire this with the improved connectors and am satisfied, I will go back to the testing.


All my supplies came to day and I started construction. I slightly modified my plan for the board layout in order to make assembly easier. Now, each board will implement twelve drivers across the top half and twelve receivers across the lower half. I have built 25% of one board so far, before the light faded outside where my assembly table was set up.

Top shows three driver circuits, bottom has three receiver circuits

The circuits are packed tightly together, each requiring five vertical columns with the input at the leftmost column and the output at the rightmost one. The horizontal power strips are +5V and ground, but the receiver circuit also needs +3V which is an SLT requirement. The +3V will connect to the number two column of each five - you can see the open hole at the top  and near the bottom of the second column, where I will daisy chain the +3V down to a connection point at the far right of the board.

I have the parts to assemble circuits for all 77 signals that are carried on the Storage Access Channel interface. This will require four boards, whose total capacity would be 96 signals if they were needed, with twisted pair in the SAC cable hooked to these circuits. The TTL side of these circuits will be wired to a high density connector which I can use to connect other logic into this voltage conversion interface. 

Tuesday, October 28, 2014

Keypunch interface stubborn issue, SAC receiver circuit working, and testing the CHI interface/disk


I wired diodes across the relay contacts in my box in order to absorb any induced back EMF from the opening of the coils. Electrically it would be more ideal to install these at or close to the punch solenoids in the 029, but we are trying to keep the keypunch modifications to a minimum. However, the small gauge wire connecting to the interface box will have to absorb the current spike flowing through the diodes.

Diodes added across relay contacts in order to quench back EMF from keypunch coils
With the diodes installed, I hooked up the box but found that the machine was not recognizing registration of a card even initially, with no attempts to punch. I will have to troubleshoot this to understand what is blocking registration.

I made up the dummy plug and verified that the keypunch works properly with the interface disconnected. Therefore, there is no damaged component in the keypunch. I hooked up the punch cable to my box, leaving all other cables including power disconnected. The keypunch worked properly one time with cards but after a clear cycle, it was again failing to recognize when the next card was registered.

Dummy plug for punch cable when box not attached to keypunch
This tells me that something in my static wiring is causing this problem - the wiring that is linked through relay contacts is somehow causing a problem - the relay contacts being open. It may be a wiring issue or a short in the connectors or something else, but I have to diagnose this before the box can be tested further.

I tested every wire going into the box from the punch cable and they were all infinite resistance to each other, except for the pair for multipunch pole 2 which are normally closed. I ran the keypunch with the dummy plug for a while, then plugged in the punch cable but otherwise had nothing connected to the interface box. This worked well for about five or six cycles of registering, spacing and clearing cards.

I then plugged in the power brick connector (but no AC was hooked to the brick), which locked up the keypunch on the second cycle. Very odd. At this point I have to suspect that a connection is intermittently shorting somewhere in the SMS block, so that small movements of the cables introduce the error.


I powered up the CHI interface electronics and they came up cleanly. Looking over the cards, I came to the conclusion that it appeared likely to be working properly. As I result, I will cable this to the SAC interface and give it a try later tonight or tomorrow.

CHI interface looking good, decided to begin testing it
The interface came up fine and the drive loaded a pack I was willing to risk. I found a slight darker mark where the head was riding on the disk. I will inspect it in the sunlight to see whether it damaged the pack, but the heads must be cleaned at a minimum before I put any other cartridges into the drive.

Superficially clean drive, but some marking on a cartridge where the heads flew


I picked up the solder this morning and rewired the demo receiver circuit, which is hooked through a transmission line (I twisted wires together from the driver output and from the receiver input, then connected those twisted pairs temporarily). This is intended to verify that TTL input signals to the driver will be properly reflected as TTL outputs from the receiver, as well as my verification that the voltages are at appropriate levels in both states.

The circuit worked perfectly. I varied resistances to ground on the TTL input to the driver to see at what voltage it would switch between on and off. It will recognize a logic level 1 down to .1V but is off somewhere above .066V, well within the specifications for the logic I will use to drive signals towards the 1131.

Driver circuit on top and receiver circuit at bottom - working perfectly
Now that the circuits work with each other, I will temporarily hook the receiver up to one of the SAC output lines and the driver up to one of the SAC input signals, in order to prove these circuits work with the IBM SLT logic cards. I chose interrupt request and the corresponding interrupt level status as the signals on the SAC interface, as I should be able to see the request mirrored on the 1131 console and the status of the interrupt level on the panel mirrored at the TTL output.

I lieu of testing this, I powered up the CHI interface and disk drive (see above). I may do some XIO tests to determine how the CHI interface is responding (and to what addresses), but the important testing will be with my circuits once I move on to try them with the SAC.

I went ahead and ordered the transistors, diodes and resistors I need to implement the full interface which will give me TTL logic on my side and for the other side it will deal with the 1131 SLT transmission lines coming out of the SAC interface. I expect to have all the parts by the end of tomorrow, thus doing the assembly on Thursday and Friday.

Monday, October 27, 2014

TTL to SLT driver circuit working well, plus solid progress on the keypunch interface unit


I have a good new belt for the 1053, although I know that installing it means partly disassembling the operational shaft and possibly having to redo all the settings when I put it together. I will stall a few days before starting this odious task.


I studied the schematics for the 029 Keypunch and read the theory of operations manual until I figured out what is going wrong - the failure to register a card and allow punching that crops up after some time using the new interface. It is the multipunch key implementation I designed.

When the multipunch key is depressed, the keypunch will drop the alpha relay, putting the keyboard into numeric mode which does not allow space, A or Z keys to be activated (they have no numeric or shifted meaning). It also sets up the machine to pick the multipunch relay once the first key is pressed and to interlock further escapements (advancing columns).

The key on the 029 consists of two switch sections - one pole is normally disconnected but when pressed will route power to the multipunch relay. The other pole is normally connected to the circuit that holds the machine in alpha mode unless the numeric key is held down. When multipunch is pressed, it opens the line to the alpha relay, having the same effect as if the numeric key is pressed.

I only implemented the first pole, latching the multipunch relay but not switching to numeric mode. This resulted in the funny behavior, I theorized. I can take the two wires and relay currently used for the Clear switch and use them as the second pole of multipunch. Clear was not an essential function, it was a 'freebie' added because we had a spare relay.

However, the way the wiring works, we must be in series with the multipunch key second pole, All the other interventions are parallel, meaning if the cable is removed the keypunch operates normally, we just close a parallel set of contacts to the original key when we remotely operate it.

Due to the circuit layout in the 029, if we were to act in parallel to the numeric + multipunch pole 2 switches, we would block it from going to numeric mode - a failure. If we insert our relay in series so that our relay is normally closed, it will work properly and kick the machine to numeric during multipunch, but if the cable to our box is removed, the machine stays in numeric only mode - a different failure.

I can't see any clever way to implement this that is independent of the cable, unless I put a double pole relay down inside the keypunch to activate multipunch remotely; pole one in parallel with the key pole 1 and pole two in series with the numeric + multi pole 2. That would let me use one pair of cable wires to activate multipunch remotely, but it means additional changes must be made to a keypunch before it can be hooked to the interface. The upside is that we get our freebie Clear switch back because the relay and two wires are not needed - one circuit fires the remote.

The other option is a dummy plug that is put on the cable when it is not hooked to an interface box, the dummy plug bridging the circuit that is in series with the numeric + multi 2 switches. This requires less hardware but the user must remember to keep the dummy plug in place when the interface is not attached.

I chose the last method, rewired my keypunch and made a dummy plug up. This does not  preserve the two wires and relay for the Clear switch; we need it for pole 2 of multipunch. It has some rewiring necessary but that will be the normal instructions for modifying other keypunches.

Example of a dummy plug - although this is the wrong polarity. Need a male plug.
I put the modification in place, hooked up the interface, but I am still seeing the same problem - won't recognize card registration or allow punching. Letting the keypunch sit for a while and it works fine, but once I punch through the interface, the problem resurfaces. This happens with or without the read cable attached.

As far as I can see from the schematic my wires should be totally isolated from the other wiring, with relays connecting the circuits to fire various punch, space or release solenoids, and only one input which is my own magnetic reed switch with no wiring in common.

I have one small problem with single letter verb mode (i.e. allow M instead of MODE) that I will clean up, and it seems my parsing, storing and manipulating binary mode characters is flawed. However, my multipunch key functionality now works perfectly.

At this point, I suspect it is back EMF generated when the solenoids drop. This back EMF may be harming the keypunch, putting it into the problem state after some punching occurs and restoring itself with the passage of time. Fortunately, I had recently picked up a pack of 100 3A solenoids which are going to work out well for this purpose.


I varied parameters and simulated my driver circuit many different ways, but the outcome is always the same - it should work properly but the sample circuit I built didn't. At this point, I will rebuild a sample circuit and check again, in case there was a bad component or bad connection or other problem that invalidated my test.

After rebuilding the demo driver circuit and firing it up, the results were exactly as predicted by the design, totally unlike the poor results of the first try. Not sure what was wrong but I can drive the transmission line to 2.9+V for logical 1 and about 0.1V for logic 0. Since the margins for SLT logic are 1.8V high and 0.3V low, this will work well. It was designed for worst case resistance and I used a suboptimal set of twisted wires. Real world performance should be better.

I will now rebuild the receiver circuit with tested components and test it out, but my expectation is for both sides to work as intended. Somehow I let myself run out of solder, which is why I ceased operation tonight. Tomorrow, after resupplying, I will test out the demo receiver circuit.

Soon I will lay out the circuit board for the final set of drivers and receivers for my SAC interface. This board will convert all the incoming and outbound signals to TTL levels which I can readily manage with my FPGA boards.

I want to create a simple function using the interface - something to load and dump memory to a PC - which will just use (abuse) cycle stealing without the need for any XIO or interrupt routines on the 1130 side. That way I can stick diagnostics and sizeable test code into the machine in the interval where I am still fighting with the card reader. 

Sunday, October 26, 2014

Memory addressing card repaired, all memory operational, console printer surprise, and more keypunch interface testing


This morning, I finished up the installation of the 1053 onto the 1131, all closed up and ready to use. In order to verify that I didn't damage anything while manhandling the cover onto the mechanism, I entered a 1053 diagnostic routine into core via the console entry switches and began to test.

To my surprise, nothing typed. Not so surprising when I took a glance inside the top of the typewriter - the drive belt had broken. I was afraid that the rubber had dried too much for these belts to be trustworthy, and my fears were proven out. Why, however, did it have to happen immediately after I put everything together and checked this peripheral off as restored? Grrrrrrrrr.

Broken motor belt atop the newly reassembled console printer


I removed the card at gate D, compartment A1, slot M3, which is the address driver card which was faulty for addresses of the form '01100xxxxxxxxxxx', in  order to repair it if possible. I have a testbed to mount SLT cards, supply the three voltages they need, and to check out why the card is failing.

If the fault is in the discrete components on the card, a repair is fairly easy. I am hoping that it is a failed transistor, which has readily attainable substitutes that can be soldered into place. If it is one of the diodes or other parts inside an SLT module, the aluminum covered square modules on the card, it may be harder and more cumbersome to repair the card.

The card has eight IBM 131 discrete transistors, two 361457 modules (FTX - four 9V transistors) and two 361456 modules (AOXb - and-or-extenders), plus a multiresistor pack, a multicapacitor pack and one filter cap for the 8.3V. I am working out the wiring for this, between the general schematic in the memory ALD, the pin assignments and the card itself where I can trace out some of the connections.

Testbed to begin diagnosing the fault in the 5803467 card
A superficial examination shows all pins have good connectivity and all transistors appear to be working. The card only receives +6V for the address selection use, 8.3V for the FTX module and discrete transistors, and ground. No +3 or -3V supply is consumed on the card and the use of +6 is quite low, simply to bias the diodes of the AND function for the address selection.

I then checked the resistor and diodes of the address selection logic, which were all good. The card requires more than the usual SLT voltage levels and driving, which is why I didn't yet try to power the card and watch it operate. There is the 8.3V level for one part of the card, but it also requires a current source to feed the other half - it implements both the read driver and write gate circuit. I suspected it would take a bit of design and fiddling to get all the drivers and sinks. The 8.3V is trivial but not sufficient.

I next did some in-circuit testing of the transistors and diodes. They all operated as diodes with the correct voltage drop - treating the transistor as a pair of diodes sharing one terminal. However, when I tested the transistors as three lead devices - which gave me good results on seven of the discrete transistors but one of them was not altering the collector current as the base current changed. It was still just a pair of back to back diodes with a center wire. I had found my bad part!

It was totally consistent with the symptoms - this transistor was for addresses with bits 3, 4 and 5 of '100' which is where the problem manifested. It is marked as a Texas Instruments unit but numbered with IBM's house values - 131. I looked up some handy substitution charts that gave me a replacement type of 2N2696. This PNP transistor is not in current production but there are a few on eBay. However, it was a close enough match to NTE159 and therefore to the very common 2N3906 part.

I had some 2N3906 on hand and carefully removed the IBM transistor. Because the leads are soldered on both sides of the SLT card, removal of the leads and replacement through the cleaned out holes would take more heat and time than I wanted to apply to the card. It has thin traces linking those pads to other parts of the circuit, which might be damaged by excessive heat.

I therefore clipped the transistor off close to the can. leaving the three leads attached to the board. I formed up the new transistor to solder onto those leads and sit low enough to fit inside the card compartment without touching the adjacent SLT card. I soldered it in place, tested everything and then inserted the newly fixed card into the A1 compartment, slot M3.

Replaced transistor on repaired memory driver card (5803467)
I powered up the 1131, tested the formerly bad address range which now worked normally. I used the Storage Load and Storage Display functions (CE Switches hidden under the cover near the usage meter) to load and then check various bit patterns throughout all 16K words of memory. Flawless operation now!


I began further testing with the keypunch interface and found that although everything was working well initially, after doing reads, an attempted punch hung up and after this the keypunch was again refusing to recognize a card registered in the punch station. I need to understand this in order to make appropriate adjustments.

It didn't appear that I had any connections which could feed back into the keypunch. All the punch, space and other key/switch activations are done with relays, which remain open when dropped. I sense the state of the registration relay by a reed switch, thus I am uncoupled from any circuitry.

The only direct link to wiring is the set of read contacts at the dup station and the +5V I inject to the common plate to read the signals. It may be that there is a path I don't recognize from those, which should be totally isolated by the DUP relays as they sit in their dropped state. Further, when they pick, the disconnect all my wires.

If I have an error where I leave some of my control relays picked, it could cause a problem but I don't see any indicator lights inside the interface box which would glow when I am picking any of the sixteen relays.

I am going to do some studying of the circuits in the keypunch to see what could possibly be happening here.  In the meantime I decided to work on the memory card - results reported above.

Saturday, October 25, 2014

Console printer working correctly, plus minor work on keypunch interface and card reader


I worked the various levers, pawls and other parts of the carrier that are involved in escapement (spacing) and tab operations. As part of my investigation I noticed a crack in the carrier string pulley on the right side that maintains tension on the cord. To remove this as a cause, I replaced the part; no change in the behavior but better to have a good part in place.
Part with crack in white part, front left

replacement part that I installed
Interestingly, the mis-spacing occurs in the same spots, which implies some friction, bent parts or residue in the racks into which the pawls engage. I don't expect to find bent rods, but perhaps there is sludge on surfaces I can't see that are impeding the operation. If I hand-cycle the typewriter after pushing the space button, at the columns where I have problems, I can see it either fail to move at all or move half a column.

The half-column movement can be caused by the backspace pawl and escapement pawl being out of adjustment, so that it sometimes stops at the backspace rack tooth (half-column). I originally attributed this to sludge between the pawls which slide over each other and around any pivot arms. I have worked so much lubricant through this area that I am losing faith with the sludge hypothesis.

Another failure mode, also occurring in the same area of the machinery, is the failure of a tab operation to latch, which is necessary so it can slide rightward until a tab set tooth releases the latch. It is bouncing but not latching, resulting in a skip of a few columns - but not tab set exists at these locations.

Later today I worked the pawls some more, ensuring they all slid easily and independently. Now, with power applied, the spacing and tabbing seem very consistent. So good that I am going to close up the typewriter cover and consider this restored. Patience paid off.


The cornering station and ability of the stacker feed rollers to take the card away remain a problem. I did more cleaning, tweaking and attempted to adjust the pressure rollers for those stacker rollers. So far, it is no better. I was able to boot the cold start card from the reader and it appeared to be correct in core. There is a check condition at the end of the read but if the data got in correctly, I have to assume the problem concerns slowness in the card movement due to residual sludge. With patience, this will be corrected just as with the console typewriter.


With the interface cabled into place, the keypunch is being cantankerous about recognizing a registered card, sometimes leaving the keyboard locked so I can't punch on the card. Removing the cables restores the keypunch to normal operation, which means the cause is something happening within my interface box.