Smith Corona Typewriter to Printer Hack

26 JUNE 2015
Chris Gregg, Tufts University Computer Science Department, cgregg@cs.tufts.edu
(with much help from Derek Seabury, Bruce Molay, and Kate Wasynczuk)

Github repository: https://github.com/tofergregg/smith_corona_printer

About four years ago, I received a letter from a good friend of mine, Erica Dreisbach. The best part of the letter was that she had typed it on a vintage, mechanical typewriter. She had written it on slightly yellowed typewriter paper (which is thinner than today's hefty printer paper), and it was chock full of cross-outs, mis-aligned paragraphs, and smudged keys -- all the things that made mechanical typewriters so wonderful and artistic.

Being a fan of vintage typewriters myself, I wanted in on the action. However, though I am a fast typist, the downside to learning to type on a computer with a fully functioning, digital backspace key is that I make a lot of little, easily correctable mistakes. And by a lot, I mean a lot. I probably make a simple mistake every ten or twenty characters. When I was in high school, [redacted] years ago, my dad brought home an office typewriter (daisy wheel, I believe), that had a parallel port that could connect to the computer. As a computer engineer, I thought, "I could either find one of those typewriter/printers, or I could create one myself!"

A fervent Craigslist search later, I picked up a beautiful 1960s vintage Smith Corona Sterling 12 electric typewriter. She was a deep blue, 120 volts magnificently machined piece of humming mechanics. I figured that I could convert the typewriter into a printer relatively easily, for (of course) if it was an electric typewriter, it had to have electronic switches that should be easy to wire up to a microcontroller. Little did I know, however, that this vintage typewriter was electric, but not in any shape or form electronic. There was nary a transistor to be found, and all the keys were mechanically connected, not electronically connected. On top of that, typewriters of that era were so meticulously constructed that once I (finally) got the case off, I soon realized that there was virtually no way to interface anything inside the machine. There were at least one hundred different springs, dozens of pulleys, one giant motor, and a series of belts, gears, and finely machined parts that must have been designed by a mechanical engineering wizard. The parts were packed in so tight that I never even saw most of the internal pieces.

Needless to say, this turn of events was disheartening. I put the project away, every so often coming back to it and wondering if I was every going to figure it out. Flash forward to Winter, 2015. I was sitting with my colleague at Tufts University, Bruce Molay, and I mentioned to him my failed idea, but he encouraged me to give it another shot. So, I brought the typewriter into work the next day, and Bruce took one look at it and said, "Solenoids." This was the answer, although not really the one I wanted to hear. What bruce meant by that one word would lead to dozens of hours of design (mechanical, hardware, and software), wiring, and debugging, but it was, in the end a good way to go.

So, once Bruce presented me with the solenoid idea, I ran with it. I found the cheapest solenoids I could ($2.75 each at www.allelectronics.com) (which, when scaled to 48 keys, isn't actually that inexpensive!), and I set to work testing if they would really do the job. The solenoids were (at the time) rated for 5V, although I see that allelectroncs.com has updated them to say 12V. Regardless, they are such a wimpy solenoid design that I had to bump the voltage up to 24V before they were strong enough to properly strike the electronic keys (which, except for the backspace key, have a remarkably light touch).

After purchasing and testing the solenoids, I needed to figure out how to mount them onto the typewriter so that they would reliably strike the keys, and be held in tightly. I landed on the idea of using acrylic to mount all the solenoids, so I bought myself a sheet of 1/8" acrylic off of eBay and hoped for the best. Luckily, I mentioned the project to my roommate, Derek Seabury, who is a brilliant engineer and also happens to have built a laser cutter for the Artisan's Asylum, a maker space in Somerville, MA (where he is currently president).

Derek said, "Acrylic? We can just lasercut that," and then took a picture of the typewriter keyboard and disappeared. A couple of days later, Derek presented me with a beautiful two-layer solenoid holder design that he had prototyped out of cardboard. We headed to the Asylum (through the snow -- it was a tough winter here in Boston!) with the acrylic, and cut out the acrylic with perfect precision.

Derek's real genius involved the two-layer setup. The bottom layer fits perfectly over the typewriter keys, creating a solid foundation, and the top layer holds the solenoids, and is bolted to the bottom layer. Together, they create a solid, immovable structure that guarantees that the solenoid vibration won't dislodge any of the solenoids out of place. (and the last picture below is Derek in his fancy laser-proof glasses).

>> <

Once we had the solenoid mounting problem figured out, it was time to get down to the business of figuring out how to drive them all. I knew I wanted to use a Raspberry Pi or an Arduino (originally, the LightBlue Bean), and I knew I would be limited in the number of output pins. My initial idea was to use a set of decoders, but I got very good advice on the Electrical Engineering StackExchange website to use the TPIC6A595 shift registers, which meant that I only needed to use one Arduino pin to provide an input value and a few more pins for shift register control (SRCK, RCK, ~G, and ~SCLR). Here is a good little tutorial on how shift registers work. Of course, at around $3.50 per shift register, having to purchase six of them was not cheap (I eventually had to buy twice that due to burning out the parts during testing).

As anyone who has worked with electronics before knows, electronic parts can be assembled in a number of ways. I originally thought I might breadboard the circuit, using through-hole components, but because I had never built a printed circuit board (PCB) before, and also because I had never used surface mount components (which are soldered on the top of the PCB instead of through holes in the PCB), I decided to learn how to use a CAD program to make a schematic and PCB design. I used EAGLE, by CadSoft, which has a somewhat steep learning curve, but can produce schematics and PCBs, and has a very nice autorouter so I didn't have to route all the PCB wires by hand.

I went through a number of different versions of both the schematic and the PCB, and as it turns out I forgot to add a number of pull-down resisters in my first attempt at the circuit, so I ended up having to send away for two separate builds of the design. I voluntarily admit that the PCB design still has flaws, and it could certainly be made significantly smaller with a bit more forethought (and, for some reason, I put the text in the wrong layer, so it is very faint on the board).

Schematic (open in new tab and zoom for more detail, or see original EAGLE files in the GitHub repo):

PCB Design:

I ordered the PCB from OSH Park, a "Community printed circuit board order." What that means is that (1) when they get enough orders for a run of PCB fabrication (on a large board), they send the projects to the board, and (2) because this method is cost-effective, it is inexpensive. You get three 2-layer boards for $5 per square inch, which is quite a deal. My boards were rather expensive ($63 per order, and I had to order two runs) because the design wasn't particularly space-efficient, and because I screwed up the first design. But, in the name of learning how to design PCBs, it was well worth it.

I ordered most of the electronic parts from DigiKey, which has incredible shipping times, if not the absolute lowest prices on parts. Because I was a novice at using EAGLE, I ended up using some parts that were more expensive because the parts were the only ones I could find in the EAGLE software. In the future, I'll be a bit more diligent about either finding cheaper parts, or creating my own part designs in EAGLE.

As I said, I had never worked with surface mount components before, and it was definitely a fun learning experience. One of my students in the CS department at Tufts, Kate Wasynczuk, helped immensely, and we both learned how to surface mount solder with this project. A few surface-mount tips:

  1. Watch as many videos as you can! I watched a ton of video tutorials on surface mount soldering, and I learned something important from every one.
  2. Flux is your friend (as is a good flux cleaner). Flux helps solder flow, and it is an amazing help with small components.
  3. Use a good soldering iron. I borrowed Derek's excellent soldering iron with an attached heat gun, and it came in very useful for soldering (both with the iron and with hot air), and also for desoldering when we needed to take off a component (which was much too frequently).
  4. Try a heat gun and solder paste to see an incredibly magical soldering method. Tiny components like itty-bitty resistors (see the video below) will literally float right onto their pads and lock in place simply from the surface tension of the melted solder paste, and the first time Kate and I saw it we were giddy with excitement. You can see this in action (albeit in an oven instead of with hot air) in this excellent video by Ben Heck.

Final PCB after soldering and hooked up:

Once we (Kate and I) soldered and debugged the board, I wrote a couple of programs to interface with the PCB through the Arduino (which was originally the LightBlue Bean). The first program was the Arduino sketch (program), which is pretty simple (as most sketches are). It takes serial input (either characters to print, or special commands for functions like setting the various shift-register pins high or low), and translates that into output for the PCB. The overall algorithm is fairly simple:
  1. Take the serial output from the computer and decide if it is a character to print, or a special command.
  2. If it is a character to print, decode the character to get the proper amount to shift.
  3. Clear the shift registers (which can be done all at once).
  4. Run through a loop that shifts a one to the proper pin location for the correct key. I.e., if the "a" character happened to be the 20th output pin, you would shift a "1" into the first shift register and then shift in 19 zeros. When you turn on the outputs to the shift registers, the pin that has the one fires its solenoid.
  5. Turn on the shift register output to strike the key. If the character is a return key (for example), the delay needs to be longer after the strike so the carriage has time to return to the other end.
  6. For special commands, perform the special command (e.g., set SRCK to high).

I also wrote an OS X application to provide the human interface to the Arduino, for both debugging and for the original output. The program (see below) still has a lot of the residual debugging features, which came in very, very handy.

Screenshot of OS X application:
Finally, after much debugging, Kate and I got the typewriter working. The only problem was that it (very) frequently would either "double-strike" two keys at once, or it would hit one or two keys off. This ended up being an infuriating bug, because the symptoms seemed to indicate that the signal wasn't propagating well, and I thought it might be because of my not-so-great soldering job. As it turns out (and after soldering and re-soldering dozens of times), I ended up getting an Arduino UNO to replace the LightBlue Bean. The UNO has pin outputs which are 5V instead of 3V, and the increased voltage was able to drive the circuit (through optocouplers, which were probably not necessary in the end) perfectly.

The last part of the project (which I am still debugging) has been to write a CUPS printer driver to print documents from the print dialog in programs. It has been a bit wonky so far, but I've proved the concept and need to debug it some more. Bruce wants to write a graphics-to-ASCII art translator so we can print any document, but I fear that may tax the poor Smith Corona a bit much.

Speaking of Bruce: when the project was almost complete, Bruce stopped by my office and mentioned that a friend of his, Yuriko Kuwabara, commented that it would be fun to get the typewriter to play the typewriter part of Leroy Anderson's 1950 symphonic release, "The Typewriter." You probably already saw that video at the top of the web page, but although non-trivial, that was one of the most fun parts of the project (and I love the external bell, too).

If you have questions about the project, feel free to email me at cgregg@cs.tufts.edu, and also take a look at the GitHub repo.

The last video below is a better demonstration of the final project, and it also discusses a couple of interesting old typewriter-specific necessities (e.g., any idea how to type an exclamation point on an old typewriter without a 1 or ! key?). Cheers!

Special Thanks to: