Virtual 1442 testing going well, beginning to wire up the 1627 plotter device

The 1130 has behaved itself for the last dozen times I have powered up to test - no sign of the misbehavior leaving it in reset or in single memory cycle mode. Fingers crossed it stays this way.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Debugging virtual 1442 card reader/card punch functionality

I spotted a flaw in some logic related to the copy-over and corrected it. In addition, I changed my diagnostic LEDs to help me further debug the copy process. With these changes made, I went out this morning to the machine and tested. Alas, no progress in seeing the previously read cards copied over and fetched successfully.

Since I was looking over the Python side code, I completed the alternate stacker support. Now, when opening an output file for cards that are punched (or just exiting into one of the two stackers), I open both the chosen filename and one with 'alt' appended to the name. When writing a line, I check to see if the user has issued an alternate stacker command via XIO Control after the last feed cycle completed.

My diagnostic lights show that bit 5 of the word for column 2 is on for the first card and then off for the next few cards, when monitoring the input to the pre-punch buffer memory. My copy routine runs through to column 80, another indication all is good, plus the main feed FSM finishes the IO. If the write signal is enabled properly, then it should have saved the proper words in the buffer.

And . . . of course, I wasn't enabling the write signal properly. Found the defect and corrected it, so after the ten minutes of glacially slow Xilinx processing I can test once again. I expanded the testing a bit, thus finding several flaws to work on:

• Still get zero output - also not certain the data is locked into the pre-punch buffer
• If I close a card file and open a new one, something goes wrong with the read
• If I try an IO with the card file closed, I get a DSW of 0x0000 but should be 0x0001

The middle problem is definitely in the Python code. I see the Python code pushing the 0x0001 down to the FPGA so the last problem is going to be in the fpga logic. More diagnostics will help me figure out the first problem.

After some changes, I began to get data fetching out of the pre-punch buffer at the end of the second feed cycle (the first cycle producing a blank card). The data was partial - the first 11 columns were zeroed out but the rest of the card image matched.

On the next (third) feed cycle, I should be seeing card two's data but instead got a mix of the earlier data. I am not sure where this is getting corrupted. My diagnostic LEDs only show me a few bits, not enough to spot this, but at least on the input to the pre-punch buffer, for its copy, the data was not the zero values I see from the Python program.

The Sense of 0x0000 given with a not ready device is still occurring. I see a need to ignore any XIO issued when the device is not-ready, rather than sending it to the Python code for processing.

The problems at this point:

• corruption of data fetched from pre-punch buffer
• failure to see the not-ready status with an XIO Sense DSW when the input file is closed
• XIO issued to not-ready device still triggers the feed FSM and will resume as soon as I ready a new input file, without an XIO being issued

I developed and implemented a fix to ignore the XIO commands when the device is busy. I also put in a diagnostic LED to show me the not-ready status, to be sure it is being set and reset properly. This will be tested on the next round on the machine.

I looked carefully at both sides (fpga and Python) when I push the input file image to the pre-read buffer and when I fetch the pre-punch buffer contents back to the PC. As a diagnostic aid, I will latch up the first column of each card as it is copied out of the pre-read buffer.

Midafternoon saw my next power-up of the 1130 to test the changes and examine the diagnostic output. I am seeing the LEDs light when the not ready bit is set, but it isn't being written into the DSW when I issue a XIO Sense Device. The other bits are written properly - this is very odd.

My diagnostics show me pushing each card image in turn down to the fpga, but after I write the pre-read buffer the first time, it is never updated. Some FSM is hung up and thus blocking it. LEDs will show me the state of the various FSMs.

I did test with XIO Control for a feed, as an alternative to a read. They should work the same was as far as pushing the data into the buffer, the buffers copying from read to punch, and the fetch of data coming out. The only different is that we will not trigger IL0 to ask for reads, but will give a final IL4 with an operation complete status. Works fine.

I was not happy with my hopper empty logic in the Python program, nor the last card work, so I will rewrite this tonight to make it more elegant and reliable. When I open each file as an input deck of cards, I seek to the end and record the byte offset of the end of the file. That is what I can check after the read in each feed cycle(read, punch or feed), before I push in the card contents to the pre-read buffer.

As I look at the last card in the file, I will push it into the pre-read buffer, and if the last card checkbox is on, I push the last card bit down to the DSW to be returned when this feed cycle end. What I do at the end of the feed cycle - where I process the fake XIO IR operation - is always to set the device to Not Ready since the hopper has run out, either because of reading the last card in Last Card mode or because it needs the next deck loaded.

Getting back to testing, I am still stymied by the failure to report the not ready bit in the DSW as well as the problem I am having with the copyover from pre-read to pre-punch. I am definitely getting the right contents into the pre-read buffer and into core memory when reading. Moving the data between buffers is where things are failing.

I gave up for the evening - having no clue how either of the failures can be happening. I will work on the last card and hopper empty code in Python tonight and take a fresh look tomorrow trying to find the problem in my logic.

Implementing physical plotter (1627 equivalent)

I loaded the Nexys2 board with its bitgen that drives the 1627, 1134 and 1055 device signals, in preparation for wiring up my interface box that makes the Strobe 100 plotter masquerade as an IBM 1627. I tried to test the high speed link but I had a wire break off the connector.

I rewired the high speed linkage connector tonight. I need to do the same for my six plotter signals and a ground connection. Once I get the connectors all sorted out, I can begin testing.

Implementing physical paper tape reader/punch (1134 and 1055 equivalents)

The slave Nexys2 board is now in place so that I can wire in the paper tape reader and paper tape punch for my testing. I will wait until the 1627 is verified before I test these.