more work accomplished

PAPER TAPE READER

I wired up the connectors between the PT reader mechanism and the PT reader interface card, as well as the final connection that will link this to the fpga 1130. I have verified the mechanical operation of the unit, although I may have to add some tension to the rubber belt before doing any live reading.

I found some paper tape programs on ebay, which will not work for the 1130 but are well formed and will let me verify correct reading. Will put this aside for a few weeks to work on other portions of the machine.

TYPEWRITER

The improved SingleShot component behaves correctly and this resolved the undesirable retriggering of SS1 due to the race hazard identified below, but the blip that previously triggered SS1 for the second time is also propagating thru the adapter logic to switch other gates. It is clear from the design that the original engineer expected this blip would not change anything, because it was short enough that it would be unable to trigger the IBM edge detecting gates which require a long hold of the trigger signal to switch the gate.

I have flagged the race hazard in the diagram below, where the drop of SS1 is routed to the trigger of SS2 but also to an OR gate that maintains an interlock as long as one of the three conditions is true - SS1 is firing, SS2 is firing or Drive Interlock is on. The issue occurs because SS1 drops, SS2 has not yet risen, thus the OR gate drops its signal in that interval until SS2 comes on. This drop is what prematurely triggers activities that are supposed to occur only after BOTH SS1 and SS2 are down.

Race condition where SS1 drop reaches OR gate (up arrow) before SS2 is firing (right arrow)

My solution was to add a delay for the signal that is entering the OR gate, giving a couple of cycles during which SS1 still appears to be on, during which time SS2 will have fired and its output will be at the OR gate. When the delayed SS1 drops the OR gate is held high by the SS2 and we get the intended results from the adapter.

The emitter remains a bit problematic - due to mechanical inertia we can seem to detect an extra count after we have dropped the escapement signal which shuts off the motor drive. More seriously, the quality of the pulse train is ragged, even with tweaks to the debouncing circuits. What I need to have is the falling edge of the emitter signal, without bounceback, to tell me once and only once that a new hole has arrived on the emitter wheel. I did some redesign of the approach in order to achieve this objective properly.

The action of the print cycle - printing a character or even firing that mechanism to release the clutch for movement only operations - seems to yield some spurious signals from the emitter which I need to either eliminate or block suitably.

Decided to remove the emitter and print feedback signals from the path through my relay driver board, just in case I am inducing noise or degrading the signal somehow. Wired up a bit of coax to the emitter and now enjoy really really solid emitter operation.

This prints well until it is time for the hidden cycle, where I am ending the cycle prematurely having not even fired the PSCC for the shift of the typeball. I also noticed that I can ask for a hidden shift cycle on movement only commands (e.g. space), but it has no meaning for these and shouldn't be activated. Time to move the diagnostic signals around and put the logic analyzer and brainpower onto this. If I can get this cleaned up, I can say the core of the selectric interface will be complete.

The impetus for movement only commands attempting hidden shifts was that I assign a tilt/rotate/velocity/case string for every firing of the print cycle mechanism, even when that cycle is used solely to release the escapement mechanism that allows the carrier (carriage) to move left or right. If the case I set up was different than the position of the typeball, it forced a hidden shift. Rather than try to sort out what command was in process in order to disable the shifting, I eliminated the attempt altogether. I did this by setting one of two alternate strings for the movement-only commands, with upper or lower case, depending upon the state of the ball at that instant. The logic would always determine that the ball was already in the proper orientation, thus it would skip over the hidden shift process.

Remaining testing areas for the interface include:
    - validating successful carriage return/line feed operation
    - run through all characters to ensure they are mapped correctly
    - test left and right margin setting and impact on returns, end of lines
    - test tab set and clear functions
    - test tab operation
    - startup routine homes the carrier and prepares typewriter for normal operation

MUSEUM WORK

The restoration technical staffs at the various museums where I am helping are all excellent, a joy to work with. The Binghamton museum group did some research on the 1440 we are attempting to interface with a 1403 printer. That machine's documentation and logic diagrams show it was configured to attach to a 1443 printer, a different type entirely that oscillated two linear type bars side to side across the page for printing, whereas the 1403 rotates a chain of type slugs between the hammers and paper.

