The new ASR33 controller board

My nice shiny new ASR33 controller boards arrived today, and I am really pleased to say it worked first time, and is now running my teletype.

My previous approach was to use a more generic ESP32 board. Indeed, I used a simple dev board for my first attempt, and then a smaller generic board I had made. This did work, mostly.

To send to the Teletype 20mA I was able to simply use a resistor to limit current to 20mA from a 3.3V GPIO line. The ASR33 has a transistor input, so that actually worked well.

The receive side should be simple - the teletype just makes or breaks a circuit. So a simple pull up resistor and then the teletype loop grounding a GPIO pin. Well, should work, in theory.

Sadly it was never good. It depended massively on the distributor with carbon brushes, and leaf contacts, and was, shall we say, flaky. Yes, if you exercised the distributor (hold REPEAT and RETURN) for a while, it would clean up enough to work most of the time, but still not 100% reliable. Looking on a scope it was clear why it was so bad - the signal was just horrid.

The solution is a completely new dedicated ASR33 controller board.

The first thing I did was to find a suitable 20mA source. I picked the NCR402U constant current source designed for LEDs. It defaults to 20mA but has an option of a resistor to change this. This also has the advantage that it can run off a higher voltage if needed, though the ASR33 does not need that. I needed two of these, one for Tx and one for Rx as the ASR33 is passive on SEND and RECEIVE sides.

For sending, I then used a simple FET to connect the signal to ground. This means I have a 20mA source out, and a return which connects via a FET to ground, and causes 20mA to flow. The result is very clean, and drives the teletype nicely. But, as I say, just using a simple resistor off a GPIO also worked.

For receiving, I originally tried the 20mA via the teletype SEND circuit, and to a resistor. This should give me a simple voltage on a GPIO pin which relates to the current, 20mA or open circuit. It should be simple. But no, just as noisy as the original solution. The fix was to fit an optocoupler. The 20mA source goes via the teletype SEND circuit and then through an LED in the optocoupler. The output then goes in to a GPIO with an internal pull up. This is clean. Very clean indeed.

The result is both Tx and Rx working perfectly. I am very pleased with the result, and it makes the whole teletype much more usable.

Passive or active?

The ASR33 is passive for SEND and RECEIVE, but some teletypes could be active, so for that reason the Tx site FET can be used without the current source, and similarly the Rx optocoupler can be connected without using the current source.

I also added pads to allow a change to 60mA. However I don't have a 60mA teletype, and they typically drove a selector solenoid directly. That will not work from the 5V USB, and the board can only really do 40V which is unlikely to work even if at 60mA. Something to try when I send a board to someone with such a teletype.

More than just Tx and Rx?

The only standard connection on the teletype 20mA loop connections for Tx and Rx, but you usually want a little more. In this case a power control. I used a simple solid state relay to control the power to the whole machine, driven from a GPIO pin. But I also coded use of MQTT to work an external power switch running tasmota if needed. This allows the teletype to turn on, do something, and turn off, nicely.

Sadly having motor start at the same time is a problem as you get duff characters clocked in. The answer to this was fit an extra lead in to the teletype to allow the motor's power to be switched, using another solid state relay. This means the motor can start and stop while the power is still on, and ensure a clean start and stop without a duff random character (it actually clocks a non printing RO character).

But there is more ... if the ESP32 is controlling power, you need a power switch. For this I have one more GPIO to go to a button. My teletype has a MOTOR START button from an original, and more complex, motor control circuit. This was bypassed and run to the controller to allow it to be used to power on and off.

Of course I also have a multi-colour LED and a button to force a config more (WiFi AP and simple setting page to set WiFI and MQTT details).

Why?

The basic purpose is to allow a teletype to connect via a simple TCP socket. This makes it a lot easier to work with any modern computer system than an actual serial lead.

But it also does a few other things, a local echo, an punching large text on paper tape, and even a game of colossal cave built in. I mean why not?

CR+LF has a long history...

