I sawed off a very short segment of the 1/4" OD hollow tubing and tested it as the pivot rest for the typewriter pivot arm. It looks as if it will work out well, with some washers as spacers to keep the pivot arm (nearly) restricted to swinging in one plane.
 |
| 1/4" OD tubing as pivot bearing surface, fitting into hole on pivot arm |
I took some time to fine-tune the operational magnet linkages to ensure a good crisp engagement when the solenoid is activated. I ran the keyboard/typewriter diagnostics partially - I still have issues with the main Keyboard/Console switch as well as bail 12 and latch 9 oxides blocking correct recognition of certain keystrokes.
When I investigated, I found that the resistor from the keyboard/console switch had broken off its peg on the resistor panel, therefore the machine was always in Keyboard mode. I will have to solder it back on - while on my back deep inside the frame once again.
 |
| Keyboard/Console switch at upper right |
This definitely needs stranded wire in the pins, as solid wire is too prone to break off. On the other end, where it has to fit into connectors on the relay board, stranded wire would be a pain to insert and prone to having stray wisps shorting. The story of my life - wires that need to be stranded on one end and solid on the other. Time to solder a stranded end on the solid wires, then put the pins on the stranded ends. I will get to this tomorrow or Thursday.
I was able to confirm backspace, space, tab and carrier return operation under program control. I tried to reload the diagnostics to try out the index (line feed) operation, but found that chip 3 of the driver board was inexplicably hot at all times - bits 6 - 11 set on because the chip was pulling those six lines down to zero. I will need to fix this before running the processor again.
I took the keyboard off its mount and began to work on bail 12 and latch 9 with the burnisher, cross checking the connection with a continuity tester. Since the 0-8-2 key isn't firing off a line feed, it is possible that latch 20 is also bad and I burnished it also while working on the keyboard. The keyboard and panel is reassembled, pending testing once I get the wires to the resistor panel shipshape.
 |
| Back of a set of bails |
 |
| Side view of the bails with the contacts visible down the middle |
 |
| Looking down at back of keyboard from the top - bail bars across bottom close bail contacts on sides |
 |
| Underside of keyboard with one latch per keystem across the middle of the picture |
I checked continuity from pin C12 - for Interrupt Request Level 4 - and from B27 which outputs an additional copy of the signal value. Both were good. I have a voltmeter across B27 which should go high when Int L4 is requested.
B27 does not change, nor does C12. That would definitely seem to be an FPGA problem and the likely place would be in my logic, but I just can't see it. IL4 requests are exactly parallel to request for the other interrupt levels and should work properly if the others do.
These sorts of errors are frustrating and often inordinately difficult to resolve. I will be scrutinizing the reports from the synthesis, which are a challenge to review because of huge numbers of essentially irrelevant or benign errors that can't be excluded or isolate, thus hiding the wheat among the chaff or more appropriately, the needle in the haystack, assuming there is any wheat or needle there at all.
After sifting through everything, there are no messages at all that would explain why C12 and B27 are both stuck at level 0. I will temporarily reroute the signal to multiple free pins such as B29 and test for a good value there - if that works, but B27 and C12 don't, then I have bad IOs on the fpga and will relocate the int request line to a good pin.
Unfortunately, none of the new pins go hot when I request IL4, so the flaw is definitely inside the fpga instantiation of my logic. After staring for quite a while, I finally got it. IL4 requests are set if any of the twenty UCW entries (devices) have the corresponding bit set. My program on the PC was setting the bits as part of a transaction, but then when idle the fpga was overriding that with the logical state for the four implemented devices on IL4.
That is, the virtual 2501 reader, the paper tape reader/punch, the 1627 plotter and the virtual 1403 printer are UCW numbers 1 to 4 and their IL4 value is only set if the device adapter logic is requesting the interrupt. My PC transaction sets the bit and then it is reset a few dozen nanoseconds later to the state of the device adapter (off).
I changed my PC program to set the interrupts in UCW 10 - not currently implemented - which is not overriden by any device adapter logic. With that, I tested the interface and IL 4 triggered exactly as I wished. It is apparently impossible to move forward one step without a new problem arising to replace any resolved issue - now IL2 won't trigger.
During testing of the 1053, when trying to do another load of core with the diagnostics, I found that chip 3 of the driver board was inexplicably hot at all times - bits 6 - 11 set on because the chip was pulling those six lines down to zero. I will look to see if there is a failure mode in my PC program or fpga logic that could cause this, but the clean boundaries around driver chip 3 argues for a different issue, perhaps an intermittent ground connection to the chip.
These sorts of errors are frustrating and often inordinately difficult to resolve. I will be scrutinizing the reports from the synthesis, which are a challenge to review because of huge numbers of essentially irrelevant or benign errors that can't be excluded or isolate, thus hiding the wheat among the chaff or more appropriately, the needle in the haystack, assuming there is any wheat or needle there at all.
After sifting through everything, there are no messages at all that would explain why C12 and B27 are both stuck at level 0. I will temporarily reroute the signal to multiple free pins such as B29 and test for a good value there - if that works, but B27 and C12 don't, then I have bad IOs on the fpga and will relocate the int request line to a good pin.
Unfortunately, none of the new pins go hot when I request IL4, so the flaw is definitely inside the fpga instantiation of my logic. After staring for quite a while, I finally got it. IL4 requests are set if any of the twenty UCW entries (devices) have the corresponding bit set. My program on the PC was setting the bits as part of a transaction, but then when idle the fpga was overriding that with the logical state for the four implemented devices on IL4.
That is, the virtual 2501 reader, the paper tape reader/punch, the 1627 plotter and the virtual 1403 printer are UCW numbers 1 to 4 and their IL4 value is only set if the device adapter logic is requesting the interrupt. My PC transaction sets the bit and then it is reset a few dozen nanoseconds later to the state of the device adapter (off).
I changed my PC program to set the interrupts in UCW 10 - not currently implemented - which is not overriden by any device adapter logic. With that, I tested the interface and IL 4 triggered exactly as I wished. It is apparently impossible to move forward one step without a new problem arising to replace any resolved issue - now IL2 won't trigger.
During testing of the 1053, when trying to do another load of core with the diagnostics, I found that chip 3 of the driver board was inexplicably hot at all times - bits 6 - 11 set on because the chip was pulling those six lines down to zero. I will look to see if there is a failure mode in my PC program or fpga logic that could cause this, but the clean boundaries around driver chip 3 argues for a different issue, perhaps an intermittent ground connection to the chip.
No comments:
Post a Comment