Virtual 1442 stacker select working, still tweaking punch and boot

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Debugging the virtual 1442 functionality

Two things left to test - punching cards and stacker select. I am expecting a very quick conclusion to the stacker select testing. What I still need to do is figure out the remaining defects in the punch logic in the fpga, then fix them.

 I also thought of some enhancements to make to the functionality. The first will close input files automatically when the last record is read. The second will provide an NPRO button. The third will act on the "last card" checkbox whenever it is changed, where the existing code only checks this at the time I open an input file. The fourth allows me to do a Program Load from 1442 with the first card interpreted in the special format for a boot card.

After an input file is open and I am reading/feeding/punching cards from it, when it goes empty the 1442 is made Not Ready, but the file is left open, waiting for the user to push the Input File button to close it. The close should be automatic when we empty the file. I will also try to include a signal that the hopper is empty.

An NPRO button will cause the 'card; that is left inside the machine in the pre-punch buffer to be discarded. I have a 'first time' variable that causes me to skip writing what is fetched from the pre-punch buffer on startup of the virtual 1442, since nothing is there until at least one card is read/punched/fed. Turning this on is the same as NPRO, but will only be allowed when the hopper is empty (input file closed), the same restriction as on a physical 1442.

I check and save the state of the Last Card while opening an input file, but should be moved to the point where I check this, when the input file was just emptied, to allow the user to select this behavior at any time up until the last card is being read/punched/fed.

My midday testing will cover:

• Diagnostics to track down punching malfunction
• Stacker Select function verification
• Test late selection of Last Card
• Test autoclose at end of hopper
• Test display of Hopper Empty status
• Test NPRO button functionality
• Test booting from 1442

In reviewing my punch logic in the FPGA, I realized that my spec for how to handle punching was flawed. Reading cards always emits 80 column interrupts on IL0 and requires 80 XIO Reads to be issued, but punching a card can be terminated by a special data pattern - turning bit 12 of the word on to indicate end of the punch operation. No more IL0 interrupts are issued in this case and the op complete interrupt on Il4 is given.

I misread the spec and thought that the word with the 12 bit set was not punched - that it just served as a marker for 'stop here'. I implemented based on this which is more complicated than it needs to be. The actual spec is that the word with bit 12 set also has punch data in bits 0 to 11, which are punched in the column first and then the operation is terminated. I had to fix my logic.

I am still not seeing the fault that leads to the incorrect data values sitting in the pre-punch buffer at the end of punching a card. I did put in some testing to check on where the error is occurring.I am never seeing the second column, row 12 value.

Stacker selection seemed to work properly, although I didn't run long enough to see the card image show up in the alternate file. I did run into an implementation issue in how I test the Last Card checkbox, in that my path to the GUI feature is not accessible from the 1442 worker thread.

Finally, I found the flaw in the logic for punching and am getting my five columns punched. There is an anomaly in the output file, with the character from column 1 repeated every 11 characters across the card. Since this is the stride of my USB transaction, I suspect a flaw in the logic related to fetching the newly updated pre-punch buffer, but need to study this more to be sure.

My early evening testing found the repeating character flaw mentioned above, the progress on punching, and showed that even though I am setting the alternate stacker, somehow the card is not being written to that file. That turned out to be a simple omission in the Python program - I wasn't closing the second stacker file, only the primary one, so the in-core buffer of the card I wrote wasn't flushed out. Change made in advance of my next set of evening testing.

Before dinner, I ran another set of tests to check out the remaining functions. The stacker select function is perfect. The repetition of the first column character every 11 columns is occurring during the copy-over from pre-read to pre-punch, it appears, because I see if even when the XIO Control is only feeding cards from input file through the virtual 1442 to the output file. The data read into core is fine during reading, at least.

I tested the new Program Load (Boot) function and saw it load core with the 80 words, but a flaw in the Python program ruined the test. I will check the contents of core to see whether they look right, but I have overwritten the core area for read/punch data and the interrupt vector information, so I need to rebuild that before I can test the punch/copy issue further.

Design of Mirror 1442 Functionality

The virtual device adapter behaves like the peripheral it emulates as far as the 1130 and its programs are concerned, but uses files on a PC as the source and sink of data. A mirror device adapter, on the other hand, just 'follows along', shadows or mirrors what is taking place with an IBM device adapter built into the 1130. Real cards are being read or punched too.

The physical adapter in the 1130 controls the physical peripheral, in this case the 1442 reader/punch. It handles the XIO instructions, moves data in and out of core, and provides the sense status to the programming. The mirror adapter just observes what the physical adapter is doing, grabbing copies of the data and sense status as the physical adapter delivers it to the rest of the 1130. These copies are sent up to the PC to be captured in a file or other display.

There are use cases for a mirror 1442 adapter - to capture physical punched cards into a PC based file for use with the IBM simulator, for example. The restored 1130 at TNMoC in the UK could use the mirror adapter at times, as well as the virtual adapter when they want to use PC based files as the card images. Even though I don't have a current use for the mirror adapter, since my 1442 is not operational, at some point it will be convenient to have it.

Now that I have all the state needed to behave like a 1442, I should be able to follow along with a real unit and its adapter, snagging card images as they are read and/or punched. The changes shouldn't be too major. I will figure out how to modify my logic and Python code so that the user can select which of the two modes it should adopt - virtual or mirror. To be a virtual device, it needs to block the physical adapter, which I do with a jumper or switch. More on the design of the changes later - as soon as the virtual version is totally tested and final.

Implementing physical plotter (1627 equivalent)

The high speed link needs to be made bulletproof - automatically recover from any loss of sync. I am looking over the design to sort this out.