NEW KEYPUNCH INTERFACE DEVELOPMENT
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.
MAINFRAME CHANNEL EMULATOR CARD
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.