The ASR33, like most teletypes of the era, works at a fixed rate. It does 10 characters per second. It is 110 Baud, using 1 start, 8 data (inc parity), and 2 stop, so 10cps Tx and 10cps Rx; 10cps printing; 10cps punching tape; 10cps reading tape; 10cps maximum typing speed. Everything happens based on one motor that does this 10cps working, engaging clutches to start an operation which completes in one turn. So everything has to happen within 100ms, well, sort of.

There is one exception: carriage return [CR]. The carriage is released within the 100ms time, but the carriage is on a spring, and does not get back to the left within 100ms if it is too far over to the right. The usual fix is to send another non printing character, such as a line feed [LF], as the next character, where CR and LF are used for each new line. The paper advances whilst the carriage is returning so giving the carriage a whole 200ms to complete the return. This allows enough time to get to the left, but can leave the carriage still bouncing and mean the first printable character is not well aligned. The fact that 200ms is enough is usually fine, unless you are particularly fussy. The fix to this is to send another non printing character, such as a NULL, another CR, or even a rub out [RO]. The standard HEREIS drum coding even specifies CR, LF and RO at the start.

If you do send characters immediately following a CR, you get them printed in the fly-back of the carriage, like this...

The whole “new line = CR+LF” thing has plagued computing for the last 6 decades, with some systems and file formats using CR as new line, some LF, and some CR+LF. Even today I can find I have a file in DOS format using CR+LF that needs converting.

The software I have written in the controller allows for this when printing text itself, doing CR, LF for new line, and adding a NULL if beyond 40 columns at the time. This works, and is used for prompts and even the Colossal Cave game that is built in.

However, this presents a few issues :-

• This works when generating text, but if in some sort of raw mode it mean the sending device needs to know to do this. Some systems know, some do not.
• If this is done automatically, so extra characters are inserted that is not a problem for printing, but for punching paper tape it records those extra characters. That said, a NULL or RO on paper tape should not normally be an issue when read in. But it is not ideal, and assumes it is not binary data on the paper tape for some reason. So you sort of need a raw or processed mode for handling such tape, which is messy.
• Paper tape is sometimes used for raw / binary data, but can also be used for “large text” or patterns (which is gibberish as printed). Whilst fun, this also has a practical use to label reels of paper tape at the start in a human readable format. If automatic extra characters for CR handling are added, they mess this up.

A new solution to an old problem...

My solution works because we are now using a soft UART. I am doing this, working the individual data bits on a timer interrupt, to allow the extra low Baud rates used by some teletypes, which are not supported by hardware UARTs. Some work as low as 45.45 Baud even.

The soft UART has now been coded so that the bytes, as actually sent to the teletype (i.e. not when buffered/queued, but in real time), are tracked to know carriage position, and operate a timer between sending a CR and the next printable character. A non printable character like a NL, NULL, RO, are allowed within this timeout, but the timeout has to finish before the first printable character after a CR. This allows the CR to complete and avoids printing a character during the fly-back of the carriage.

This means :-

• Where the sending device is sending the extra characters, even just a CR, LF, to allow for CR, then the operation is totally unchanged. This makes it 100% backwards compatible with existing working of teletypes and means no special raw or processed modes needed.
• Where the CR needs this extra time it can be done in sub character, even sub bit, periods, not wasting the time for a whole extra character such as a NULL.
• The delay can be adjusted for the position of the carriage, and hence allow just the time it will take to complete the return.
• This works even when CR is immediately followed by a printable character (causing a pause you can just hear on longer lines).
• No extra characters are actually inserted, so characters as punched on paper tape are perfect, no gaps or ROs, etc.

This works well, even with a printable character immediately following the CR, like this...

Today I learned...

What is funny (well, for me) is that there will be people who have worked in computing and IT for decades and encountered the whole craziness that is CR and LF, but have no idea why it was ever a thing. I hope this, in some way, explains some of the background.

You're welcome :-)

[thanks xkcd]

