Good progress on virtual 1442 card reader

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- virtual 1442 --

I can see the cause of the error I last detected, where all 80 columns of a read card have the same value. The FSM for controlling the read buffer is befouling the buffer address lines. I redesigned and recoded the section and went out to test. The test was not successful so I need to refine the instrumentation.

By this point, the push transactions complete for all eighty columns and the state machine moved on to the f1442 emit state. In that stage, the machine should loop through the eighty columns triggering 80 interrupts on IL0 and responding to 80 XIO Read commands from the test software.

I wasn't seeing the interrupts triggered, so I looked to the emitter FSMs for read and punch. I found a defect and corrected it, then went back to testing. The next run did indeed fire off the IL0 interrupts to request reads for the 80 columns. It also triggered the fake XIO Init Read operation which tells my GUI code to fetch the pre-punch buffer contents. The transaction timed out at this point so I first have to look at the logic to handle the get special data transactions for the eighty characters.

I did some more restructuring of the logic and set up traps to tell me what col 12 of the first card column is when the preread buffer is being written. Once I know it stores the right value, the next step is to see it present the right value during the column XIO Read, After this works, I can check that it fetches the same value out during the fetch once the read is done and it is being copied over to the pre-punch buffer.

The value delivered to the XIO Read is always a blank column, but my first test needs to be whether the card buffer is returning anything other than blanks. There is still the open question of whether the black box block RAM was properly included in the design, since there are messages:

Could not resolve non-primitive black box cell 'blk_mem_gen_0' instantiated as 'C1403CardBuff

Once the test pointed at a problem with delivering the retrieved value to the XIO Read, I moved the diagnostics to that point and looked again. I did see one other anomaly - I had a four card deck with last card enabled, saw four reads issued but didn't get the fake IR triggered for the last one. My logic for detecting the last card and acting on it is not working properly, and that is an error in the GUI not the FPGA. 

The GUI code to handle the last card situation was moved around to fix the problem I discovered. I will test this as I debug the basics of the read functionality. Now that I seem to have good values in the read buffer, the next area to confirm is how that data gets handed off to an XIO Read instruction. 

I see good values set up in the signal that should be gated into core during the XIO Read instruction. Not sure why it isn't working, will have to zoom in very close to see what is happening. After a minor change, I am getting all card columns reading into storage now, which is excellent. 

Unfortunately, I have an 'off by one' problem with the data going into columns. Column 1 of the real card shows up in columns 1 and 2 of memory, then column 2 of the card is in memory location for column 3, and so forth. Probably a timing issue in my FSMs. 

The physical 1442 has a hopper, two stations inside and a stacker. The stations are pre-read and pre-punch. My virtual device has a PC file as the hopper, two buffers in the fpga for the stations and PC files for the stackers. 

A feed operation (or a read or punch) takes a card image from the file and moves it into the pre-read buffer. The data that was in the pre-red buffer before the feed operation will be copied over into the pre-punch buffer. Data sitting in the pre-punch buffer will be output to the stacker files during the feed. 

Thus, once cycle of read or punch or feed consists of:

• fpga sees the XIO Control to start the read, punch or feed
• fpga notifies the GUI that an operation has begun
• GUI reads the PC hopper file and extracts one card image
• GUI pushes the card image down as eight 10-column transactions
• when the pre-read buffer is filled by the transactions, the operation begins
• logic in the fpga emits an interrupt on IL0 for each card column
• logic in the fpga will provide the data from the pre-read buffer to the XIO Read
• when the card has been read (80 columns or the count if less), the GUI is notified
• the GUI extracts the data from the pre-punch buffer and puts it in the stacker file
• the fpga waits for the extraction transactions to fetch all eighty columns
• the fpga copies over the data from pre-read buffer to pre-punch buffer
• the fpga signals operation complete via interrupt IL4

Thus, the data read from the file in cycle N may be read during that cycle, or it will move to the pre-punch buffer where it can be punched over in cycle N+1 and then ejected to the stacker. There is always one card sitting 'inside' the 1442 but not yet written out to the stacker files. 

The GUI compensates for this with a special first time card process that ignores the data fetched from the pre-punch buffer on the first card through the virtual device, since in cycle 1 there was nothing in pre-punch to come out the stacker. NPRO will reset that flag, just as it clears out the cards from the physical machine. 

I have a flaw somewhere in the logic because the stacker file output consists of 80 columns of data per card, but it is the last 10 columns of the card duplicated ten times. I don't yet know if this is a flaw in the transactions that fetch the pre-punch data or if it is a flaw in the copy-over process. I will need instrumentation to discover that. 

My current known problems with the 1442 virtual device:

1. Off by one error in columns delivered to 1130
2. Corrupted copyover or pre-punch buffer fetch
3. Handling of the last card is still wrong - setting not-ready status at wrong time
4. Emptying hopper file results in GUI python error due to defect in code

I will be working on these tonight with study and bench testing, but have no more test time today on the real hardware.  In addition to the known problems and any new defects I discover, I have not yet tested card punching, feed only IO, stacker select or Prog Load (boot).