Wednesday, October 22, 2014

Testing new keypunch interface with IBM 029


I checked the behavior of the punch cable lines against expectations, prior to hooking up my interface box. Everything worked as expected except for pin 20, which was intended to be a 48V supply for the Release relay. It was not delivering power, which was a result of an inappropriate choice of SMS connector pin for the wire. I found a better pin, A08-E, and hooked to it. Now everything on the punch cable works properly.

I then checked the behavior of the read cable, although I didn't address the timing of when a column's holes are detected. I did see the power blip up whenever the chosen row had a hole. There is a hardware change I need to make to the interface box, to add 10K pulldown resistors.

Otherwise, the signals from the dup (reader) station float at high impedance when not powered due to a hole. On the Arduino, the detected logic level is indeterminate during the high impedance time, not a logical zero which we want. The pull down resistors will fix this.

I will solder the resistors into the box tomorrow, but want to do some testing today on the remaining functions. I hooked up the box and a terminal program to the serial port and ran it through some paces.

It is correctly detecting cable presence, card registration in the punch station and other status, plus correctly triggering release and clear switch actions. What it is not doing is punching - the relays are not energized long enough to fire the keypunch. I know that hand connection of the pins will fire off spacing and punches, but that is much longer than the 10ms that was used on the original interface.

I adjusted the duration to 20ms and will dial it up further if that isn't long enough to trigger a punch cycle. I expect this may be enough because the release key works properly, the difference in activation is 15ms duration for release and only 10ms for the other punches, plus the common power for the punches is interrupted by a cam while the release key is not.

At 20ms, the keypunch did exactly the same thing - nothing. If I didn't trigger spacing and punches by a jumper across the cable, which is what the relays do when they activate, I would think I didn't have the proper common power source. Since that was what worked with the jumper, and since I can hear my relays firing while the keypunch does nothing, I will ramp up the duration once again and see what happens.

Looking at the schematics, it appears that interposer bail contacts are the connection that fires off the punch and escape solenoids, however if that is true I don't understand how my jumper could cause punching and spacing nor how the original interface worked successfully. I need to do a bit more research on this.

Monday, October 20, 2014

New keypunch interface controller box tested extensively, ready to connect the 029 keypunch for final testing

It was a busy work day and tomorrow will be even more jam packed, but I did get some time to test the keypunch interface box.


I added in support for XON/XOFF flow control in a way that will protect us from deadly embrace problems and fits in cleanly with the logic flow. When we detect an XOFF from the user side, we flag the occurrence and will not pass along completed commands to be parsed and processed. We won't be sending any data to the user during the accumulation of a command line, thus won't overflow their buffers.  On our side, we are vulnerable to buffer overflow during the long duration activities when we are operating the keypunch, so we will send an XOFF at the start of command execution and XON at the end.

If the user terminal sends an XOFF to us in the middle of a command, when we are sending text with status responses or a card image in the case of a read, we might overflow the user terminal. To fix this would require us to write into a buffer and have a separate process emptying it subject to flow control. The impact of losing part of a status message is low, so we will accept this risk.

The card reading routine, however, could overrun the users receive buffer because of the 89 or 409 characters we will send as a single action before completing the read command. The Serial1.print() call will block until it can pump the last of the data into the 64 byte output buffer, which means we can't read the incoming serial stream to spot an XOFF.

If we could peek at the incoming serial buffer to spot an XOFF, we still wouldn't be able to stop the output in time. The Serial library in Arduino has no flow control - it will just pump out bytes until the buffer is empty. In order to guarantee successful flow control, we would have to institute a separate buffer for outgoing messages and pump it out by some method that would be given control in spurts to send out just enough to fit in the output buffer. Peeking at the receive buffer is also a challenge because the Arduino environment only gives us the immediate next character, not any behind it.

