Thursday, October 23, 2014

Interface testing, some adjustments and improvements, but not yet done


It was another heavy work day but I did get a few hours in the shop tonight continuing to test and refine the keypunch interface. One of the issues I uncovered is embarrassing to admit. The reader cable is hooked to a mechanism that reads the holes in a column of one card in order to duplicate the holes in the following card sitting at the punch station. I will use it to read cards and to verify that a card matches what we punched one cycle before when it was going through the punch station.

The contacts that will be made when a hole is present close a circuit to deliver 5V back to the Arduino, but this only happens during an escapement cycle (moving from one column to the next). When the card is not moving the contacts are open. Connecting the contacts to the Arduino, whose input pins are in a high impedance state, means that we don't have a reliable signal from that input except for the contacts at the moment they are recording a hole. The contacts recording an unpunched location remains floating.

The right thing to have done, which I had to retrofit to my interface, was to pull the Arduino pins down to ground through a 10K resistor, which causes the inputs to sit at logical 0 except for when a contact is closed through a hole, pulling that input up to a logical 1 state. It is a big clunky, having to be done by splicing wiring between the reader cable and the Arduino to hook up a resistor, with the common terminus of all twelve resistors hooked to ground.

During my testing, trying to drive the keypunch, I was having to deal with the three cables loosening or pulling off the interface. This is because the cable ends inside the keypunch are not very long, requiring the interface box to hang down near the relay panel of the keypunch. The serial cable I am using to test is short as well, barely reaching up to the table of the keypunch where a small Surface Pro tablet provides a terminal that I can use for testing. The motion of the keypunch mechanism and the precarious hanging position of the box caused many cable disconnects or flaky connections.

I spent about an hour working on the mechanical aspects of the interface, particularly the two DB25 and one DB9 connectors, to allow me to securely screw down the cables that attach to it. With that done, I could restart my testing.

I found right away that it would trigger a punch just fine with the 10 millisecond pulse I originally designed in to the program, but something goes wrong that causes the Arduino to reboot after it punches one column. It may be a vibration issue or a loose power connection - I ran out of time to explore the cause - but there is definite progress and some confirmation that the interface will eventually work satisfactorily.

It is now late and I am too tired to keep flogging away at the testing. Tomorrow and the weekend is when I will get back to this task.


I have an IBM emulator card that was used with their PC based mainframe offerings - XT/370, P/390 etc - which would let me communicate with any bus/tag based peripheral. In addition to the card, I have a cable which has bus and tag connectors on two ends and a third end that plugs into an IBM emulator card. To make this work, it has to be put into a working PC and it needs the driver software.

I don't have the driver software, but a friend does have it and is willing to sell the disk to me. There is a better than even chance that it won't work, since there are a few versions of the IBM channel emulator card, each with its own version of the software. I already know I have another challenge, because the cable set I have uses a connector with four rows of twenty pins, but the emulator card has a longer and thinner connector with only three rows of pins (but more pins on each row).  If I can figure out what the three row connector assigned for each bus and tag signal wire, I can make an adapter. However no guarantees.

Then of course I need to set up an old IBM PC with a microchannel bus, which is the bus type of the emulator card, which brings some additional complications I am sure. I don't have a current device that needs a bus and tag connector, but it will be a handy testbed to support any peripherals I might get in the future. More of a speculative activity than most of the tasks I am undertaking, so this will sit at bottom priority and may take quite a while to be finished.

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.