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 :-)
The case was badly cracked and broken, so lots of glue was needed. Even so, bits are missing.
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.
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!
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
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 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.
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.
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!
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".
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.
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 :-)
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.
I remember using these a LOT in my first few years at university! I ended up getting ear defenders to use in a crowded terminal room; they came in useful later for the main computer room.ReplyDelete
Great work. We had these at Cambridge Uni. in the late 1970s, and Edinburgh a bit longer. The luxury of lower case was unknown to us.ReplyDelete
The paper tape reader sends data up the line without local echo to the printer, unless you put it in local mode. Arranging for remote echo (the usual situation) will give you a printout. So it's probably working correctly.ReplyDelete
There are characters you can send down the line to start and stop the paper tape reader.
I can't remember whether you can duplicate a tape (by switching on the punch) without also getting a printout: probably not. Hey, it's been 42 years...
If you can print you can punch, so duplicate is easy, and I can do that.Delete
But the distributor trip solenoid does not engage in remote mode at all (i.e. the tape does not move, nothing happens) - it looks like it is controlled by the mode switch, but I would expect it to work in both local and remote, so very odd.