Skip to main content

Interface for a 1960 Creed 75 teleprinter: Part 5

Internal workings of a Creed 75 teleprinter

The fully-boxed interface next to a naked machine. Since Part 4 was published, I decided to mount the bell on top of the case – why hide such a nice finishing touch? Underneath the circular pattern of holes in the lid is a 30mm extractor fan.

Is this kinetic art or engineering? Even with the covers off, many of the moving parts are not visible. Imagine trying to ‘debug’ it while it was still under development: that powerful motor could probably send metal shrapnel, springs, and gear teeth flying all over the place if anything jammed….. Thanks to Greig Cameron at DesignSpark for stitching the video together.

The interface software

I found the development of code for the printer microcontroller much more of a challenge than it was for the paper tape reader project. That’s probably because the latter was designed as a computer peripheral, making the interface that much easier to develop, both in hardware and software. The Creed 75 is a telecommunication device, a teleprinter, not initially seen by its creators as a human-machine interface for the cutting-edge computer technology of the time (the 1950s). So firstly, here’s a list of the basic functions required:

  1. Allow printing from a standard RS-232 serial (COM) port, using an asynchronous (UART) signal format with ASCII-coded text characters.
  2. Using the same format and ASCII coding, allow the keyboard to send characters in the reverse direction to the host COM port.
  3. A printing test facility activated by a pushbutton, that does not require a host computer connection.

Different voltages

The PTR was easier to deal with because data flowed one way – reader to host – only commands went back. Its output was also in 8-bit parallel format plus a data-available strobe. The Creed 75 both transmits and receives serial data, though not at the same time, as a result of design simplifications involving shared mechanics. Its serial input drives a bipolar electromagnet directly and requires a signal magnitude of ±80Vdc. The average RS-232 driver can only manage ±12, hence the bridge magnet driver circuit I described in Part 2. The serial output from the machine can use whatever voltages you care to supply. In my case, I chose +3.3V for Marking (logic 1) and 0V for Spacing (logic 0); only because +3.3V is the working voltage of the PIC24 microcontroller to which it’s connected. That’s about as far as hardware interfacing can go; software running on a microcontroller has to do the rest.

Different codes, different baud rates

The interface has to work with obsolete 5-bit ITA2 (Baudot) codes, a serial character length of 7.5 bits including 1 Start bit and 1.5 Stop bits, and a baud rate of just 75. That gives a character period of 100ms or a printing rate of 10 characters/sec. So, there’s our first problem: modern UARTs do not have all the teleprinter format options they once had: 5-bit data, 1.5 Stop bits, and 75baud. Bizarrely, some devices have two out of the three settings but not the third. As I suggested in a previous instalment, a ’soft-UART’ driving two GPIO pins will have to be constructed in program code. In order to avoid the necessity for elaborate buffers, the character rate for the host serial connection must the same or less than that of the printer connection. Sounds like a dead-end, but then we had a stroke of luck: the host’s terminal emulator I’m using, Tera Term, will accept an equally obsolete rate of 110baud, and because the data format for communication between host and interface is standard 7-bit ASCII with one or two Stop bits, we’re in business! It works like this:

Printer link: 1 Start bit + 5 data bits + 1.5 Stop bits = 7.5 bits -->10 chars/sec @ 75baud

Host link: 1 Start bit + 8 data bits + 2 Stop bits = 11 bits -->10 chars/sec @ 110baud

So far, so good, but there’s a snag: remember the Letters/Figures shift operation needed to get around the limitation of a 5-bit code? The machine contains a mechanical ‘latch’ that holds it in one of two states: Letters mode where the 5-bit codes print the alphabet, and Figures mode where the same codes are interpreted as numerals or symbols. Two codes are assigned, one to select Figures mode (1Bh), while the other (1Fh) sets Letters mode. So, if you are printing letters followed by a number, the figures shift code must be sent immediately after the last letter. And this is the heart of the problem. The interface software handles all this automatically, but without some sort of FIFO buffering in the UART receiver, characters will be lost. Consider a worst-case scenario:

ASCII-coded data from host: A.B.C.D.E.F.G.H.I.J. = 10 print chars/sec input

Baudot data to printer: A^.^B^.^C^.^D… = 5 print chars/sec out (^ = Figures or Letters code)

The whole thing falls over the first time the interface inserts a shift character. Luckily, the PIC24 UART has a four-character FIFO buffer on both transmit and receive. Unfortunately, after a few shift characters have been inserted, the receive FIFO overflows. Nothing for it, some form of ‘handshaking’ is required to stop transmission from the host before the FIFO overflows. Transmission is restarted when the buffer is empty. Two methods are available:

  • Hardware, using RS-232 signals RTS and CTS.
  • Software, based on ASCII control characters DC1 and DC3 (aka XON/XOFF).

The RTS/CTS approach is undoubtedly the most reliable, and most UARTs have the necessary hardware built in. But as the TTL to RS-232 level convertor module, I’m using doesn’t support it, I went for XON/XOFF, as it is supported by Tera Term, and the extra code in the interface is trivial.

The fully-commented PIC24 assembler source code for the interface can be downloaded from the ‘Downloads’ section below.

Printing text from the host

The two key routines for inputting an ASCII character for printing from the host computer are CHRIN and the Buffer-Nearly-Full interrupt service routine __U1RXInterrupt. The receiver interrupt is set up to activate when the FIFO is ¾ full. The CHRIN routine then sends the XOFF code back to the host using the CHROUT routine. The drawback to this handshaking technique is the latency or time taken for the host to receive and react to the stop-transmitting code. One or two new characters can be sent before transmission ceases. I’ve not found this to be a problem because the interrupt activates before the FIFO is full and the latter can accept up to two more characters before overflowing. Once the FIFO has emptied all its contents out to the printer, XON code is sent back to restart host transmission. The system can even cope when two extra characters are inserted – Carriage Return and Line Feed – as part of the automatic end-of-line wrap-around feature.