P.S. I cannot say for sure that the way teletypes work is why CR and LF are separate. They were around at the time ASCII was being developed - heck my teletype does not even have lower case as it is 1963 first ASCII version. So the way they work is quite likely to be a factor. That said, CR and LF as characters dates back even further than ASCII. It is true that CR being separate has been used for things like over printing underscores, even over printing hyphens many types to make a perforation, and other tricks, but I suspect those tricks are all a consequence of CR being separate and not the reason for it. Even the older manual typewriters would have a manual carriage return level that would typically do the line feed at the same time - so it seems odd they would be made separate characters if not for this reason. It is odd how, what may have seemed trivial at the time, such a decision still impacts computing today. At the very least, you can see why it is CR then LF, and not LF then CR, in files.

More on KICad 6 and PCBs

I have been updating all my PCB designs to allow for using the more commonly available LMR16006 with variable voltage, rather than the fixed 3.3V regulator. All done now.

But I have also made a couple more boards.

For a start, an ESP32-WROOM-32 board with more GPIOs. The previous generic board was this.

It has 6 pins, GND plus 5xGPIO with some links. I have updated the silkscreen to have GPIO numbers all over the place as it is a pain to find them on older boards if not printed on the board!

But I decided a more powerful generic design may be in order, so did this new one today...

This is a tad bigger, but 16 GPIO pins. Yes, one each side is pre-linked to GND, but can be cut. And options to link to DC supply or 3.3V are always useful. Again, an RGB LED on board. And I have labelled all the GPIO numbers. This should be useful.

But this has been a busy weekend, and I have also made this...

Now this is a fun board, an interface for an ASR33 using 20mA current loop. It uses some simple ICs that are aimed at providing fixed current driver for LEDs, but seem ideal for this use. For avoidance of doubt this is not the same as 4-20mA current loop used for some control systems (an analogue signal level), but a simple make/break on 20mA, and used for teletypes 50+ years ago.

All of these will be a little over a week to arrive, so fun to test when they get here. I'll post more, specifically on the ASR33 board, once I have them.

To be honest I am amazed how easy KiCad makes it to just knock out a circuit design, do PCB layout, and be all ready to order actual boards.

BNT162b2 Pfizer COVID vaccine, on paper tape!

This is an amazing article on how the vaccine works, and it is so much like computer programming. Well worth reading:-

https://berthub.eu/articles/posts/reverse-engineering-source-code-of-the-biontech-pfizer-vaccine

So I decided to see just how small the vaccine is, and it is tiny. If you then code the components in binary, e.g. U/Ψ=00, C=01, A=10, G=11, and pack in to 8 bit bytes it is only 1071 bytes in total, or put it another way, 2.7m of paper tape!

I hope that gives you an idea of how compact this code is, way smaller than any computer anti virus code!

But do read that article, it is amazing!

P.S. I used to get berated for being able to read hex ASCII (not as good at it these days), but after taking the above pictures I looked at the paper tape and realised "that's not how an mRNA sequence should end!". Basically, the sequence has padding, lots of As, which translate to 0xAA on the paper tape which is quite distinctive and I expected to see it but did not. It turns out a change to the ESP-IDF MQTT library moved where the default buffer size is set (which limits MQTT message size), and so truncating my sequence by 73 bytes, hence the missing As on the end (and a bit more). The picture still shows how small it all is, as it was only a small amount lost off the end (I had text printed more tape than that anyway on the ends). But for those of you that cannot read the base code of the universe, on paper tape, it was wrong and would not have worked if you injected that paper tape as shown... So don't try it at home.

This is how it should end (video) :-

P.P.S. it is also not bad as a QR code (base32 encoded) - only slightly larger than the NHS covid QR codes :-)

The trump tweet machine

As usual , something silly and simple has turned in to many hours, and learning some lessons.

I made a Trump tweet machine that prints Trump's tweets on an ASR33 teletype. It was a fun use of the teletype as it only does ALL CAPS anyway, meaning Trump tweets were a perfect fit. It was also printing on the only paper I had which was a sort of tissue paper (so you could, in theory, wipe your arse with the tweets if you wanted to). I have some proper teletype paper rolls now.

The original version was very simplistic - it used IFTTT which can do something for a tweet by a person. It can send that via http, with the name, time, and tweet text. I printed that. It worked.

