Last controller logic to debug in VCF 1130 is the 2501 card reader circuitry - but no card reader here

MY PREFERENCE IS TO HAVE DEBUGGED ALL OF THE MACHINE BEFORE RETURN

Since the VCF has a 2501 reader in their museum, it is feasible that it will be restored in the future and connected to the 1130 again. For completeness sake in this restoration, I want to have everything working that could possibly be used in the future. 

The museum in New Jersey has an 1132 printer and a 2501 card reader, both of which are configured into this 1130 system. I completed testing of the 1132 printer logic, as well as the keyboard, console entry switches, and console printer. Once the disk drive is restored I will validate its controller logic which leaves only the 2501 that would be undone.

OPTIONS CONSIDERED

One possibility is to have the 2501 delivered to me in Florida where I can restore it then test the controller circuits. That would be expensive to hire a truck and drive it or to have a shipping company deliver it. 

A possibility is to defer the checkout until the future when the 2501 is restored and do the testing up in the museum in NJ. That separates me from much of my equipment and supplies that would be needed to test and repair parts, plus it involves an extended time away from home.

The choice I am leaning toward is to emulate the signals from the 2501 sufficiently to verify the operation of the controller logic. The interface is 26 inputs and 11 outputs. A few of them are unimportant - usage meter operation for example. I do have enough technical information to correctly emulate the timing of signals so that the controller believes it is dealing with a real 2501 card reader. 

EMULATION BROAD DESIGN

Parts of the testing are not timing sensitive and can be done immediately. Triggering the signal that the Start key was depressed, for example, should trigger the activation of the motor relay. Setting other signals should trigger the lighting of the indicator lamps for conditions such as Stacker Jam. 

The bulk of the testing would need to simulate very specific timing of signals. Whenever the motor is running, three pulses are emitted per revolution of the timing wheel at fixed degree points. These are related to the movement of cards in the machine and the time when certain photocells would detect light or dark. 

Emitter pulses are produced based on the timing of when a card edge is detected by a photocell and at a fixed frequency. The logic samples the state of the row photocells at specific times based on the emitter pulses.

When the feed and hopper solenoids are engaged the movement of a card will produce a change in the card lever 1 photocell in the pre-read station. It goes dark when a card is fed in from the hopper and it sees light when the card begins moving through the photocells (or when there is no card in the pre-read station). 

A simple device can produce the pulses from the timing wheel continuously. A second device could produce the emitter pulses and also control the row photocells to inject desired card contents. A third could produce the card lever 1 output based on timing from the issuance of feed and hopper solenoids. 

All of these could be combined in a single FGPA based board, one that had almost 40 input output pins. They could also be done with separate Arduinos or other simple microcontrollers. The key decision would be time to design and test, as well as availability on hand of the parts I need. 

Interfacing to the 1130 involves open collector gates to drive the 26 inputs and due care connecting the outputs since IBM circuits can involve strange voltages outside the safe range of the inputs of the devices I might use to build the emulator. 

Technically, the pushbuttons (Start, Stop and NPRO) and a few reader microswitches (stacker full, hopper empty, cover open, and motor running) involve delivering +12V which is pulled down to -3V by the switch debouncer when the button is not pushed. I could use relays or other isolators for these inputs, but my first tests will inject the result into the controller logic after the debouncer circuit. Once the tests with the bypassed signals are over, I could verify the three debouncers easily.