V1442 card reading is complete, now focusing on punching and stacker select

COMPREHENSIVE SLT BOARD INVENTORY

I decided to list and total all the SLT boards used in my 1130, in order to recognize when a card on ebay might be useful to acquire. There are 80 different card types used in the machine and a total of 224 actual SLT cards spread across six compartments.

I only have schematics for less than half the card types in the machine. For those where I have a schematic, I can work out discrete components to repair a bad card, if I can't find a spare. For those without a schematic, if I can figure out what components are not working, I might find replacement SLT modules on some other cards or be able to figure out what is the schematic of just the SLT module (the square metal cans that contain a mix of transistors, diodes and resistors on a ceramic base).

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Debugging the virtual 1442 functionality

These are the remaining tests to sign off on the virtual 1442 function::

• 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

My read instructions are now properly setting Not Ready both when the last card in the PC file is read and on any subsequent XIO Sense Device, until a new file is 'put into the hopper'. If Last Card is checked when a file is opened, then the LC status bit is set on the XIO Sense DSW at the completion of that card.

Restart with a new file systems to work properly, at least as far as the virtual device being ready to read and the proper card contents arriving into core. The contents of the output files seem off by one, the contents fetched seem to match the new card read and not the prior card which would be exiting the pre-punch buffer. This needs to be checked and if it is occurring, the flaw must be corrected.

I did a punch of four columns, punching the hollerith for CARL into the front of the blank card image I loaded into the input hopper. However, it looks like the FSMs didn't work properly as the fpga was not ready to accept a new punch command. This needs a new set of diagnostic LEDs to help me chase down the problem.

To summarize, reading is working solidly including the not ready condition at the end of a PC file used as card input and the proper handling of the last card condition. I seemed to have some problems to resolve:

• I may be out of sync on the card images that appear in the output file as I read two decks, with a NR in the middle. This could be a problem due to next issue. 
• I might need an "NPRO" equivalent to flush the card image from the pre-punch buffer out, in order to see the last card. This will take some design work.
• Punching a short card is not working - not sure whether a full sized card would work better

After thinking about it, I realized that when I switched to testing the punching operation, I didn't fully change the software in the 1130. The punching of a card is begun by an XIO Control with the Start Punch modifier bit on, then it will receive up to 80 interrupts on IL0 to which it must respond with an XIO Write to send the holes to be punched. I left the interrupt routine with an XIO Read, not an XIO Write. Without the issuance of Write commands by the 1130, my feed cycle won't complete.

Rerunning the tests more carefully, including making all the changes to support punching, allowed me to run a full card punch and then several of the four column punches of "CARL". These all completed properly with a normal operations complete interrupt. I turned to the output files to see how I did.

I can see that when I run out of input cards, the last card that had been read is sitting in the pre-punch station and has not been fetched to put in the output file. When I open the second input file, making the virtual reader ready again, as I read the first call of the second deck, I get that final card of deck 1 into the output file. This isn't really a problem for reading decks.

On a real 1442, the input cards are placed in the hopper, but when Start is pressed on the reader it takes a feed cycle to put the first card at the pre-read station. Nothing is at the pre-punch station yet. If a punch operation is performed while the 1442 is in this state (no pre-punch card), the adapter logic forces another feed cycle first, putting the first card that was originally in the hopper into the pre-punch, the second card of the deck is now in the pre-read and the third and subsequent cards are still in the hopper.

When the hopper empties after a feed cycle (read, punch or just a feed requested), the final card that had been in the hopper is now in the pre-read station. The next to last card from the hopper is in the pre-punch station. The 1442 goes not ready.

If the operator pushes Start while the hopper is empty, the reader is ready again and another read can take place, moving the last card from pre-read to pre-punch and having ejected the N-1 card into the stacker.

If the operator then wants to remove the final card, the operator pushes the NPRO (non process runout) button to force feed cycles until nothing is in either pre-read or pre-punch stations. The last card is now in the output stacker.

If the operator did not push Start with an empty hopper, then the program reading or punching cards is paused waiting for the 1442 to go ready again. Placing the next deck of cards in the hopper before pressing start will switch the device back to ready so that another read/feed/punch can occur, but no "last card" status is reported. Things resume, with the last card of the old deck read and moved from pre-read to pre-punch, the N-1 of the old deck moving to the output stacker, and the first card of the new deck moving into the pre-read station.

I don't have an NPRO equivalent and probably don't need it. If reading a deck, I don't care if the last card makes it into the output file. If punching on blank cards, the punch operation is completed by fetching the pre-punch buffer thus that last card is captured.

I did see that the punching is not working properly - specifically I have all blanks in the output cards even though I am attempting to punch non-zero values. Although I haven't explicitly tested the Stacker Select operation of XIO Control, it is pretty simple so I will do this when I wrap up whatever I get the punching fully fixed. I figured out some diagnostic LEDs and data I can watch to figure this out.

Found the first flaw and corrected it, then went out to test. Something not right yet, as I got a card with C and a bunch of spaces, then the same group repeated several more times across the card. Also tried the stacker select, which didn't work because I miscoded the test in the Python program. Fixed and ready to test, once I figure out the punching problem tomorrow.

Testing physical plotter (1627 equivalent)

I saw a couple of instances where the slave Nexys2 FPGA board got out of sync with the master ztex board - I need some form of error recovery to get these working together again. I also will swap the polarities of the control signals to the plotter so that if the slave board is not yet talking to the master, the resulting signals to the 1627 make sense (e.g. they are all high so they mean no operation).