However, it was not perfect. The main issue is a hour or so lag with IFTTT. I decided I could do better.

The code is asrtweet.c on GitHub. It has had an annoying amount of tinkering to get it right. I suspect there will be more.

I decided to use twarc after a bit of googling. It seemed to be one of the few command line tools that would feed the raw JSON which Twitter provide. Handling JSON is easy, but it seems handling tweets has a lot of gotchas, and is not as obvious as it seems.

• There are two formats, the text in the main body, and full_text in extended_tweet (if present). I can only assume this allows for legacy where tweets were shorter.
• There is a range of characters to display as the text will start with lots of @names which you don't show in the text usually.
• The character positions / ranges are unicode characters not bytes - arg!
• It, or something, changes " and ' and several other characters to unicode versions, so I replaced them to allow printing.
• The text content is XML coded for &, < and >. Why? This is JSON, so why do that? Crazy! And these are not counted as one character for character counts, but as &, a, m, p, and ; as separate characters.
• There is a timestamp based on unix time to the ms, good, but not for the time stamp of an original tweet if retweeting. Date/times seem to be in a text format only otherwise. It even does a time zone (e.g. +0000) but shows UTC (yes +0000) for a Trump tweet which is clearly wrong.
• A retweet only has the abbreviated text with RT on it, you have to look in retweet_status to find the original text, possibly within an extended_tweet block.
• Whilst referenced twitter handles are @name in the text, some things are not as you might want to display them. E.g. a URL is a twitter URL. There is then a list of replacements/expansions which you can use to replace things like this with the original. Again, all unicode character counts not byte counts.
• It seems twarc can filter follow a user by user number, but gets all events mentioning that user, so I have to filter if I want see tweets by that user. Mostly that is simple, but when it is Trump, that is tweets mentioning him several times a second.
• I replaced media with [photo] or [video] as a teletype is not good at such things. I also did not bother printing tweets that only have media in them and no text.
• There seems to be no flag in the JSON for twitters "disputed" status, though as I am printing as tweets they would not have time to add it. But even so, printing an old tweet, does not have any way to know. So I had to add this to his tweets myself :-)

There was a lot to learn.

But the end result (so far) is code that runs twarc to filter follow one or more users, and pick tweets by them. Handles retweets and replies with an extra line of text printed. Handles wrapping to 72 characters. It is typically printing a Trump tweet within about 10 seconds of him tweeting. No more hour long lag.

It is rather surreal having a teletype (very noisy) suddenly wake up and print a message from the president of the united states in my study here.

Here's one which did not even need converting to upper case :-)

ASR33 consumables

One of the issues with my ASR33 Teletype is consumables. Where can you buy teletype supplies these days? The three things it eats are paper, ribbon, and paper tape.

Paper

This is one of those occasions where google skills are needed! The paper needs to be continuous roll (this machine is not sprocket feed) and around 200mm wide. Well, between 190mm (to allow 72 characters) and about 220mm max width of roll holder area. I suspect it is based on US paper sizes so 8.5" (219mm) is what is expected.

I tried all sorts of googling on this - 8" paper, 8.5" paper, 8" paper, 210mm paper, 200mm paper, etc... I found bugger all.

The magic phrase I was missing is "telex paper". Google that and loads of people sell it, even Staples!

It is the proper stuff, low quality paper but works a treat.

Ribbons

The other concern was ribbons. This time I had no issue though. It seems that typewriter ribbons are still sold, a lot, enough for next day Amazon prime to have them. I tried a couple and found that 1009FN are what I want - they are exactly the right size, and even a black/red ribbon works (printing just the black side). It even has the eyelets at the end to auto reverse.

Some other ribbons worked, but were loose on the spools as the hole in the middle was too big. I have also ordered some black only for 1009FN so I can reverse it without printing red :-)

Paper tape

By far the biggest challenge was paper tape - continuous roll paper 1" wide.

Nobody makes it any more. I contacted the few web sites claiming to sell it, and either no reply, or replies confirming it is not made any more. There is someone selling antique Russian paper tape on eBay, and that is about it.

I was stumped, until I discovered the right phrase to google.

