Console Printer (1053) adjustment/testing and enhancement of the SAC Interface Box

1053 CONSOLE PRINTER RESTORATION

I hooked up the scope to the busy lines on the adapter - the line from the typewriter mechanism into the adapter and then the official busy line that is produced by the adapter logic. I used it in conjunction with my testing to figure out when problems arise.

Mechanically, I made adjustments to the five pull links that the operational magnets yank when the solenoids are activated. These fire the Tab, Return, Index, Space and Backspace cycles respectively. Four of the five were too loose, so that the pull link didn't trip the interposer to fire off a cycle. The Tab link, on the other hand, isn't firing the interposer regardless of the adjustment.

I adjusted the four links so that they would trip when I pushed down on the operational magnet armature, which I believe will make them work well although for completeness I checked this under diagnostic control. What I found is very encouraging. Spacing, backspaces, indexing and carrier returns are triggered reliably by program command.

I have a few problems with carrier return which are purely in the mechanical side of the typewriter, and for some reason tab won't trigger when I yank on the pull link. I imagine this is also purely a mechanical issue inside the typewriter.

When I ran the diagnostic, it was typing away, triggering returns, and in the test for alignment it would forward space to type black 0 characters then backspace and type a red + inside. These looked quite nice most times it tried this test. The characters on both upper and lower case side of the typeball typed cleanly.

Here is what is unresolved as of dinnertime:

• Carrier return doesn't latch as it should, stops after an inch of travel
• Carrier return is not pushing the left margin stop hard enough to unlatch
• Tab does not activate by pull link at all
• My broken nylon ribbon is stopping the machine from activating the red/black ink halves of the ribbon under program control

The lack of activation of the tab interposer means that some adjustment is way off so that it won't unlatch on a pull downwards. The only reason it activates by the button on the front panel is because that forces the interposer back. If I can figure out what is wrong with the triggering mechanism on the interposer, it should fix all these problems.

The carrier return is a more pernicious problem - the toughest part of the machine to rehabilitate. Within this, there are two subparts - not moving far enough to latch and not unlatching on the far side. Frankly, I have to check that the high speed gearing is engaging, as the failure to unlatch at the end could be a result of slow or anemic movement. There is also a clutch spring on the operational shaft that can affect the carrier speed. 

The nylon ribbon for selecting the color of the ribbon is a simple attachment and adjustment, if I can repair the end or find a new part.

After a bit of studying, concentrating on the carrier return problem where it doesn't latch, I knew what was wrong. There is an adjustment where the latch edge should overthrow the slot in the keeper but it isn't even clearing the edge most times. I loosened the nut and moved the bolt head down to achieve the overthrow I wanted.

I did accidentally loosen a nearby nut first, and in spite of tightening it back down, I have to adjust that one to get the mechanism back to working properly. The adjustment is twisting the escapement, as it has to during a return operation to pull the escapement teeth out of the rack, but if it doesn't release fully it will stop the spacing and tab. That is the current symptom.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I put in some time changing the logic in the fpga to add a transaction type to be sent from the PC that requests activation of my emulated Prog Load button - a sequence of Imm Stop, Reset and then Prog Start key presses. In between the Reset and the Prog Start, the PC program will have to write the 80 words into low storage which will get executed when the Prog Start key finally activates.

I also built in the new signals for Interrupt Level 0 and 1, but have not yet changed my UCW design or other logic to fully implement these new signals. Basically, I need two bits to control these two levels, plus the logic that sets and resets the bits as IO device adapters work, and the logic that first the interrupt requests when the UCW bits are set.

I began assembling the logic card for the Prog Load engine that will sit in the 1131 under the keyboard. The parts won't all be here for a few days but I could put in IC sockets and do some wiring. I found a convenient set of signals from the fpga to handle the four signals for the handling of interrupt levels 0 and 1, but I haven't yet selected a pin for the trigger to my Prog Load engine.

The sequence to activate this, from the PC program side, is:

1. verify that there is a binary mode card deck loaded into the virtual 2501 reader
2. issue a transaction with code 14 and special value 127 which triggers the emulation engine in the machine.
3. verify that the USB link returns the same command code 14 and word value 127.
4. issue status fetches for the word that has the Reset line as one of its bits
5. wait for the Reset line to go active, meaning that the emulation engine pushed Imm Stop and now Reset buttons
6. wait for the Reset line to go inactive, meaning that the processor is waiting at IAR of 0x0000
7. request cycle steal writes for the first card image, in boot format, into locations 0000 to 004F
8. at this point, do nothing. The emulation engine will push Prog Start to begin executing at 0000

There are several independent mechanisms that have to work in the proper sequence, but I don't have much ability to synchronize them. After I fire off the emulation engine for the Program Load, by sending the command type 14 from PC to the fpga, that engine has no interaction with the fpga.

The emulation engine steps through a ten stage state machine with its own on-board clock operating at about 10 Hertz or a click every 0.1 second. The machine presses the Imm Stop key for .1 second, pauses for .1 second, then pushes the Reset  button for .1 second. then waits a half second before pushing the Prog Start button for .1 second and finishing.

During the half second, the PC has to see the Reset signal drop, meaning the action of that button has finished, then the PC will request 80 write cycles to load memory with the boot instructions. It can't start too early or the 1130 will still be in reset and not able to handle the cycle steal write cycles. If the 80 characters aren't stored by the time that the Prog Start key is pushed to begin execution, the boot instructions might not yet be in core.