Their research did document how it was programmatically viewed and controlled by software on the 1440, and it is very good news indeed. The programmer issues a command to print one character of a line, doing this repeatedly to fill a line. There are branch commands defined for various carriage control tape states, for example branch if carriage control tape channel 9 is sensed. Nothing else, thus no details of the printing mechanism or timing are exposed to the programmer. These instructions and results are fully compatible with how the 1403 printer works, thus there is an easy, straightforward mapping of semantics and behavior.

The next step of investigation will be to check for the existence of each SMS logic card and connector in the 1440 that the logic diagrams show are installed when a 1443 printer is hooked up. We can then document the signals and physical details for the connector or connectors we will use, most likely a set of SMS paddle cards but possibly a unique connector.

We have the full logic of an adapter that takes a line of type and prints it, plus the full logic to move the printer ahead and sense carriage control tape channels. We have the circuits with parts values for the cards that drive the print hammers and even the full circuits with parts values for the power supplies.

Given what we have learned, the odds of a successful mating of the 1403 to the 1440 and the ability to print by program has shot up. I would guesstimate it at 60% already, and if the cards and connectors are all there on the 1440, and the cards all work properly, and the 1403 mechanism has no broken or unrepairable parts, it would shoot up to perhaps 85 to 90%.

The items to make are power supplies and driving circuits for hammers and clutches, SMS sockets to connect the printer cable into, level shifting circuits to adjust the logic voltages and thresholds to modern fpga or microcontroller levels, level shifters for the connection into the 1440, some paddle cards or connectors and finally cables between interface and 1440. All the complex logic of driving the printer and mapping results will be handled in the microcontroller or fpga or other modern circuitry.

I need to sketch out the basic framework, circulate it to the teams in Binghamton and at the CHM, and provide any assist they need to move this forward into an active project. The group in NY have cleaned up the printer and it appears to be in very good shape. However, it is missing a few small parts, one of which is pretty essential. The print train cartridge, which holds the type slugs on a belt that rotates across the hammers and page, is missing a small gear in the set that drives the belt. If a spare can't be found, likely one will have to be fabricated after divining the proper design of the gear and teeth. The other parts are in the mechanism that  raises and lowers the cover over the 1403 - a sound reducing cover to lower the noise that is a feature of the N1 model printer. The cover can be manually raised and lowered, thus lack of the parts is not too much of a problem.

LIGHT DISPLAY PANEL COVERPLATE

The front of the pedestal mounted display panel on the 1130 has two squarish metal plates on each side and a 20" wide by 5" high plastic plate in the center. That plate has lettering and other printing on its inside face, with transparent openings in the shape of numerals and letters for each place where an indicator light will glow. The basic background is black, with medium and light grey rectangles defining groups of lights that are the bits from one machine register, plus lettering and other legends. In the 1130, incandescent lamps glow behind the transparent openings for numerals or letters.

My machine replaces the incandescent lamps with LEDs, with a suitable filter to recreate the yellowish color of the original equipment lamps. The LEDs are separated by a grid or honeycomb, similar to how the 1130 separates the incandescent lamps, blocking spurious illumination of an opening by lamps in adjacent positions.

I am preparing the image that will be printed on a plate of acrylic 20" by 5", to sit on the front of my display panel. The image will be reversed as it will be printed on the inside face of the plate but read from the outside face. I have been working out the techniques to draw the image with Adobe Illustrator and have just worked out the final process I will need - 'punching' out a transparent hole in the shape of a text numeral or alphabetic character from a painted rectangle.

I will proceed to drawing the plate image very accurately to the measurements and pictures from the 1130 machines I visited, print it in grey scale and take it to CHM to hold up against the real machine. That will primarily be to validate the colors, intensities and other cosmetics, plus review how closely my chosen font appears to the unknown font used by IBM. Once it proves out, it can be flipped and saved for manufacturing.

The way I will print the image on the acrylic is still up in the air. I will check with various silkscreen printing businesses as that is likely the best method, but a hand-made version done in TechShop is a fallback. So far I have found services that print pictures on acrylic, not too bad in price as long as they can leave off the wall mountings and backings they normally include.