One nit and 1403 is complete

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Implementing virtual 1403 printer

I built the test for skipping, which I can perform on the 1130 to verify that my virtual carriage control tape works properly.  I have a sequence of skips to perform, based on the default carriage control tape image for my adapter, and will check that the resulting line number is correct after each one.

My first test this morning was bad due to operator error. I forgot that my skip list for the XIO Write is offset - channel 1 is bit 4, channel 2 is bit 5, etc. I reran with the proper command and the fpga and python behavior differed. The fpga is wrong.

I was at line 1 and did a skip to channel 4, which should have stopped on line 4 since there is a channel 4 punch at every line modulo 4 (4, 8, 12, etc). It stopped on 8 in the fpga based on the displayed line number. Next, I set it to skip to channel 1 and it stopped at line 2 per the fpga.

I need to validate the contents of the tape buffer first, which I can do with my current LED assignment from the fpga board. I can see the top five bits of the buffer - channels 1 to 5. If I do XIO Control (space one line) then I will successively look at all the buffer contents and can match them to what should be present.

While I am running that test, I have the fpga synthesizing a new assignment for the LEDS, to display the top five bits of the skip command issued (XIO Write with the data word bit 4 as top bit, bit 5, the next, etc). That will let me confirm that the search word is correct for the fpga process.

Immediately, I could see that the print line number in the fpga was NOT advancing with successive XIO Control (space one line), thus I was always seeing the same buffer word. That needed to be fixed in order to complete my test validating the buffer contents.

Defect found and fixed rapidly, so a mere 30 minutes for the toolchain process before the next test. Grabbed some lunch while it synthesized. With this, I found a defect in my Python code as it loaded the buffers, corrected it and got right back to testing (not needing the glacial toolchain for the fpga).

I discovered one oddity - the displayed line number from the fpga was one higher than the actual buffer contents and one higher than the place it was stopping. I will review the fpga code to repair this. I made one operator error again - when I set the skip word to go to channel 12, I put in 0x0010 instead of 0x0001, leaving the printer on line 10 and not line 66 as I intended.

However, a retest uncovered a timing condition in my XIO handling logic, with the low bits of a word from core arriving later than the higher bits and sometimes not being latched properly.  I changed my XIO routines to give a bit more time for latching and all is good.

Skipping is working properly, so I can run a final test to produce an intended output file and verify that it produces the desired output including everything being on the proper line number.  I had made the change to the fpga to straighten out the line numbers reported, but the line number assumed by the fpga is always one past the real line number. I just can't see why this is happening.