ASR33 Restoration

We were sent an ASR33 a few years ago, and I can't seem to find my notes on who sent it so as to thank him again, but it was severely damaged in transit.

Finally this weekend I got the motivation, and a helping hand (after lots of COVID testing, thanks Simon), to try and restore it. There are a lot of youtube videos on this, so I decide just to make a blog post. The next post on this is how to use an ESP32 to talk to an ASR33, which may be more interesting :-)

Case

The case was badly cracked and broken, so lots of glue was needed. Even so, bits are missing.

Schematics

They are available, and the youtube videos on these refer to them as written with hieroglyphics, and I am inclined to agree. They take a lot to get your head around them. But they exist, and the manuals define pretty much everything you actually need to know - mostly.

Power

The first thing was connecting power, which you would think would be simple enough. These are designed to run on US power, 115VAC, so there is a huge transformer in the base with connectors/. The motor is a variation of the standard 60Hz motor for 50Hz, so it is still 100 Baud.

A two way connector, and a lead from the teletype with a two way plug - simple. But there were two leads with 3 way connectors from the transformer, and they looked like they were just in parallel, so I picked one to connect to the one lead with a 3 way plug. Power up and motor ran for a bit, and bell dinged, and then it all stopped.

This is where I had got to when we first got it, and despaired somewhat.

So, we tried to investigate more and find what was happening. Fuses were blowing in at least two places. So we tried to work through schematics to check the various voltages and nothing made sense, until we checked the supply power which was 230VAC. It seems the two connectors, unlabelled, are not in parallel! One is 230VAC and one is 115VAC. Changing to 115VAC and replacing fuses, yet again, and we finally got the motor running. This was a major milestone for us on day 1 and helped a lot.

The whole thing is mechanical, and the motor running is the key thing you need for anything to work. It runs all the time and has two tripable clutches that engage to do one revolution for send, or the other side to do one revolution for receive. They work independently so the whole thing is full duplex in operation. All of the logic is mechanical, it is even possible to manually feed in data while manually turning the motor and have it print a character with no power on at all! The main electrical bits are power supply components and bits to drive a solenoid to clock in the data in to the mechanical receive system.

It is a shame I never thought to try the other lead right at the start - kicking myself!

Keyboard

The keyboard was slightly damaged with a crack at one end and a broken nub that should take a split ring. We re-assembled it, and used screws to replace these bits and re-fitted the keyboard. There is an "H bar" that links it mechanically to the main mechanism. The design is very modular, and this one mechanical link allows a key press to kick off the send mechanism, and allows the send mechanism to reset the keypress (allowing the next key to be pressed) once the character has been sent. It is quite amazing mechanics.

Unfortunately when connected up, and motor running, the distributor continuously ran - sending characters (NULLs) all the time. Thankfully that was down to washers in the wrong place when we re-fitted the keyboard making it slight higher than it should be. Once re-done, it then sent a character on a key press and stopped, ready for the next key - well mostly.

In fact, just occasionally, it would run on and send another character. The way the keyboard works this was always a NULL which does nothing, expect if you hit another key during that 100ms and manage to encode a character which is partly sent, making a duff character (often an @ as the low bits were not sent but the top bits came in when pressing the next key, if a letter). Thankfully this seems to be down to a slight adjustment on the distributor tripping mechanism from the keyboard and H linkage.

It seems there are a lot of places where you can (and have to) adjust things!

Distributor and sending

Now the keyboard was working, and apparently sending one character at a time, we wanted to see if it was actually working. When in "local mode" (a loop back to print) we just got constant "chattering" and gibberish being printed which made no sense, so the plan was to test the sending side.

One simple step was cleaning the distributor, which is pretty simple. But we wanted to check what it was sending, on an oscilloscope.

This was a lot harder to work out - we are used to circuit diagrams that have GND, and signals, so we were looking for that sort of thing, so it was all very confusing. Connecting a scope to the two "send" pins showed nothing sensible, mostly flat line at zero.

The way it actually works is that sending is just a "switch", the distributor and other contacts mean the the two "send" pins are either open or closed circuit, no GND, no signal, no polarity, no voltage. Simply putting the meter across it on continuity test provided a voltage to allow the oscilloscope to see a nice clear trace.