"Flightstrips"

These are 1" wide strips of paper used by air traffic controllers, and there are printers for them, and they take 1" wide paper tape on a roll. And they are still made, and you can buy them, albeit in a box of 10.

I'm happy to sell some of the rolls I have.

They are not quite "proper" paper tape in that they don't have some lubricant in them, and they also have a thermal print layer which is not needed, but otherwise they do work.

I still have some restoration to do on the punch anyway (was playing up even printing in cut down A4 paper), and I need to 3D print some spool holders, but I now have paper tape to play with, so should be a lot easier.

'70s game on '60s teletype

So maybe I am a tad crazy, but with very little work I managed to get Colossal Cave, the text adventure game written in the 1970s, to compile and run on an ESP32, and connected that to a 1960s ASR33 teletype.

So I decided to include in my ASR33/ MQTT driver stuff, so it is possible to run Colossal Cave on the teletype, stand alone, no WiFi or anything.

The C code port of the original FORTRAN pretty much compiled as is for the ESP32 (linux ESP32 pdf), but I had to change printf and readline slightly to work with the UART, and tweak CR/LF and additional timing NULLs, but that was all.

Well, I did spend an hour or so coursing as it nearly worked and kept crashing - I added debug after debug and eventually did what I should have done in the first place and wheeled the teletype to my computer and connected the debug port which helpfully told me stack overflow. I have the task more stack and it literally "just worked".

Update: Since the video I have added a dramatic pause / thinking time, using some NULLs, before each response. Adds some suspense :-)

Update: You see typing issues on that video - cleaning the distributor fixed that right up...

Connecting an ASR33 Teletype to an ESP32

As you know, I now have a working ASR33 teletype (see here for notes on restoration). Even though a few more bits to do, notable the case, I decided now was the time to do something with it.

Getting the teletype, and getting it working, were just pure nostalgia, as I used one in secondary school. I had not thought a lot about actually doing something even vaguely useful, let alone fun, with it. But I had made a few assumptions.

One thought was a simple linux terminal, so connecting the teletype to a Raspberry Pi, for example. Of course, the slowest ever game of space invaders was not really a consideration :-).

RS232 interface lead

Internally computer components normally work with binary, 1s and 0s, and these are represented as a voltage relative to a "ground". So typically 0V is 0, and operating voltage is 1, e.g. 5V, or 3.3V. Some modern chips use a variety of different voltages in different places, but the principle is the same.

I'm sure you have all heard the song, no? Anyway, the serial interface of choice, when I was growing up, was RS232. So you need a way to connect the internal working of a computer system to RS232. This involves driver chips.

RS232 actually works with voltages (relative to ground) that are +12V or -12V, though modern variants use +5V and -5V or even less. The original specification allowed for quite a wide range of voltages to be valid.

Connecting something like a Raspberry Pi to RS232 simply involves getting an appropriate USB adapter. Easy.

20mA current loop

However, the teletype uses an older standard called 20mA current loop. Instead of ground and a voltage this uses a pair of wires (- and +) which either generate 20mA or nothing to represent the binary values. The advantage of this is that no matter how long the cable you have, if you put 20mA in one end, you get 20mA out the other. That is how current works. It does mean long cables need quite a high voltage at the start (voltage does drop over distance on a long cable), but if you can apply the necessary voltage to feed 20mA in at one end, then you know the far end is getting 20mA, and the signal is getting through.

Sadly a simple USB 20mA current loop interface seems harder to find, but one can get an adaptor for RS232 to/from 20mA current loop.

Not so easy!

Sadly it is not so easy. For a start, the interface box (which is over £100) needs a power supply, so I need you get some sort of DC plug top power supply for it. This is to source the 20mA to send to the teletype.

However, it is worse, it turns out the teletype does not send 20mA anyway. It expects you to provide a 20mA current source which it "switches" on and off. So I would need a second 20mA constant current supply for the teletype so it can feed 20mA to the adaptor which turns it to RS232 which I then feed in via USB to a Raspberry Pi.

This is getting expensive and messy.

Tech that is 55 years apart

