Almost finished virtual 1442 card reader/punch testing, beginning testing of the physical 1627 plotter

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Debugging the virtual 1442 functionality

I began the day wrestling with two major problems. First, the DSW stored when my 'not ready' bit is set is all zeroes, not 0x0001 as it should be. DSWs with the read, punch and operation complete responses work properly. Second, the data I correct load into the pre-read buffer and correctly read into core memory is not correctly copied over to the pre-punch buffer.

I finally spotted the error in my process to copy over the buffer contents from pre-read to pre-punch stations. I initialized the index to 0 at power up, incremented it while cycling through the 80 card columns, but never reset it to 0 when I went back to the idle state waiting to copy over the next card image.

This leaves the mysterious issue of the not ready bit which does not appear in the DSW but should whenever I don't have a input file open on the PC. I suppose this could be something that effects the low bit, either spurious trimming of the signals by the untrustworthy toolchain or a hardware flaw that just arose in my interface box.

When I did a quick test, something hung up so that I couldn't do a second card read operation. Since I just changed the copy routine, that is the logical place to look. I checked the state of the diagnostic LEDs to help illuminate the condition of the system and point at what might be awry.

They showed me that the FPGA FSMs were all back to their proper idle positions, but the Not Ready but had been set for the device. Turns out the flaw was in the Python code I changed to handle hopper empty - it was treating the hopper as empty right after the first card. A quick fix and I could get back out to test.

In support of the missing DSW bit, I added some recognizable bits to the DSW and watched what was stored. The testing at lunchtime showed that my copy-over process is working correctly and the data being picked up by the Python program at the end of a fetch cycle matches the card image two back in the input deck. However, the image in the output file is distorted. I appear to have everything shifted over by one byte, so that data belonging in card column 1 shows up as column 8. Clearly a Python side problem.

The DSW stored for column (IL0) interrupts had both bits 12 and 13 lit up, which were the two I added to the DSW as a fixed output. However, the DSW stored for the operation complete (IL4) interrupt had only 12 lit. When I tried an XIO Control with the virtual device Not Ready, the DSW returned had only bit 12 lit. Something is trimming the bottom four bits from my returned DSW for both IL4 and later, but not on the column interrupts. Could also be a timing issue for the XIO Sense DSW logic. More investigation is definitely needed.

I worked on the Python program for a bit, found and changed the code which shifted the hole patterns off in the output file. My testing in the late afternoon showed that the new output file is still messed up, just differently. I suspect this is a combination of endian problems and other defects, but will have to keep working on it until I get it working properly.

I changed the length of time that I held the write gate and write data lines up during the XIO Sense Device module process, which fixed my problem with dropped Not Ready bits. Instead of dropping as soon as the 1130 gets into T6, I wait until I enter phase A of T7. This needs to be carried over to other XIO modules which write to the 1130 (XIO Sense ILSW and XIO Read).

Remaining problems or subfunctions not yet tested to satisfaction:

• fetched words from pre-punch buffer are stored correctly in 1130 simulator binary format file
• Stacker Select causes next card to go into the alternate stacker file
• Start Punch will successfully punch the contents of memory into the pre-punch buffer
• Looping to a last card in a file results in Not Ready after last read, if no Last Card selected
• Looping to a last card in a file results in Not Ready after last read, plus last card bit in DSW at end operation, if Last Card was selected
• Loading a new file restarts properly from Not Ready

I got the Python code to properly load the fetched words from the pre-punch buffer into the output files on the PC. I also tested that a loop will properly detect the last card of a deck, but it triggered a code defect that I have subsequently repaired.

In the early evening, I went out to test:

• loop detects last card and it is read into core properly before 1442 goes Not Ready
• restart of a new deck (input file) after reader exhausted previous hopper to Not Ready
• loop runs with Last Card on and returns proper DSW on operation complete
• feed only cycle copies deck over correctly input to output file
• blank input file and punching produces proper output file
• dirty input file and punching works
• punch with short count works

The loop detects the empty status but my Not Ready is not showing up unless the file is closed - this means my Python code is not pushing the DSW update. Same with the Last Card run (3 above) likely for the same reason. I looked in memory and it didn't match up properly with what card image I should see. I need to fix the problems I see before going back to the tests.

The behavior that I can't match is when the 1442 is readied with new cards (e.g. first card is in pre-read buffer) and the first operation is Control for Start Punch, the 1442 will trigger a dummy feed cycle first. That would require a copy-over of the pre-read to the pre-punch buffer.

Instead, if the XIO Control for Start Punch is issued right after startup, the punching will take place into the pre-punch buffer as if the card were completely blank first. If the purpose of the job is to take a card with partial contents towards the right side of the card and the program wishes to punch data in earlier columns, it will be off-by-one from the presumed deck. order. This can be fixed operationally by running in a single blank card file first.

If the program is going to read cards and then punch into the first part of them in the next operation, this will work properly since the Start Read will result in the data from that card moving to the pre-punch station where a subsequent Start Punch can overwrite columns (up to 80 depending on length of the punch field). I don't understand how the device could read card 2 as well as punching in card 1, as both operations will trigger a feed cycle. More study is needed to see if this is possible and how I might mimic it.

Implementing physical plotter (1627 equivalent)

I began wiring up the connector for the 1627 adapter box this afternoon, allowing me to move on to testing the Strobe 100 plotter acting as an IBM 1627 to XIOs from the 1130. With the connector done, I hooked up the fast link and powered up the combination (SAC Interface Box, slave fpga, 1627 adapter box and Strobe 100 plotter.

When I brought up the system for my 1442 function testing, I also had the 1627 gear ready. It showed the expected values for the plotter and when I fired off a single XIO Write asking for a move to the left, I saw the plotter move to the left one step. However, there is a timer loop that seemed to be running way too long and inverted status of the movement signals.

It was a good first step in testing, but some fine tuning is needed. I will get to this when I go back to testing the 1627, but have to prioritize finishing up the virtual 1442.

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

There are status signals that I have not yet assigned or routed, which will tell me if the 1134 or 1055 is not ready. I need to work this out, make changes to both the core and slave FPGA logic, and then begin soldering up the connectors.