The Heath Robinson Rube Goldberg Computer, Part 1: Implementing a computer using a mixture of technologies from relays to fluidic logic

A plan comes together

Imagine a computer formed from a mixture of technologies ranging from relays to fluidic logic. Now imagine being able to create a single piece of such a computer (perhaps as small as a single word of memory) in the technology of your choice, and then using the Internet to run your masterpiece in conjunction with other portions of the system created by contributors located around the world! Author Clive (Max) Maxfield explains the creation of just such a computing engine and how you can be involved.


Clive "Max" Maxfield (, Author, Freelance

Clive MaxfieldClive (Max) Maxfield is the author/co-author of a number of books, including Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and How Computers Do Math, featuring the pedagogical and phantasmagorical virtual DIY Calculator.

In addition to being a hero, trendsetter, and leader of fashion, Max is widely regarded as being an expert in all aspects of computing and electronics (at least by his mother). Max was once referred to as "an industry notable" and a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.

03 October 2006

Welcome to the first in a series of articles describing the creation of a computing engine called The Heath Robinson Rube Goldberg (HRRG) Multifarious Technology Computer. This machine will be built using a variety of implementation technologies, including (but not limited to) relays, vacuum tubes, transistors, and simple integrated circuits -- also mechanical, magnetic, pneumatic, and fluidic logic -- and possibly some even more esoteric technologies.

In case you were wondering, this contraption (affectionately known as "The Beast") is named after British cartoonist and illustrator William Heath Robinson (1872-1944) and his American counterpart Reuben Lucius Goldberg (1883-1970). Robinson and Goldberg were both famous for creating illustrations of machines that were intended to perform relatively simple tasks, but whose implementations were incredibly complex such that they performed their tasks in exceedingly convoluted and indirect ways.

As you will come to see, it's probably safe to say that Heath and Rube would have been proud of us! In fact, this is such a multilayered project with so many diverse aspects, that it's easy to become lost in a maze of possibilities, so please bear with me while I explain how this all came to be and -- more importantly -- how anybody (including you) will be able to play a part in the creation of The Beast.

As a starting point, glance at Figure 1 below. This is a relay computer, created fairly recently by Professor Harry Porter III (standing next to the machine in the photograph). Professor Porter is a lecturer at Portland State University in the USA. You can discover more about Harry's computer by visiting his Web site, which provides photos and videos along with audio of the relays clattering away (see Resources for more details).

Figure 1. Professor Harry Porter's relay computer (courtesy Harry Porter)
Professor Harry Porter's relay computer (courtesy Harry Porter)

Doesn't this look amazing? Wouldn't you like to have one? Well, this is what sparked the HRRG project. I had long planned on creating a relay-based computer of my very own, but once I saw Harry's magnificent creation, there didn't seem to be much point because he'd already done such a fine job.

And then I started thinking -- imagine a series of cabinets like Harry's mounted around the walls of a large room. In the case of The Beast, however, the contents of each cabinet will be implemented using a different technology. Take the system clock, for example; this could be formed from a cabinet containing an antique clock. The swinging of the pendulum could be detected and used to provide the main system clock signal.

Alternatively, consider the famous old black-and-white horror film with the mad scientist crying: "It's alive, it's alive!" In the background, you may recall, there was a "Jacob's Ladder" formed from two vertical metal electrodes with a series of electric arcs buzzing their way from bottom to top.

Figure 2. An example home-made Jacob's Ladder
An example home-made Jacob's Ladder

One of these could form the system clock cabinet; a photo-detector could detect the arcs, where alternate arcs would represent "tick" and "tock" signals -- following a power-on-reset (or a hard or soft reset), the first arc will be taken to be a tick of the clock. (Find home-built Jacob's Ladders -- along with many other interesting items -- on Mike Harrison's "Electric Stuff" Web site; see Resources).

The more one thinks about this, the more fun it becomes. Over the last few months, numerous people have offered ideas such as using relay-based memories from old jukeboxes or mechanical memories from old church organs (these suggestions are gathered in an ever-evolving paper on the HRRG project -- see Resources).

In fact, the memory and input/output (I/O) cabinets provide a simple starting point from whence you can really let your imaginations soar. Consider a cabinet containing a number of eight-bit output ports, for example. Each of the bits could be represented by a servo-controlled puppet: logic 0 and 1 values could cause the puppets to wave small yellow and blue flags, respectively.

Alternatively, consider a memory cabinet employing some form of pneumatic system that uses a ping-pong ball and two adjacent plastic cone-shaped receptacles to represent each bit. A ball in its associated left-hand receptacle could represent a logic 0, while the right-hand receptacle could represent a logic 1 (or vice versa) as illustrated in Figure 3.

Figure 3. An eight-bit word implemented in a pneumatic memory cabinet
Figure 3. An eight-bit word implemented in a pneumatic memory

In this case, when the system writes an eight-bit byte of data to one of these memory locations, the pneumatics could "puff" the ping-pong balls associated with that byte into their appropriate receptacles. The value in a memory location could be read back again in a number of ways. For example, the ping-pong balls could be sprayed with conductive metallic paint, and each non-conducting plastic cone could have two bare conducting wires inside it. These wires (which, for simplicity's sake, are not shown in Figure 3) would be close to each other, but not touching. When a ball is inside a cone, it will short the wires and complete that circuit. Thus, when the system reads a byte from one of these memory locations, it would actually be determining the location of the conductive balls.

How exciting! The only problem is that actually creating an entire computer system as a mixture of different implementation technologies from the ground up would be an incredibly time-consuming and resource-intensive project to be undertaken by a single person, organization, or academic institution. What is required is a cunning solution... which brings us to the point of this article series.

When virtual and physical worlds collide

Before leaping into the fray, you should know that a number of folks are involved in various aspects of this project; you can find out more by visiting the "Who is to Blame" Web page described in Resources.

One key consideration is that anyone should be able to get into the game and share in the fun, especially interested individuals and young people at high school and college. As I previously noted, however, building the entire machine would be a tremendous undertaking. On the other hand, constructing a single cabinet containing (for example) only a few memory locations would be a much simpler task.

Thus, the idea is to split the HRRG computer into a number of well-defined functions. For reasons that should be obvious after seeing Harry's computer at the beginning of this article, these functional units are often referred to as "cabinets." In the case of memory (ROM and RAM) and input/output (I/O) ports, the system can have as many cabinets as one might wish, where each of these cabinets will have a range of memory addresses associated with it. Of course, a key element in this project is defining the interface and the protocol that the various physical cabinets will use to communicate with each other and with the outside world.

The next task will be to create a program called "The HRRG Emulator" that will run on an IBM-compatible PC.

Amongst many other things, this emulator will include virtual representations of the default cabinets (you will be able to add your own virtual cabinets -- including nice graphical interfaces -- as you wish). As soon as it's finished, this emulator (and an associated assembler) will be made freely available. This means that you will be able to immediately create a program in the HRRG's simple assembly language, assemble it, and run it on the emulator.

If you subsequently decide to create a physical version of any of the cabinets, you can do so in the technology of your choice. By means of a USB port, you can then connect this physical cabinet to your PC, and the physical cabinet will run in conjunction with the virtual cabinets running in the emulator. As you create more and more physical cabinets, these will replace their virtual counterparts, until you eventually have the entire HRRG implemented in the physical domain.

But wait, there's more, because the emulator will use the Internet to support both virtual and physical units located around the world. This means that if you create a relay-based ALU cabinet located in America, for example, you will be able to run your cabinet with a physical memory cabinet implemented in fluidic logic located in say, Australia, with other physical cabinets located in other countries, and with any "missing" cabinets running in the virtual world.

The mind boggles! There are so many ramifications to this that it makes your head spin. Take the Central Processing Unit (CPU) to be used as a basis for the HRRG, for example. As it happens, a small calculator circuit board featuring an FPGA-based version of this CPU is currently under development (see the "Who is to Blame" Web page in Resources). Eventually, it might be possible for you to build, say, an Arithmetic Logic Unit (ALU) cabinet out of relays, mount it on your office wall, and connect it into this calculator circuit board, where it would replace the ALU running in the FPGA.

You've probably got enough to be thinking about for now. Part 2 of this series will consider the various functional units forming "The Beast," including discussions on the CPU to be used along with any decisions with regard to splitting this CPU into functional units (cabinets). Part 3 will introduce the emulator software, and Part 4 -- well, you'll just have to wait and see...



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

Zone=Multicore acceleration
ArticleTitle=The Heath Robinson Rube Goldberg Computer, Part 1: Implementing a computer using a mixture of technologies from relays to fluidic logic