Skip to main content

Interfacing a 1967 Paper Tape Reader: Part 4

ptr 4 1

Figure.1 Initial testing of the interface, now bolted into its enclosure with all signals and power supplies connected. Test programs are flashed into the PIC24 via the PICkit 3 programmer/debug tool.

In Part 1 of this series, I introduced a piece of computing history – data storage on paper-tape – and announced my intention to interface a 1967 vintage paper-tape reader to a modern microcontroller system. I gave various reasons for this seemingly pointless task in that article. Nostalgia is a factor, but I also wanted a vehicle for demonstrating how a product can be engineered for long-term reliability and easily repaired when bits do break. It adds up to what we might call: sustainable engineering. Part 2 described the interface circuits necessary to make the signals from the reader’s photosensor amplifiers compatible with a modern microcontroller. I also considered a recommended design for the clutch solenoid driver from the original technical manual. In Part 3 I decided to work on a simpler design for this driver circuit based on more recent component technology. The microcontroller system was also designed and prototyped on stripboard. Now in Part 4, I’ll describe how the new hardware was checked-out, boxed-up and connected to the old.

Boxing it up

When I embarked on this project, the idea was to make a stripboard prototype of the electronics and leave it at that. After all, I wasn’t proposing to make a ‘production’ unit as part of a plan to abandon disk storage and return to the good old days of paper tape. But then the climate-change conference COP26 had everyone talking about ‘repairability’ and ‘sustainability’. As I said in Part 1, this piece of computing history was built to last; but should anything fail, it was also designed for easy fault-finding and component replacement.

The heading photo (Figure1) shows the general arrangement for hardware testing and firmware development. In this picture, it does appear that the whole tape reader rig with its new interface has a rather large footprint (it takes up a lot of bench space), and the box could be a lot smaller. There is a reason for this apparent waste of space which will be revealed later on – if you haven’t already guessed.

ptr 4 2

Figure.2 Close-up of the interface box interior before the base plate was screwed on.

The complexity of the wiring to the interface board is well illustrated in this photo (Figure2). The four 5.5mm barrel sockets for the dc power supplies are arranged along the edge of the box on the left. From the top we have the +6V and -6V inputs, then the 240Vac for the motor followed by the +12V solenoid and +9V lamp supply sockets. The bare wire linking the four dc sockets and the Earth pin of the mains socket provides the common 0V connection. So how did I generate the -6V rail? That’s easy as long as the dc power supplies have a ‘floating’ 0V output that’s not internally connected to the mains Earth. That’s a given with European and US two-pin mains adapters, but it’s obvious too with the UK three-pin plug when the Earth pin is made of plastic! So, to turn a +6V supply into a negative one, just connect the positive output to the system 0V; the supply 0V connection will now appear to be at -6V relative to the system 0V. The only way to do this is to re-wire its barrel plug, swapping the wires to the barrel and pin contacts. The moulded plug will almost certainly have to be cut off, discarded and replaced. I used a new plug with a red cover to remind me of its reversed polarity. For safety reasons the PTR chassis must be earthed, so I have ensured the Earth connection is maintained all the way to the appropriate (metal) pin on the UK mains plug.

Figure2 also shows the interface operating in ‘development mode’ with the PICkit 3 plugged into the ICSP header and a UART-USB bridge cable (767-6200) attached to the serial port header. Both connect to my laptop; the former controlled by the MPLAB IDE, the latter by my favourite terminal emulator TeraTerm. A terminal emulator is perfect for firmware development because a keyboard can send ‘commands’ in the form of single ASCII characters, and the laptop screen will display the text read from source code tapes. Ultimately, the host processor will take over that role via an RS-232 cable link. The as yet unconnected DE9 socket and RS-232 buffer board can be seen under the mains power connector on the back panel. The big heatsink on the board behind the PIC24 chip keeps the LM33 +3.3V power supply regulator cool.

ptr 4 3

Figure.3 Close-up of the cable connections between the PTR and the interface box.

The most disconcerting feature shown in Figure3 is the socket-sharing by the 240Vac main cable and low-voltage dc signal wires! Fortunately, the design of these military-grade Plessey plugs and sockets does eliminate any chance of accidental interaction. It is a bit annoying though that I only have the back-shell for the smaller plug. Still, the heat-shrink sleeving should keep fingers away from dangerous encounters with the mains.

ptr 4 4

Figure.4 View of the interface box with its lid on. But why has it got rubber feet bolted on to it?

ptr 4 5

Figure.5 The power supply farm.

You can see in Figure5 that five mains sockets are required to power this beast. At first, I was annoyed that the +6V units were oriented in the opposite direction to the others. Then I thought: it balances the weights so the distribution block doesn’t tip over. Not important, but it looks better.

ptr 4 6

Figure.6 Ah, so that’s why….

Yep, Figure6 reveals why the interface box has rubber feet on its lid – it’s designed to be turned upside down and sit under the PTR. It adds to the height but involves no increase in real estate. As an extra touch, the recess in the centre of each existing PTR foot engages with a 3mm bolt head fixed to what was the bottom of the box. That ensures a machine weighing over 7kg isn’t dislodged with an accidental nudge.

In case you’re wondering, the box is a standard die-cast aluminium unit available from RS (868-1054) . Lucky that. Take a look at the shine on the PTR rear panel; you won’t see a paint finish like that outside of a car showroom. Those were the days.

ptr 4 7

Figure7 The first data read back from an ancient paper tape.

First Read

With all the hardware built and checked out, I flashed a simple ‘echo’ program into the MCU. The code consists of a main loop which monitors the UART input for the Run and Stop commands – ASCII characters for ‘r’ and ‘s’ respectively. When ‘r’ is received from the laptop keyboard the external interrupt INT0 is enabled and the PTR clutch solenoid turned on. The ‘sprocket’ channel on the paper tape consists of holes somewhat smaller than those of the eight data channels. So, when the leading edge of a sprocket hole arrives over its photosensor and triggers a rising edge interrupt on INT0, any data holes on each side of it will already be well centred over their sensors. The interrupt service routine ‘samples’ the state of all eight data channels in parallel, sets a ‘data-read’ flag before returning to the main loop. The data-read flag being set causes the new character to be sent to the laptop display via the UART output. The flag is cleared and the MCU continues in the main loop waiting for a stop command or another data-ready interrupt. The first time I ran this it became obvious that the most-significant data bits, 4 to 7, were stuck at zero. Nothing wrong with the hardware; all signals were present on the GPIO pins. It turned out to be one of those irritating device ‘features’ that cause so much grief for us bare-metal (assembler-language) programmers: any MCU GPIO pin that can be used for analogue input defaults to analogue from reset. A single line of code in the initialisation section fixed the problem and Hey Presto – with a clank and a wooosh, Elliott 920 assembler source code I had last seen in 1976 appeared on screen (Figure7). Well, it was exciting for me….

Next Time

I’ll be describing the PIC24 firmware for communicating with a host computer via the RS-232 channel. A good wallow in paper tape nostalgia may be on the agenda too.

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