Worked on 1053 a bit, mostly extended logic in SAC Interface Box

1053 CONSOLE PRINTER RESTORATION

Another ultra hot day, even with the air conditioner unit trying its best. I adjusted a linkage that trips the cycle clutch and saw one part that should snap back by spring action but seemed to stick. That part got flushed with fresh oil and exercised. Once it is cool enough to power up, I will try things once again.

By 8PM it had dropped to 75F and with a bit of AC I could do some testing. Having made a slight adjustment to the trip link and relubricated the one part I saw sticking, I was curious to see how it will have affected the typewriters's behavior.

I ran the diagnostic on several tests - upper case side, lower case side, then some worst case patterns for tilt or rotate selections - and was pretty pleased. There are still intervals where I can see the solenoid levers dancing but the cycle clutch doesn't cause a print cycle - as before, these are fairly long sequences where it fails to type, not interspersed individual failures amid good strikes. My work so far has created quite an improvement, with fewer dropout intervals.

1053 output on sheet at left, reference strings in book on right

You can see the page where the the 1053 was typing tests, with the reference output from the diagnostics MDM next to it for comparison. You will see long sequences where every character is typed, no mis-selection and it is running flat out at full 15+ characters per second typing rate. You can also see points where it stopped typing for a while and then picked up at another place. Thus, it is still alternating between long sequences of typing and other shorter sequences of missed print cycles.

I used my flashlight to look to see if anything was noticeable during the non-print intervals, but I didn't see anything clear. Tomorrow I will work on the trip link length a bit more and see if that resolves the issues.


SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I spent time overnight building up a mirror version of the 1132, such that the fpga will mirror everything that occurs on the printer. If the PC program wants to copy this into a file, it can issue poll commands, see the printer activity and build up a file that represents the printed output. I will also build a mirror version of the 1053 console, keyboard and console bit switches, all useful for logging what happens during a session.

In writing the logic, I realized that I didn't need new versions of most of the modules for handling XIO, because they could shadow the state of the real IO adapter with no harm. It is only for the cases where the real IO adapter is outputting new data - for example in an XIO Read, where I have the special version that sees what the real adapter writes into core as it appears in the B register late in the E3 stage of the instruction.

Sense DSW is the other function that needs a special mirror version to snapshot the B register after the real adapter has emitted its status word. This works because I will see the status word reflected in the B register, even though the machine is not taking a storage cycle reading and then rewriting memory. The data is still gated into B from the IO adapter.

The cycle steal fetch and store must be changed as they cannot actually request a cycle steal, nor should they be setting the memory address or inbound data. Instead, they should snag the contents of the B register at the appropriate time when it contains whatever the device has written or read during the steal.

XIO Init Read, XIO Init Write, XIO Sense ILSW and XIO Control don't write into memory, instead the processor does all the fetches and simply presents them on the B register for the adapter to grab them. Thus, I can use the same logic to grab the appropriate values for mirroring.

For the printer, I need to save the emitter data (character coming up to print), the last XIO, the sense bits, and track the state to know when to watch cycle steals and other status. It appears that I will need new transaction types where the PC program can fetch the extracted eight words of the printer scan field in order to virtually fire the hammers and see other mirrored status.

I also have to determine why my 2501 code keeps updating the DSW status when it is not ready. Once I figure out what would work properly, I can reactivate the remainder of the virtual card reader logic.