Copy the long link into your browser. It's a simpler, more steam punk way to drive the pendulum, Omit the clockworks if you like.
The pendulum clock idea can be quite accurate. I suggest the pendulum consist of a rod with a magnet as its bob. As the magnet passes a coil at the bottom of it's swing (maximum velocity) it generates a pulse in a coil. Regenerative feedback of this pulse can then drive the coil which kicks the pendulum in repulsion to keep it swinging. Early electronic clocks did this with a transistor or two (probably germanium PNP). The pulses also drove a mechanical solenoid which advanced a wheel in steps equal to 1/2 the pendulum period and in turn drove the clocks gears. Incidentally, a 1 meter pendulum has a 1/2 period of almost exactly a second. At one time, making such a pendulum a standard meter was considered but abandoned because of variations in the earths magnetic field etc.
Now, setting aside the pure brainstorming nature of it, there are some underlying structural concerns to make it happen.
The design of the clocking scheme and handshake protocol for the interconnect is not trivial, if we really want such liberty in the timing for the modules.
Clearly, a traditional synchronous design with a central clock is not what you have in mind. Are you thinking of implementing the interconnect with a packet-oriented "bus"? One possible implementation would be to use packet with tokens to identify and submit data between each module, with a fully static design, i.e., the slowest module sets the pace for the transactions.
That way, the controller can dispatch micro-ops to the modules, and wait for the completion of tasks, handling the synchronization of the "buses", even if some modules are thousands of times slower than others. If well implemented, a program could successfully complete a "hello world" sequence in a matter of one month, and everyone could follow the micro-ops hapening via the internet.
If the underlying packet protocol (e.g. tcp based) together with the wireless / wan circuitry (possibly 802.11b), and embedding the interconnect rules can be implemented in a blackbox, and that would be all that anyone would need to implement his/her cyberpunk trip to work over the network of modules.
Talk about hardcore steampunk cloud computing.
Actually I think we can make this happen -- and it will be a lot easier for folks to get involved than you might think -- once I've finished writing about the various technologies I've been considering (which I will be doing once a week for the next few weeks) I will move on to consider the real-world implementation details.
You know, I think this would be an incredible, irresistible contest for promoting science and technology interest, if not just plain old fun.
Imagine an entire planet of high-schools, interconnected, with steampunk HRRG computers.
cool! The capture of the random data could be via a snapshot of the ants scattered through an area of the ant farm. That would produce images very similar to an old TV set capturing static.
Or else, a few high-gain electret microphones could capture the actual noise the ants do in the interior of one chamber. One could capture one ant scream once in a while.
Another HRRG module that comes to mind is the advanced numeric coprocessor.
To keep the SteamPunk style to the Max, we could use a crank-driven Curta II calculator as the core logic for the math engine.
The selection of the operands (input registers) and the operation of the crank shaft (pipeline logic clock) can be carried-out through very complicated contraption with a series of gears that run on energy accumulated in a wound spring.
The output interface would be FPGA-based video character recognition logic that would recognize the result digits and send them to the bus, via the wireless circuitry.
Of course, to keep the steampunk visual, the operands and results would be displayed by nice Nixie Tubes, housed in a beautifully crafted wood panel.
A nice final touch would be to have the Curta shaft noises amplified and played back by a class-A tube audio amplifier.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...