The user serial link issue was resolved - wire snapped in a harness inside my interface. I continued to debug code and clean up behavior. The relays appear to be operating correctly except for the row 12 punch relay which makes no sound. I will check that wiring. In addition, some of the relays sound but the signal LED on the relay board doesn't illuminate. Not sure if that is significant or just a flaw in the board. I will do some connectivity testing of the relay contacts before hooking up my keypunch cables.

After a bit of double checking, I discovered that one of the pin assignments was incorrect and that two signals were assigned to the same relay leaving the other relay disconnected. After making quick changes, I retested and everything clicked and lit as it should. Next up was a test of the DB25 cable connections to ensure that I am controlling each wire I expect inside the keypunch.

Everything checks out for the connections that are switched through the 16 relays. I also checked the pair of wires in each cable which are shorted to allow the Arduino to detect if the cable is connected or not. Finally, I tested the pair of contacts that hook to the reed switch detecting when a card is registered at the punch station.

The only part not tested is the reader cable which will detect the presence of holes in cards as they are moved through the dup (reader) station. Once I do a quick sanity check of the wiring in the keypunch, I will plug in my cables and run the diagnostics.

Sunday, October 19, 2014

1053 debugging, SAC interface circuit testing and good progress on keypunch interface controller


I hoisted the console printer up for access to the contacts and began to check continuity and operation of all the contact/switch units on the typewriter frame. Amazingly, given all the oxidized contacts in the rest of the machine and peripherals, everything in the 1053 worked properly.

Checking switches and contacts in the 1053
The erratic spacing has to be mechanical, therefore. I did some spacing with the hand crank wheel rotating very slowly to see the operation at the moment of release. I saw spots where the carrier did not move forward at the release, while in most spots it jumped promptly to the right.

While it could be a bit of sludge on the escapement and backspace rack teeth at the failing spots, I am still leaning to residual sludge between the escapement, backspace and tab levers keeping them from snapping back in place as they should under their spring tension.

I know that the tab should latch the escapement and backspace pawls out of the way until the carrier runs into a tab lever in some column that is set, which releases that latch. On some tab operations, however, I see the tab lever fail to latch so that it moves only a few columns over.

Since the latch is part of the stack of levers along with escapement and backspace, it reinforces the theory that it is sludge in the levers causing all these problems. Access is difficult without disassembling many parts that must be carefully adjusted upon reassembly.

Stack of tab, backspace and escapement levers, looking at tab lever on topo

Escapement and backspace rack teeth visible toward top, bottom pins are the tab stops

Another view of the stack of levers where I suspect sludge is causing problems


