Working on both virtual and real 1442 card reader/punch units

1442 CARD READER/PUNCH RESTORATION

I built up more of the Bondic material around the punch wheels in preparation for rounding it off to just below the wheel circumference. Once prepped like that, I can make a slurry of grit and Bondic, spread it thinly on the repaired section and harden it with the UV light.

I am going to need a very good jig to hold the wheel, turn it through the arc where the wheel is damaged, and to guide the grinding/polishing tool to the precise radius I want. I need to design this and then build it.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Implementing virtual 1442 card reader/punch

I have a big decision point about how I will implement the 1442 support. There are two possibilities:

1. a virtual device using files on the PC
2. a mirror device that grabs card images read or punched on the real 1442

The 1130 system has the adapter installed for my 1442, so that it will respond to XIO instructions and respond with status. If it is doing that, all I can do is to mirror what it happening with my logic, grabbing the data as it flies by. In order to take choice one I would have to tie down the line that signals the adapter that an XIO is addressed to the 1442 address (area code 2).  Mirroring is easier but less useful since I still have problems getting the 1442 back in operation.

Major reasons to implement a mirror device using the real 1442:

• Ability to read real decks of cards I own
• Ability to punch out real cards

Major reasons to implement a virtual 1442 device and disable the real one:

• Can move virtual decks between the real 1130 and the simulator on a PC
• Can move ahead before I get the physical 1442 working

The choice gets easier when you consider the following:

• I have a Documation reader that can read cards in and use them on the PC
• I have an 029 keypunch with a modification to let me punch real cards from PC files

The two facts above eliminate the major advantages of a mirror device implementation. Therefore, I will build this out as a purely virtual 1442 reader/punch and stick a jumper into the 1130 to tie down the 1442 adapter so it does not respond to its address. That allows my logic in the FPGA to step in and respond to 1442 commands.

I have implemented the logic in the FPGA that allows the Python program to push down a card image into the pre-read buffer, wait until the punch or read operation is complete and then fetch the punch buffer contents. This is a feed cycle with or without the read/punch.

The Python program feeds the card images by reading them from an input file, and will add the card images coming out of the punch buffer to an output file, if it is opened. The way I handle stacker select is a bit funky, but it was easiest considering that using the alternate stacker is somewhat rare.

A SS XIO Control operation is issued after one receives the operation complete interrupt for the prior XIO Control start read, start punch or feed operation, but before card travel has completed. In my flow, I have already written the card image to the punch file by the time I get the SS request. It is easiest for now to just punch a special record afterwards that indicates the prior card image goes in the alternate stacker. I can use the Deckview utility to move those card images to their own file, as a post-processing step, if it is ever needed.

There is an alternative I see, but it adds some complexity including the need to maintain separate output files for both stackers, update the GUI for both file open buttons, and so forth. To make this work, I would save the position of the punch output file ('tell' operation on the file) before writing each punch output image. If a subsequently got a SS command, I would back up the main output file to its previous point, erasing the card image I added. I then write the saved card image to the alternate output file.

The remaining implementation details are in the FPGA, including:

• moving the pre-read buffer contents to the pre-punch buffer at operation complete
• a read FSM to fire off 80 IL0 interrupts, wait for the XIO Read and latch the column data
• a write FSM to set up the column data, fire off 80 IL0 interrupts, and wait for the XIO Write
• a master FSM to spot pre-read loading, trigger the read or write FSMs and send fake XIO IR
• make sure the IL0 and IL4 state flipflops are modified to suit the new approach

At lunchtime, I built the read and write FSMs, along with the master FSM. The read and write FSMs also enforce timing simulation to deliver approximately the real throughput of a 1442 model 7. That means delays before beginning the IL0 interrupts for columns and then the proper timing between columns to match the 400cpm of reading and 120 cpm of punching.

I didn't have anything complete enough to test today so I continued developing logic and refining the Python side until this is complete enough to begin testing.