Project:Ball Computer

From London Hackspace Wiki
Revision as of 21:57, 25 April 2011 by Flux (talk | contribs) (Added thoughts on memory and encoding.)
Jump to navigation Jump to search

Logic will get you from A to B. Imagination will take you everywhere. -- Einstein

Part 1: Introduction

Or how Flux's imagination got the better of him..

Long ago, when I was young, I received a copy of The Way Things Work. It's an awesome book and I spent many happy hours studying it. The two things that fascinated me most were nuclear power and electronic adders. I wanted to make my own water-based adder (I didn't have any uranium). I didn't really know where to begin and it stayed firmly in the realm of my imagination.

Fast-forward twenty years and I've just joined the Space. Somewhere buried in my subconscious the idea is dusted off and *bam* it's back (2011-04-12). Water-based logic gates, memory, coloured water displays (think of the mixing)... this is what the MakerBot was made for! How many transistors did the Intel 4004 have? Only 2,300...

Today (2011-04-13) I mentioned this to Tom (Reading hacker extraordinaire) over tea. He loved it too and we started to think it through. Stay tuned for Part 2 where we get a teeny bit practical.

Part 2: Where to begin?

Or how Hoxton Lake will have have to wait

A bit more reflection suggested water might not be the best place to start (Artag suggested caution). Ball bearings are easier to deal with a less messy. Some early areas to consider include:

  • Logic gates
  • Encoding
  • Memory

Logic Gates

The core of the machine, AND OR and XOR gates should allow the creation of an adder.

  • Could treat ball bearings like a fluid (example project by David Bober)
  • Could use magnetised balls for 1 and unmagnetised balls for 0 with some sort of clock mechanism
  • Could use different ball sizes for 1 and 0 (e.g. 4mm as 0 and 5mm as 1 - in which case a 0 ball weighs roughly half a 1 ball)
  • Consider using compressed air or solenoids to hold ball bearings in place

Will has ordered 100x4mm (0.2610g) and 100x5mm (0.5099g) high grade steel ball bearings for experimentation.

Encoding

Do we use pure decimal or binary coded decimal or something else? BCD has the advantage it's easy to convert for display, but is a bit more complex to process arithmetically.

What about letters and other characters? The larger we make a byte the more complex everything becomes. One possible scheme is to use 4-bit nibbles for numbers with BCD, with two nibbles used for to represent a character or instruction. In BCD no number is of the form 11xx. So could separate letters from numbers by using 110x xxxx for letters and punctuation (room for 32 of them) and 111x xxxx for instructions (also leaves room for 32 of them).

Some possible examples: 0000 = 0 0010 = 2 1001 = 9 1100 0001 = a 1101 0010 = r 1110 0001 = read nibble from memory 1110 0010 = write nibble to memory 1110 0011 = add

This isn't especially compact, but would seem to make it easy to separate different operations.

Memory

Some approaches within a plastic grid (could use stepper motors and simple arm to move or read balls):

  • a ball indicating 1 and a void 0
  • a magnetised balls indicating 1 and non-magnetised 0
  • a 5mm ball representing a 1 and a 4mm ball representing a 0

Do we read individual bit or a whole nibble? Nibbles make addressing easier. With a 16x16 grid of nibbles (so 32x32 ball slots) you'd be able to use 2 nibbles as an address (16x16 = 256 = 2^8). This would give 1 kilobit (256 nibbles) of memory. If we're using 4/5mm bearings and you allow 8mm by memory cell then this memory would be about 26cm to a side.

More to come...