The 5-bit code equivalent to the 7-bit ASCII from the host is obtained from a simple look-up table. ASCLUT uses the ASCII code as an address for the 128-entry table which contains the 5-bit codes as data. The need to take into account the machine’s current shift mode makes things a bit more complicated. Each entry in the table has Bit 5 cleared to indicate that the character is a letter, or set to indicate a figure. A flag variable, FIGLET, is initialised to zero on power-up and the user presses the LTRS (Letters) shift key on the keyboard to initialise the machine. From that point on FIGLET is updated every time a shift mode change is made by the interface, with FIGLET = 20h (Bit 5 = 1) denoting figures shift mode current on the machine. A simple Exclusive-OR operation on FIGLET with the character obtained from the table determines whether a shift change is needed.

The SDATA routine is half of the ‘soft UART’ for sending formatted serial data to the printer. Essentially, it performs parallel to serial conversion. A pretty straightforward example of ‘Bit-Banging’ I think.

Keyboard output

Getting data from the keyboard and sending it to the host as ASCII is a much simpler task for KBDIN. The routine makes use of the Change Notification feature of the PIC24 to sense the falling edge of a possible Start bit, then waits for a half-bit time and checks to see if the line is still low. This ‘glitch avoidance’ technique is part of the functionality of any hardware UART. In this case, it is part of the receiving half of our ‘soft UART’, GDATA, which performs serial to parallel conversion. Routine BDTLUT returns the ASCII code equivalent from a much smaller look-up table than before. This time, the look-up address is formed by adding FIGLET to the 5-bit data.

Main program loop

This short loop at the top of the program, MAINLP, idles around, checking for host input activity or a possible Creed key press. It also fires up a printer test when a button on the interface box is pushed.

Printer test

A pushbutton on the interface activates a routine that prints out a block of text stored in the program memory. This allows the printer to be tested without any host connection. Convenient for quick checks without having to drag out the laptop, fire up Tera Term, and then send a text file to the COM port.

Send-Receive switch

As I mentioned in Part 1, space and weight were saved in the revolutionary design for the Creed 75 by having the send and receive sides share the main camshaft. This led to the possibility of damage to the machine under certain circumstances when a key was pressed while a character was being received on the serial input. A number of interlock mechanisms were added to prevent expensive damage should these conditions occur. The shared camshaft also affects operations in two (non-destructive) ways:

  1. Typing on the keyboard appears immediately on the printer. Of course, this means no remote echo is required (or no ‘leak’ resistor between the two comms lines). However, it does mean that faults with the serialiser mechanism or the host communication interface will go unnoticed.
  2. Data coming into the machine via the serial input will be echoed right back on the serial output. This is not a particularly useful feature.

Nothing can be done about (1), but the internal send-receive switch fixes item (2). Built into the machine is a changeover switch that’s toggled when any key is pressed. This Send-Receive switch normally sits in its receive position, allowing the serial input to drive the printer, but preventing the serialiser from sending a signal out. When a key is pressed, the switch moves immediately to transmit, returning slowly to receive when keyboard activity ceases. The transmit blocking is done electrically, by making the Mark and Space reference voltages to the serialiser (Part 1 Fig.5) both Marking. The cams flip the code contacts around as normal, but the output signal remains in its idle state. The wiring of the switch is determined by the type of comms circuit in use, so its three connections are brought out to the 12-way socket on the back of the machine, leaving the installer to work it out!


Well, that’s about it. The question is: was it worth all the effort? Personally, just being able to watch it in action is all the reward I need. Despite being an electronics engineer, I have a profound admiration for the mechanical engineers who design complex machinery like this teleprinter. You can’t just make a ‘lash-up’ prototype and keep re-making parts until it works. The thing is, mechanical engineering hasn’t been rendered obsolete by electronics – the two fields have come together giving us ‘mechatronics’. A modern ink-jet, laser, or even 3D-printer represents a fusion of technologies where each is essential: the mechanics provide the ‘physical doing’ function; the electronics do the ‘thinking’.

Everybody’s talking about ‘Sustainability’ and ‘Repairability’ nowadays. A detailed inspection of the Creed 75 reveals just how much design effort went into ensuring it had a long service life. Of course, there used to be another word in widespread use amongst engineers: ‘Maintainability’. The technical manual for the Creed contains a whole section on daily/weekly/monthly servicing tasks, principally cleaning, and oiling the many bearings. Apart from your car, and perhaps the central heating boiler, what gets ‘serviced’ nowadays? New technologies have reduced the apparent need for it, but is that because we expect to scrap the equipment when it becomes ‘outdated’, like, next month? Right now, we are being subjected to high-pressure marketing of 5G broadband networks. But there is growing consumer resistance in these times of dwindling resources: as someone in a movie once said of recreating dinosaurs; just because you can do it, doesn’t mean you should.

Previous articles in the series:

Part 1: Introducing the Creed 75 teleprinter and the aims of the project.

Part 2: Teleprinter communication and the printer magnet driver circuit design.

Part 3: The keyboard interface and power supplies.

Part 4: Microcontroller board and host communication

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.

Engineer, PhD, lecturer, freelance technical writer, blogger & tweeter interested in robots, AI, planetary explorers and all things electronic. STEM ambassador. Designed, built and programmed my first microcomputer in 1976. Still learning, still building, still coding today.
DesignSpark Electrical Logolinkedin