The 20mA loop sending actually needs an external current source which works, via this open/closed send circuit, to send the characters on the line.

Unfortunately for diagnosing things, the trace was fine, 110Baud data, so no clue what was not working. But it did allow us to check each key was coded correctly and sending correctly. What is amusing is that the "even parity" is actually just part of the coding bar for the keys - it is an "even parity" keyboard even. There is no checking of parity on the receive/print side at all. Amazing.

Loopback

Now we know the distributor is working, we tried to work out why the loop back (local mode) just printed jibberish. This is a matter of checking voltages again - there is a DC supply which is a transformer, diode and capacitor. The capacity was making odd noises as well, more so when on 230VAC, but not good. So we checked it, and it seems OK.

But checking the voltage showed a quite high AC voltages, which may explain why the cap was not very happy. Turns out that the diode was not entirely in one piece any more, and was conducting both ways.

Thankfully I had another diode, and we changed it, and bingo, nice clean DC, and the capacity was not threatening to go bang any more. It is possible that this just packed up, or maybe the 230VAC is what cooked it. Once in place, things started working a lot better - well - the print side did not "chatter" any more, confirming there was idle current.

Receive and print

Now the loopback was generating sensible voltages for the current source, the loopback could get to the receiver. But pressing keys did not print anything, well, mostly. BREAK caused "chattering", so clearly that was working, and we realised the HERE IS (answer back) started chattering part way through the 20 character sequence.

The solution - well, the main one, spraying the whole receive solenoid and mechanism with lube. Magically is started working. It seems quite a few bits are improved a lot with a little lube...

There is also a timing adjustment ("range finder") which was needed, and we needed to tweak a few times to get clean printing without mis printed characters.

The good news is the printing just worked, which is amazing.

Dating the machine

Trying to date the printer, and looking at ASCII specifications, the typewheel and keyboard have ↑ and ← characters which are only in the 1963 standard, dropped by 1965. It does rather date the machine to around when I was born!

The keyboard and typewheel are also a tad special - the manual shows the letter owe and the digit zero as uncrossed, basically they look about the same. But this machine has cross letter owe, which is unusual. It seems IBM started using crossed letter owe and uncrossed zero but dropped that after a few years, so this again dates this as a very early machine, but with slightly special IBM style keyboard and printwheel!

ASR33's are rate, but this is more so, it seems!

Tape punch

We don't have punch tape. Well we don't have roll paper either. For both the answer was A4 paper. We cut to 1" strips for punch tape testing. The tape punch just worked. Wow!

The paper tape punch was actually really quite useful for debugging as well. Trying to get the range finder right was easier when seeing the bit patterns, and how they have gone wrong, rather than trying to work out from the mis-printed characters - even with a good understanding of ASCII.

As I said, parity is just the keyboard, everything else is just 8 bits transparently handled which allows one to send 8 bit serial data that is not valid even parity to just punch "as is".

Tape reader

The tape reader does not work - the auto feeder logic runs, and spins the distributor, but does not advance the tape, or sense the holes. The issue is the send solenoid. It seems this is run from a silly voltage which requires its own power supply. This is stuck in the base under the machine.

Unfortunately this was not working - apart from a blown fuse (not that surprising), it has a broken resistor. So one ordered from RS, and we'll get that working soon. With any luck it will just work too.

This is one area where the reader is linked to the distributor using contacts and solenoids rather than mechanical linkages like the keyboard.

Update:New wound 50W resistor from RS and it works, but oddly only in local mode. I am unsure if that is intentional or not.

Fine tuning

There is a lot to adjust, and we think we finally have the keyboard working with no run-on NULLs, and the printer working with the right range finder settings. The print paper feed is slipping, so I'm trying to work out how to make that tighter to the paper and may have to strip it down.

Update: print feed OK now - more lube :-)

What's next?

The case needs fitting, and I need to print some knobs, but then it should be quite good. The plan then is to WiFi it up, allowing it to be operated over MQTT. More on that in the next blog on the ASR33.