virtual 1442 reader and punch working properly, moving on to other testing and work

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- virtual 1442 --

Eureka! I have the copyover (mostly) working now and the off-by-one problem is gone. Unfortunately, I have regressed to the problem where the first column of the pre-read buffer card is copied to every tenth position of the pre-punch buffer, replacing what belongs there. This was an error in my copyover logic that has returned now that I rewrote it completely.

I also have a minor error with the write special data transaction where I wasn't returning word 2 as it had been sent, but that was easily rectified by a snippet of code. Otherwise, this transaction has been working properly for some time.

Once I clean up the every-ten-overwrite problem, I can start debugging punching operations. I need to test with a blank deck of cards (input hopper file that is all blanks), punching a full card and then a short one. The 1442 will check each column being transferred for punching and when bit 12 is on, it ends the punch operation.

If blank cards work fine, the next test is loading a file with data already in the cards. The result of punching should be a merge or row-wise OR of both the original card and the new punched pattern. This will be checked for both full card and short card punching.

The tenth position error is the first word of each get special data transaction, which repeats the value in column 1 rather than starting over with the value in the column 10, 20, etc. It is caused by a lack of adequate time for the pre-punch buffer address to set up from the value delivered in the second word of the incoming transaction, so that it still uses the default value which is column 1.

I added another cycle between the startup and when I latch up values, which should give the buffer address time to settle on the actual start cycle. My next testing opportunity in the late morning showed that it was now working just as planned. Whether reading or feeding, the card images were faithfully copied over and then written to the stacker file on the PC. If reading, the columns were faithfully stored in memory.

Onward to the last items to test - punching cards and the stacker select function. My first try at punching cards did not produce any results. My guess is that the pemitter process didn't work properly, hanging up and keeping the main device process hung as well. I instrumented the LEDs to check various status signals and ran a test after lunch.

It confirmed what I suspected - the main device state machine got to the point where it triggered the punch emitter process, but that process hung. I did see that a punch operation was correctly recognized. Looking closely over the punch emitter process, I found two problems. Both were related to the timing that emulated the delay of a 1442 punch.

I had set up a counter to model the time of the card movement during a punch, but initially the times I used were the same as reading. The punch is considerably slower than reading, however, so that eventually I calculated the correct counts for the timers. I did not increase the size of the counter.

The counter would run from 0 to just over 1 million, which could model a 20+ millisecond delay. In fact, punching incurs an initial delay of 40ms, so I changed the test in the state machine to 2000000 yet the counter only went up to 1000000. It wrapped and cycled in an infinite loop.

The secondary bug was that I didn't reset the timer back to zero before modeling the 6.25ms per column delay, so it would have run from 2000000 upwards. I didn't reach this point because of the earlier bug and infinite loop.

I changed the timer to run up over 2 million, to cover the initial 40ms delay, and made sure to reset the timer before each column delay and before the final delay for card movement out of the punch station. With this changed, I went back to testing on the 1130.

I got punching over the blank card images. My only problem is that the results were off by one, which means I have to focus on my logic for the XIO Write and pre-punch buffer accessing. This is very encouraging, as I realize that I am pretty close to done.

I ran a quick test with bit 12 set on in the 10th column, just to verify that it will punch a short card.  It did, off by one of course but otherwise correctly stopping and leaving the remaining 69 card columns blank. All that is left to verify is:

• get it aligned to the right columns, 
• verify the punch merge function
• verify the stacker select function

Punch merge is a realism behavior I added which will combine the holes already existing in a card coming from the pre-read station with the rows that are punched during the punch operation. If a card deck were put in the hopper of a 1442 that had row 12 punched in all 80 columns, and the program were to punch row 3 in all columns, the resulting physical card would be a string of C characters (rows 12 and 3 punched in each column).

Stacker Select is a function that a program can issue (XIO Control with bit 8 set) that will arm the stacker mechanism so that the next card coming out will be ejected into the alternate stacker, rather than the primary stacker. I open twin output files, once for the primary stacker and another for the alternate, so that if the stacker select function was issued, I will write the card image to the alternate instead of the primary file.

