Now that I am comfortable with the revamped 1130 processor, it was time to get back to completing and testing all the peripheral interfaces. First up is the console printer, which is an IO Selectric on the IBM built 1130 but is an IBM Electronic Typewriter Model 50 on my system, with some fancy footwork and mapping to retain the original IBM 1130 adapter logic yet accommodate the considerable differences between the "Selectric I" style printer on the authentic 1130 and the "Selectric III and beyond" style printer I have in hand.
I am using the "1130 Scope Loop" diagnostic program, which will send streams of a chosen character to the printer. The character to print is toggled in with the 16 Console Entry Switches that sit on the front face of the console printer on the 1130.
I did find that the print feedback switch which tells where the mechanism is at this moment in its print cycle - rotation of the drive rod - was intermittent due to corrosion and loose fitting connectors on the typewriter. I cleaned that up and moved forward.
I am using a card and logic to handle the switches that was designed by Richard Stofer for his fpga 1130 system. Eventually I will handle these with my own logic and hardware connections, but it is faster to debug with that card for the time being. I have found that the board will get 'locked up' sporadically, returning either all 1s or all 0s regardless of the switch settings, and often will not reset unless I physically pull the cable or drop power for a second.
Since it was not designed with the same reset approach as my system, it is not participating in the master reset signals (NotDCReset) of the 1130 system. I believe that some noise is driving the board so that it is out of sync with the fpga and it remains that way. It does not seem to detect a problem and come out of it the same way on both sides. It has a self-reset circuit onboard that will reset when power is first applied, but the capacitor on that circuit will hold its charge for a relatively long time after shutting it down, which hampers recovery since a quick power cycle won't do. I haven't debugged it to learn whether it is the SPI protocol or interface that is wedged, or if the problem is that some unintended set of bits set the chip into a mode that wont work right, or if it is simply the code on the fpga that can't figure out how to restore normal operation.
This is a warning to me, as this can occur with any of the signalling buses on my design. While presumably my logic will reset both the hardware boards and the fpga, putting them back in sync, it requires the user to recognize that the system is malfunctioning and to push the reset button. It will be better if I design my logic on both sides to have verification codes that detect an out of sync situation, and a handshake that will always get them back on the same page. It is nothing more than an annoyance during the printer testing, but worth documenting and remembering for my own protocols.
I have verified that the typewriter will reliably spit out the 26 lowercase alpha characters and the ten digits. It will space and backspace pretty reliably too. However, I do have some bugs to deal with. Any attempt to print what the system considers an Upper Case character or the special characters that are considered to be on the upper case side, will fail. The ball chatters a bit but the head doesn't strike the paper.
It might be an issue with the fairly complicated logic to handle the real upper vs lower case status of the typewriter while reflecting the apparent upper vs lower case that the 1130 adapter thinks it would see.
Some characters that are upper on the actual 1130 may be on the lower case side of the ET50 and vice versa, to illustrate the complexities. Both typewriters handle the 'case' of a character with a shift operation introduced before the character typing operation - thus two 'cycles' of the mechanism are used, the first positioning the ball to the right case and the second printing a character on that side of the ball. I might have the 1130 adapter think it has to command a shift, but after I execute the shift I will translate the character being printed and discover that it is really back in the prior case, thus shifting once again.
One character could take 1, 2 or 3 print cycles. The 1130 adapter could think there is no shift but my adapter has to introduce one. Think of the combinations that can occur, each having to interact with timers in the 1130 adapter that expect one character to print in a fixed period of time. If it expects 65 ms for a print, it may return a completion status but I have only done the hidden shift and not yet printed the character - I will take 130 ms in these cases.
A further symptom is that if I use the diagnostics to type a single character, for example lower case 'c', it alternates printing as 'C' or 'c' with the logic always performing the hidden shift cycle, whether it is needed or not. This has a minor downside of slowing the printing rate, which might be temporarily tolerable if it wasn't tied to incorrect operation. Having random shifts of letters would make output look like the stereotypical ransom letter, on top of which it cannot print any characters that are intentionally upper case.
My line feed command should only index the paper downward, leaving the carriage in its present position, but I am improperly activating the motors and escapement so that it moves while feeding. Whatever flaw that causes this seems to sometimes infect the carriage return, which should simply move backwards until it reaches the left margin. Sometimes it moves forward, sometimes it returns but doesn't stop the left margin. This smells like a state machine problem in my logic, most likely due to signals that are changing state at the time I am making use of them.
After a hunt with the logic analyzer, I found that my translation of the 1130 tilt/rotate code to the ET50 signals, which also sets the target case to shift the ball, was not stable when I latched it and was using those values. Other timing issues were fixed, plus I introduced a more conservative approach in some places.
I feel that the physical typewriter is working perfectly at this point. My problems are within my adapter logic and that is what I will hack away at over the next few days. I am going to intersperse that with work on the physical machine - building the console light display pedestal for example.
No comments:
Post a Comment