How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
What’s in the box? This image shows the firmware development hardware consisting of the PICkit 3 on the ICSP header and the incredibly useful UART-USB bridge cabletemporarily connected to the host serial port. The Test button is yet to be wired up. At the top of the picture, you can see that the original 12-way screened signal cable from the printer is now terminated with a ‘Jones’ 300-series connector of the period. As quaint as these multiway connectors seem, they are robust mechanically and electrically – and are still available today. Sitting alongside is the printer with the cover off, revealing part of the electrical contact box. Beneath all that and out of sight lie the camshafts that make it all happen. I will attempt to make a video of the printer running – a sight that boggles the mind.
The Creed 75 was designed as a communication device, but adapted for use as a computer console on many early British computers. This project is to build an adapter to convert the high-voltage serial signals of the device to standard RS-232 levels with a 7-bit ASCII-coded format.
The Microcontroller Board
As with my paper tape reader interface, a Microchip PIC24 16-bit microcontroller chip provides the necessary processing power. Regular readers of my project articles will know that I frequently use the PIC24, or its enhanced DSP sibling, the dsPIC33. I wanted to make my own stripboard design, so that limited the choice of chip to those with DIP packages; the only other critical criterion being the number of I/O pins available. The PTR project needed twelve GPIO pins plus an interrupt input, so a 28-pin device was chosen for that. However, the printer interface only requires four, plus two dedicated to the Rx and Tx pins of the UART. A 14-pin device was chosen: the PIC24F04KA200 which boasts 4Kbytes of Flash program memory and 512bytes of RAM. Well, not much to boast about, but unless I go all weird and want to give it artificial intelligence (AI), then that’s more than enough.
The circuit diagram (Fig.1) is pretty simple, with few extra components beyond the MCU chip itself. These include a processor ‘Reset’ button and the ‘Hello World’ blinking LED driven by a simple test program to confirm that everything works. There are three sets of header pins: the ICSP connector for the PICkit debug/programming tool, the connector for the host serial port, and a connector for a panel ‘Test’ button. The plan is for the latter to trigger a printer test when pressed. Most probably, it’ll cause the three-line message shown in the photo at the beginning of Part 3 to be printed a few times, more than anything to confirm that the mechanics are working correctly. The two data connections to the interface board and the power supply, are made via a screw-down wire connector.
Enlarged view of the MCU board – the holes are actually spaced 0.1in (2.54mm) apart. It’s amazing what you can cram onto a bit of stripboard, mainly to keep lead lengths as short as possible My recent article ‘Build your own Microcontroller Board’ covered the reasons why I’ve chosen not to use an ‘off-the-shelf’ (OTS) part.
The Bell Circuit
The bell was something of an afterthought. The bell code (Ctrl-G in ASCII, Figures shift + J in ITA2), was used a lot to alert a distant teleprinter operator that a message followed. The early ‘glass teletypes’ (VDU) made do with a rather anaemic-sounding beeper. The ubiquitous Teletype model 33s of the period had a mechanically-driven ‘gong’, but I guess Creed couldn’t squeeze in the extra levers and cams needed, and opted for an electrical solution. I wasn’t going to bother with it at first, but then I spotted new old-stock 12volt electric teleprinter bells on sale from a tech surplus supplier in the US. This little beauty just fits under the lid of the interface box and gives a loud ‘ding’ whenever the bell, or in my case ‘Alarm’, code is received, either from the line or when J key is pressed with figures shift active.
The bell switch signal is available on the printer’s 12-way connector, so it only took a couple of discrete components and some wire to get it ringing!
The final version of the MCU’s code is not yet completed, mainly because I haven’t finished thinking about any useful extra functions that might be incorporated. In the meantime, some test programs have been written to test out the main functions. These are:
- A convertor from 7-bit ASCII to 5-bit ITA2 (Baudot) code, and another for the reverse direction.
- A software ‘bit-banged’ UART for moving serial data to and from the Creed at 75baud with a character format consisting of: 1 Start bit, 5 data bits and 1.5 Stop bits.
The Software UART
The reasons for creating a soft UART are simple: the on-board hardware version cannot be set up for 5-bit data and 1.5 Stop bits. As an old-timer I find this annoying but inevitable. Telegraphic communication networks based on 5-bit ITA2 codes have been obsolete for decades. Hence the need for a bit-banged solution using two ordinary GPIO lines. So, how to do it? Well, on the printing side, the first item on the agenda is a subroutine to convert 7-bit ASCII to 5-bit ITA2 codes. That ASCII character will come from the host via the hardware UART, UART1. There’s no mathematical formula for the conversion to ITA2, so a simple look-up table is used (Code 1).
The full look-up table has 96 entries covering most of the ASCII set except for lower-case letters and some graphical symbols. The ASCII code is used as an address offset from the table base at alut, enabling the ITA2 equivalent to be retrieved, or zero if there is no equivalent. Only the first 16 entries are shown in the snippet; a full listing will appear in a future article.
Unfortunately, there is a complication. You might have noticed that a 5-bit code can handle up to 32 characters, but there are 26 letters, 10 numbers, and a whole lot of symbols and non-printing functions that need unique codes. Actually, just under 64 codes are required, implying the necessity for a 6-bit code. Short of adding a Bit5 to the code, the compromise solution was to implement a mechanical ‘flag’ in the printer. In one state, all codes are printed as letters; if switched to the other state, then all subsequent inputs print as numerals or symbols. Two precious codes are used to switch the flag: 1Fh for Letters and 1Bh for Figures. For the interface software to work, a copy of the machine shift status must be held in RAM. By comparing the state of this flag with Bit5 of the code extracted from the look-up table, the program can determine if a shift code needs to be sent before the next printing code. Five non-printing functions will work whatever the state of the shift flag: Carriage Return, Line Feed, Space, Letters Shift and Figures Shift.
The Code 2 snippet is of the soft parallel to serial convertor subroutine SDATA. It implements the basic low-level UART function of taking the 5-bit code, appending the Start and Stop bits, then sending the whole lot at 75baud to the printer-magnet driver, via GPIO port RB8.
The keyboard input routine will look rather similar in structure to SDATA, except that the bit intervals will separate the points where GPIO input port RB9 is sampled. Another look-up table will be required, this time to perform ITA2 to ASCII conversion.
There are plenty of other problems to solve. For example, it’s unlikely that the host baud rate can be less than 300. This means some sort of handshaking/buffering will be needed to cope with 30 characters/sec arriving from the host, but only 10 characters/sec being printed…..
Hopefully, I’ll be able to describe the full code for the interface.
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.
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.