An alternative idea, now that I have played with ESP chips, is to connect to an ESP32 to make the teletype WiFi connected allowing a lot more flexibility.

The technology I am playing with here is around 55 years apart. The teletype is using a 1963 version ASCII typewheel which dates it probably before 1965, as the 1965 typewheel has underscore instead of an arrow. The ESP32 came out last year. So yes, 55 years apart, and yes, as old as me, which is scary!

So really. how hard will it actually be to glue these two together?

I mean, this is really old technology one side, and really new technology the other. Nothing was even close to using 3.3V back 55 years ago, it was not even using 5V TTL from what I can see.

So really, how hard could it possibly be to connect them up?

Guess?

...

Really.

...

The answer is this!

A 100Ω resistor that I happened to have lying around, and costs a few pence. Yes, I can spend over £100 on an RS232 to 20mA adaptor, more on a USB RS232, and more for two power supplies, or I can use this, and that is it. Really, that is all.

How it works

Sending data to the teletype...

The input to the teletype just wants 20mA or not, and it does not matter that the ESP32 only generates a mere 3.3V. By feeding through a 100Ω resistor I measure 2.2V drop which is 22mA, which is fine. The printer has this going in to a transistor (Q1) which drives another power transistor which switches power to the solenoid that drives the selector which works the mechanical clocking in of the data to the print (and punch) mechanism.

So it turns out that 3.3V output GPIO pin on ESP32 to 20mA current loop needs literally nothing more than a 3p 100Ω resistor, that's it, magic.

The ESP32 is then quite happy to be configured to 110 Baud 8 data bits and 2 stop bits and that just works. (Yes, the ASR33 is technically even parity, but actually the machine ignores parity. You actually want clean 8 bit if you want to print space invaders on the paper tape punch as I have yet to see even parity space invaders).

But what about the other way - data from the teletype?

The answer to that is actually even simpler. I know, how could it be, but it is. The teletype is designed to "switch" a 20mA current source, which means internally it is just a electrical contact that goes on and off (via a distributor) to send the serial data.

This is what the keyboard contacts look like. The wires are pushed out in a pattern by the bars that the keys work, and they contact a bar at the bottom, or not, in a pattern for the data bits to send.

And this is how those are clocked out. Each of the contacts from the keyboard are on the outside, and connect in turn, clocking a start bit, 8 data bits, and 2 stop bits. The keyboard itself generates the even parity for the keys pressed.

But at the end of the day it is two wires that work like a push button, and so one connected to GND and one to an input pin with configured pull up, and you have input data to the ESP32!

You do have to connect to the right pins, else you end up putting 80V or so up an ESP32 pin and releasing the magic smoke, and you don't want to do that, or again, or again, arrrg!

The ESP32 settings also, rather handily, allow it to have the input inverted, which is necessary when wired like that. You also need to tell it to give you one character at a time as UARTs are typically going a lot faster and you expect to get several bytes at once. Once set up, it was then easy to make a local echo sending the typed key back to be printed as you type.

The end result?

I can connect to the screw terminals at the back. And then fit it all in the case nice and tidy, and we have a WiFi MQTT connected ASR33 teletype!

The ESP32 is connected over WiFi to MQTT where I have commands to send raw 8 bit data, or lightly cooked text (sends even parity for the sake of paper tape; adds carriage return to line feed; wraps at 72 characters; and blats any smart arses trying to send UTF-8 emojis to print an up arrow instead). It also allows sending key presses back raw (i.e with parity, so allows all 8 bits from paper tape), as well as line buffered (stripping parity). All in github for your amusement (here).

I have also put a Sonoff Basic (Tasmota) in-line to the main power, so the ESP32 can turn the power on and off over MQTT automatically when it wants to print.

I then have a simple script to handle incoming SMS on a number and send to the ASR33 via MQTT. Works a treat! The printer powers up, prints the message, and the powers down.

One more step planned, seeing as it can only print upper case, is to make it print tweets from the (soon to be ex) president of the United States. Seems appropriate some how. (update: I did it! here)

Here's a video of it working...

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.