I worked on the adjustments for the shift mechanism and it now seems to reliably move between upper case and lower case positions when I manually push on the appropriate solenoid. I attempted a power on test, but there is still the unresolved issue of a level 4 interrupt that is unexpected or not cleared. I will need to shoot that first.
Another humid day, although a bit less hot with highs only forecast to reach the upper 70s (F). It is sticky in a way that we normally don't experience out here.
If I hadn't run into a diagnostic that was checking for extraneous device interrupts, I wouldn't have found this error in my fpga logic until sometime later. My change fixed this problem, so that I can move back to the debugging of the console printer.
It is now shifting properly but I suspect it is still getting lost in a busy state. I am bashing my way through the diagnostic, in equal parts understanding what it is saying, how it works and what problems it is flagging.
Another issue solved - I adjusted the ribbon color mechanism so that it shifts between black and red ink portions of the ribbon under program control. The remaining issues to work on:
- Return button on front of printer panel starts CR but it is not latching properly into return mode (this will be fixed with an adjustment)
- Getting lost in some state, but not sure what causes it until I understand the diagnostic better
- XIO request for CR not activating a cycle
- XIO request for Tab not activating a cycle
- XIO request for backspace not activating a cycle
- XIO request for line feed (index) not activating a cycle
Part of the diagnostic operation echoes from the keyboard to the console printer. I tried quite a few keys and it is getting the correct character, but I need to do a more exhaustive test to validate everything. The space bar, a separate microswitch, is erratic in its operation and needs contact cleaning.
I put the diagnostic into a mode where I can type individual characters or movement commands by setting their value in the bit switches. I used that to validate all the XIO results. However, I can't quite get the diagnostic into that mode.
I did get some sporadic junk jammed onto the incoming data line, which I suspect is from one of my peripherals, so I uncabled the 1442 reader/punch and the 1132 printer for now. I can concentrate on debugging the keyboard, console printer and my peripherals hooked through the SAC Interface Box.
I found a few more adjustments that improved operation. I think the situation where the machine gets lost with CR and tab operation is going to be gone, but I still have to get all the operational magnets to trip their operational clutches when the solenoid is engaged. The other issue I know I still have is the failure of a CR to latch up.
Normally, when the CR solenoid or Return button trips the operational clutch, it takes one cycle of the operational shaft to start the carrier into its return motion, but since that motion lasts longer than a rotation of the operational shaft, it has to latch the mechanism. The carrier slams into the left side at the end of a return, which unlatches the mechanism. My problem is that the mechanism isn't latching up so that when you trigger a return, it moves just about an inch until the operational cycle is over and then it stops.
While I was adjusting the heavy printer, which involves tipping it on its back and upright again several times, I managed to clumsily snag and rip off the nylon tape that shifts the ribbon between black and red halves. This is frustrating, as I have done this once before, and it was JUST ADJUSTED TO WORK WELL this morning. I will figure out how to attach a new hook to the end of the tape, put it back on, and adjust again, but I won't do this until everything else is working cleanly.
I found that the stickiness in the carrier return mechanism latching up is easing up as I work it more and more. It must be residual hardened grease in the mechanism which will only go away with time and exercise. It is still not latching perfectly every time but much better already.
Even when I push down on the armatures of the various operational solenoids, the link is not tripping the cycle for any of those functions - tab, return, index, space and backspace - thus I have it narrowed down to inside the 1053 mechanism, not an adapter electronics issue.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I had to look over the fpga logic to see if I am somehow interfering with the operation of the interrupt level which is shared between the console printer and my virtual 2501 logic here. I did find that the logic to load the interrupting device in an ILSW was flawed - it always would dump that bit pattern if the device issued an XIO Sense ILSW, even if it wasn't actually triggering the interrupt level.
What is special about an XIO Sense ILSW, compared to every other function of an XIO, is that the device number (area code) is ignored. The instruction is issued in an interrupt handler in order to figure out which device(s) have triggered the interrupt and branch into their device specific interrupt handler. As a result, whenever an XIO Sense ILSW is triggered, all of my FSMs were triggered even though the program was working with area code 1, the console printer/keyboard.
I have one FSM for each device which is triggered by any XIO Sense ILSW regardless of device and returns the bit pattern for that device. For interrupt levels with multiple devices implemented in my fpga logic, there will be more than one of these FSMs operating at the same time.
The bit pattern is 0 for all devices that did not trigger an interrupt, but since all the the device patterns are tied together in an OR, that works fine. Only the device, if any, that is requesting an interrupt on the level will have a 1 bit high in its assigned position in the ILSW.
I began thinking about the enclosure and physical construction details of the circuitry that will sit under or near the keyboard and remotely actuate the buttons needed to emulate a Program Load.
No comments:
Post a Comment