I deferred debugging the problem with the user serial link, due in part to the total ambiguity surrounding PC serial port links -

  • which of dozens of permutations of control lines are used (CTS/RTS/DSR/DTR. . .)
  • voltage (TTL versus true RS232)
  • cables (all wires, partial wires, straight thru, crossover, control signal loopbacks)
  • NL, CR+NL (a terminal program variation rather than link per se
Instead of attacking the link, I temporarily changed the input routine to use the USB serial0 link associated with the Arduino code upload. With that in place I could do quite a bit of testing of my logic. In some cases, I added temporary 'Serial.print' instrumentation.

 I have worked through quite a bit of the functionality successfully, other than the question of whether it does what I expect to the keypunch. Identified issues to debug are:
  • Punch command with more than 80 columns of data is not detected and truncated
  • Verify mode doesn't properly handle shorter card for punching than prior card being checked
  • Serial1 link is not working, no output displayed by my terminal program

There is still more to check, such as:

  • translation under binary and user table mode
  • proper loading of the user table, 
  • parsing of binary mode punch commands
  • verify operation correctness
  • keypunch function timing 
I put together a pigtail power connector to hook to the Arduino from the main 12V power brick, since it is powered by the USB cable at the present, but no USB cable will be in place when the interface is in normal operation.

One part of the spec is not implemented - XON/XOFF flow control - but that shouldn't be hard to add in as testing wraps up. No point worrying about it until I get the user serial link working.

Later in the evening, I worked on the code and resolved all the known errors except for the serial link which I am avoiding for now. I also tested the binary translation mode, entering punch data in binary, and related functions. Ignoring the serial link issue, the rest of the testing should be done hooked to the keypunch.


Initial issue when I began testing my SAC interface sample circuits, but it turns out I mis-selected all of the transistors. All I had on hand were some IBM 077 and a random NPN small signal transistor, not the parts I had simulated. The failing circuit was the driver which takes a TTL input and drives an SLT transmission line as output.

I will do some simulation with varying part characteristics later tonight, even though I plan to replace the current transistors with the part number I will use for full scale production. If I find tweaks that make it less sensitive to component specs, I will apply them. 

Saturday, October 18, 2014

Disk drive timer finished and installed, SAC interface circuits built, and debugging underway of the keypunch interface


I finished assembling the timer neatly into a plastic project box, with appropriate air holes to dissipate  the heat produced by the zener diodes, voltage regulator and relay timer board. One final test validated correct operation - roughly 105 seconds after the motor is switched on, the heads load when the timer circuit activates. It is now installed and the disk drive enclosure put together.

Timer circuit in its enclosure

Timer box in its final location

Everything closed up, front door in place


When I retrieved my power brick and powered the Arduino, it showed some pathology without being hooked to anything. Periodically, the Arduino would reset and start over, which I suspect is a power protection reset due to excessive draw by two relay boards fed from the Arduino.

I think I can take the 5V from the brick input and bypass the rest of the Arduino circuitry that is overloaded, although I might need to add my own 5V regulator on the power if I see any signs of sensitivity to power variations. I have to sort his out, but by removing the connection of +5 from Arduino to the relays and connectors, I can resume testing some logic for now.

I cleaned up code for quite a while with the 5V disconnected, but when I tried to open the user serial link to get into more serious debugging, it was clear that the serial port card I use also requires 5V. I had to separate out the connections from those for the power hungry relay boards and connect it individually before I could begin talking to the Arduino.

Next minor snag - the interface box has a male DB9 connector and the only USB-serial adapters I have also have a male DB9 connector. I found a female-female adapter but when I began testing it was clear that it was not a crossover inside. I need to have a crossover adapter or cable with female connectors on both ends.

The power brick for the Arduino is 12V, which is dropped to 5V by an onboard voltage regulator, so I will need to wire up a voltage regulator in order to feed the relay boards bypassing the Arduino onboard power system. I have the parts and began to build it, while ordering the DB9 adapter I need to continue testing.

Discovered that the relay board activates a relay on logic low input, not high. Reversed my logic and all was well. I changed the code controlling the relay signals to use an indirect value - PICK or DROP - rather than LOW and HIGH due to the potential for confusion because of inverted activation.

Set up the voltage regulator and an external 12V 4A power brick. Now that I have the right adapter and power to the system, I am still not seeing output from the user serial port nor getting any input into the system.


I breadboarded my receiver and driver designs for the SAC interface, but will postpone testing until tomorrow. I have to set up +3 and +6V power, some TTL driver and receivers, and then wire it into the SAC adapter for testing. I want to move carefully to avoid damaging the 1131. I will pick an interrupt request line as my driven signal and the corresponding int level active line as the received one - an easy pair to test with that don't require any other signals to be connected.

My board has twisted wires, similar to the twisted pair used in the IBM signal cables. My bench power supplies will deliver the SLT voltage levels and a digital trainer unit I have offers TTL level inputs and outputs. When all set up, I should be able to flip a switch, step the 1130 to have it enter an interrupt routine, and see the indicator lamp light reflecting the entry.

Friday, October 17, 2014

Disk drive timer final construction plus initial testing of keypunch interface controller


My new approach was to drop the 48V power, which switches on when the motor is activated, using a sequence of 4.7V 3W Zener diodes. The eight diodes bring the 48-52V down to the right level to feed the 7812 voltage regulator. The timer board activates its relay after 110 seconds, which disconnects the logic signal from ground to indicate it is now safe to load the disk heads.

This worked well in practice, so I began to install it into the system. The old relay is back inside the power box, but my wires take the 48V from those connections out to the new box I built. The plastic box contains a board with the zener diodes, the regulator chip and the timer board, hooked to the four wires I routed out of the power box.


I completed the Arduino code and began testing the unit. The first stage was to validate the basic communications link, startup process and first level diagnostic tests. Once done with that, made more difficult by failures of the Java code in the Arduino workbench which left my serial port unusable until the machine was rebooted. The port that failed is the basic link over the USB cable used to program the board, not the one that users will use for commands and data flow.

I now suspect that the USB port can't drive the power that the Arduino plus its two relay boards are drawing, thus it is going offline periodically. My power supply bricks for the Arduinos are in a side shed which would be inconvenient to look through in the dark.

Thursday, October 16, 2014

A lot of Arduino coding, some hardware prototyping


I received all my parts and began assembling the disk drive delay system that waits 90+ seconds after the platter motor spins before loading the heads. I gave up on trying to shoehorn it all inside the power box in the place that the relay itself had taken, instead placing the circuit into a plastic project box that I can put nearby to the power box but still within the 1131.

I wasn't happy with the performance of my first circuit after some testing. I will try a different approach. I certainly don't want anything that might dump the heads onto the disk surface too early.


I coded the remainder of the Arduino code for the keypunch interface today. While I still believe it would be better to add a signal from the keypunch when it is actually punching, both for validating proper execution and to time the release of the punch relays,

I implemented this with the timing based logic used in the original keypunch interface. For example, the punch relays are held for 10 milliseconds then released, after which I wait another 100 milliseconds for the punch cycle to complete.

I believe that the read pins in the duplicate station are active just after I drop the punch relays, which is how I coded the controller, but I can slide this anywhere in the 110 ms total cycle to ensure I capture the state of the holes at the read station while in the midst of punching at the punch station.

I have a small bit to change in how I handle the binary mode lines, otherwise this is ready to begin testing.

Tuesday, October 14, 2014

Working the last vestiges of sludge out of the gummed up 1053 printer and continuing the software development for the keypunch interface


I cleaned up and applied more grease on the carrier rails, then oiled other parts of the mechanism. It is still erratic and my suspicions are turning to the contacts and micro-switches that inform the adapter when a print operation reaches certain stages. With all the other contacts in the 1130 that had oxidized into permanent off switches, I need to check all the circuits for continuity.

I did notice that the right margin  and end of line detection is a bit erratic. From time to time it doesn't trigger the carrier return or index, just typing to the end of the platen and chattering away in place. This is likely to be sticky old lubricants as well. After some work with oil and exercising joints, it is much better, including a clear bell ring on reaching the right margin, but it still fails to trigger the CR once in a while. More work with lubricants, cleaners and repeatedly hand moving all the moving and sliding parts.


I completed all the command validation code, leaving just the execution of the commands to implement. By early evening, I had about three quarters of the execution logic coded as well. The main part still remaining has to do with when to fire the punch or space relays and when to release them.

I am looking for a means to determine when to drop the punch relays - I could use a fixed time but it would be better to watch something like the cam contacts which operate at fixed points during a punch cycle. I could add a wire to the punch cable, hooked to a reed switch around the escapement relay, which would give me a pulse right at the 180 degree point of a punch cycle just as the card prepares to move to the column that will be punched. However, I am not sure what happens during a multipunch.

Some scoping of the machinery and testing of code is probably necessary to get this to work as intended. I am going to write the final execution code with pseudocode in place of the timing delays or condition tests, allowing me to finalize it once I have done tests with the keypunch.