How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
It works! For the first time in its life, this machine is printing copy generated by a computer program. The Quick Brown Fox line is a traditional printer test, as it contains all 26 letters of the alphabet. In the case of ITA2 5-bit code, that means all the characters in ‘Letter Shift’ mode. The code for ‘Figure Shift’ is then sent, changing the mode so all the numerals and special characters appear in the next line. Finally, back to Letters and the line composed of alternating ‘R’s and ‘Y’s. This combination is a maximum stress test for the mechanical decoder: the code for R is 01010 and Y is 10101. Not bad performance after 40 years of inactivity. And using an ink-ribbon of similar vintage.
Printing from the Keyboard
I was able to check out the keyboard and printing systems before any electronic circuits were built because mechanical linkages give the Creed 75 a sort of ‘typewriter mode’, which just needs the motor to be running. Having a permanent connection like this is useful for establishing that an old machine in an unknown condition can be brought back to life using little more than copious quantities of oil to free up dried-out bearings. The downside is that incoming serial data can clash with keyboard data. Having demonstrated that the printer will work with a serial data signal driving the electromagnet, the next stage was to get the serialiser working, with keystroke data converted to a serial format and sent to a host computer.
The Creed’s keyboard and encoder is entirely mechanical, only needs the motor to reset the key after its code has been read, and is a detachable module held onto the main chassis of the machine with just two screws.
The detached keyboard unit. Notice the six horizontal code bars just above the key cover plate. That’s one for each code bit, plus another that activates the ‘key-pressed’ signal. In the reset condition, all are pushed towards the left and held under spring tension by a latch bar. When a key is pressed, its own crossbar is lowered onto the code bars beneath behind one or more of the ‘teeth’ on the latter. At the same time, the key crossbar pushes down the key-pressed bar which in turn releases the latch allowing the code bars to slide to the right under the spring tension. Only those code bars not held back by a tooth acting against the key crossbar will move. So, an unmoving code bar indicates a Space; one that has slid back to the right represents a Mark. The ‘output port’ is a line of six vertical pins above the code bars: pin down = Space, pin up = Mark. The next picture provides a better view. After printing, a motor-driven cam forces all the code bars back to the left until the key-pressed latch re-engages.
Close-up of the keyboard’s ‘parallel output port’. The pin on the far right is the key-pressed signal. The other five provide a 5-bit ITA2 code with pin up = 1 and pin down = 0.
Sending keyboard data to an MCU
The five bits of data from the keyboard are transferred via a set of levers and cranks to another set of pins which impinge on the code contacts of the Serialiser. See Fig.5 in Part 1. The Serialiser, as its name suggests, converts by mechanical means, this parallel data to an asynchronous, serial format electrical signal with a Start bit leading and ending with 1.5 Stop bits (Fig.1). The signalling rate is, of course, 75baud providing a ‘flat-out’ data rate of 10 characters/second.
The picture above shows the signal waveform present at the output of the line filter. It’s an image of a real signal captured by a Digital Storage Oscilloscope (DSO). Notice the ‘rounded corners’ on what you might expect to be a rectangular waveform. That’s the low-pass line filter in action, removing high-frequency components from the signal and eliminating any noise spikes completely. The text in the diagram explains how the MCU software can tell the difference between a low-going noise spike and genuine 13ms duration Start bit. The software then samples the line at 13ms intervals right in the middle of each data bit, allowing some variation in the timing between transmitter and receiver. Even better, the receiver sampling points are resynchronised with every Start bit, providing for robust data recovery despite the timing being derived from a mechanically-governed brushed-ac motor! In practice, I found the governed motor performed incredibly well; providing a rock-steady display on the ‘scope with no perceptible frequency jitter or drift. Amazing.
Power supplies & keyboard interface circuits
The keyboard interface circuits and power supplies are straightforward and don’t need a lot of explanation. See Fig.2. I mentioned in Part 2 that I was fortunate enough to possess a mains transformer with two secondary centre-tapped windings; one for the 80v supply and one for 12v. Each winding is wired for full-wave rectification with just two 1N4004 1A diodes. The +80v rail is not regulated. The +3.3v rail was a bit more of a problem because the rectified and smoothed 12Vac input yielded an unregulated voltage of +17Vdc - too high for the LD1117-33 regulator I’ve used before. Under normal circumstances it would be ridiculous to create a design with such a large volt-drop across the regulator. Unfortunately, I didn’t have a choice, so a LM1086-33 device was used as it has a maximum input voltage of 35v.
The Serialiser in the Creed requires reference voltages for the Code contacts: +3.3v for Mark and 0v for Space. The two 100Ω resistors in Fig.2a provide current-limit protection in the event of the cam-driven contacts getting out of adjustment and shorting the 3.3v and 0v references. The regulator can supply over 1A – current that could overheat the contacts and weld them together. The original communication circuit with its 80v signals used a pair of incandescent lamps to perform the same function, protecting both the contacts and the signal lines.
The simple RC circuit of Fig.2b is all there is to the serial line noise filter discussed above. It has a cut-off frequency of about 160Hz.
The interface board
That completes the design for the main interface board. Since the photo in Part 2 was taken, the stripboard prototype (right), has been fully populated and tested. The only changes involve the screw-clamp board connectors: all the ‘low-voltage’ connections now go via a 12-way 0.1in pitch type, leaving the 80v signals on two 3-way 0.2in blocks. The 3.3v regulator is bolted down with a small heatsink that’s probably unnecessary, but I just hate seeing TO-220 packages ‘waving about in the breeze’.
Next time in Part 4
Having demonstrated that the machine can print reliably at full speed from its serial input, and can supply keyboard data via the serial output, the next task involves constructing and programming the PIC24 microcontroller board. The test programs were run on my FORTHdsPIC Clicker 2 board using a couple of its GPIO pins: RB14 and RB15. For anyone interested, the Forth-based source code is available from the ‘Downloads’ section below.
If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues. To see my back catalogue of recent DesignSpark blog posts type “billsblog” into the Search box above.