Card movement in 1442

The Stacker Select is not completely accurately modeled. It should only take place during the time that a read, feed or punch is active and before the card would have reached the stacker pathway. It is reset by the completion of the feed, read or punch cycle. My implementation, however, will arm the code to put the next card ejected by punch, feed or read into the alternate stacker, no matter how long the time from select issuance until the actual card movement occurs.

The reason for my off by one problem is that I was triggering the write into the pre-punch buffer from within the print emitter loop, which only determines when we set off IL0. It is the subsequent issuance of an XIO Write instruction by the software in the 1130 that determines the column contents, so I will trigger the write of the buffer as soon as I grab the data value from the E3 cycle of the XIO Write instruction.

Problem solved. Punching reproduces the core contents exactly into the cards and short punching works correctly also. Time to check over the logic for punch merge and for stacker select, then do the final testing. Everything looks ready for punch merge, but it needs testing.

I discovered that my logic in the GUI that was checking which type of XIO Control was not working properly, apparently I am not sending the proper data up from the FPGA. Inspecting the code makes it appear that I should see the proper modifier from the XIO Control, but the results differ in real life.

My late afternoon testing was to test the punch merge operation, which would take a hopper deck with known contents and a prepared punch area to see if it merged properly. In addition, I tried out the stacker select operation.

Everything worked perfectly. When I open a file for the input hopper that already has holes punched in the cards, they are properly merged with the holes being punched by the program. Stacker selection causes the next card to be fed, read or punched to go into the alternate stacker file on the PC, rather than the primary 'stacker'.

This wraps up the virtual 1442 capability. Later, after I get my system back home, I will work on the mirror 1442 capability, which will capture cards as they are read and/or punched on a real 1442, storing them in a PC file. I don't need this, but it will be quite useful for other 1130 operators such as the National Museum of Computing in the UK.

-- virtual 2310 --

I attempted to test a boot of the virtual 2310 disk drive, using a cold start card booted from the virtual 1442. When the cold start code began, it stopped with the keyboard select lamp illuminated and an interrupt on IL4, which is definitely not what should be happening. I created a memory load of the boot card, just for convenience, as I chase down this flaw.

One possibility was that I have a defect in my mirror device logic causing it to interfere with the real device operation. The boot card reads from the console switches to decide which drive is being booted, so if this is inducing an error while the XIO to the console switches takes place, it might explain the symptoms.

I decided to hand step the boot card logic to see when the problem arose. The logic of the boot loader is to check that the busy bit went on for the drive, otherwise go to the invalid boot device wait at 001E. Single stepping will cause this to happen, even if the disk is valid, because the XIO Sense happens after the I/O is complete.

I have to verify that my logic is setting busy correctly and holding it long enough to be seen by the boot card program. Inspection of the program shows that it is not accurate as far as a disk read or write is concerned. I will display busy during a seek, but when the operation is a read or write, I shut off busy as soon as the XIO IR/IW completes, not when the disk is done. Will have to modify the design a bit. This is what I will be testing starting tomorrow.

CLEAN UP MACHINE COVERS IN PREPARATION FOR MOVE AND EXHIBITION

I replaced all the internal cosmetic covers in the 1442 - these are plastic plates that cover various parts of the machinery. I then replaced the front skin that had been removed while I worked on the machine. Still to do for the physical 1442 - fix up the status lamps and adjust the card feed into the stackers.

The lamps suffer from the same age degradation where the leads on the lamps snap off with the slightest movement, making it nearly impossible to get a full set of working lamps back behind the status panel. I left them loose for the show, since they are hidden inside, and will work on this when the equipment is back home.

The physical cards move from hopper to pre-read, through the read station to pre-punch, through the punch to the cornering station, then out into the stacker mechanism. The cards make a right angle turn in their motion at the cornering station. Cards are not reliably turning and moving through the stackers, which is a matter of adjustments of a few parts at the station and stacker. This is something I want to adjust before the show.