@Max, That's a RAM!!! "A ball bearing in its associated left-hand receptacle could represent a logic 0, while the right-hand receptacle could represent a logic 1 (or vice versa)"
At least for this RAM type the 'charge' and its 'stable states' will be more 'visually' representable. We will even be capable of seen the 'charges moving' from one stable state to the other! I'll like to see that!
It should be possible to reduce the speed update lag by employing an accelerometer to calculate the velocity during times of acceleration or deceleration. This might be slightly more compute intensive in an FPGA, but should be do-able in a microcontroller as well.
@Victor: I specially like those green nixies from the old cassio calculators, all contained in the same vacuum tube.
Tasty!!! One of my background hobby projects is to build a simply 4-bit processor out of a mix of tecxhnologies (relays, vacuum tubes, transistors, magnetic cores, etc.) and you can be Nixie Tubes will feature in there somewhere...
@bobdvb: "Was that really the most efficient mechanism?" It depends on what your primary parameter "efficiency" referes to. Lookup tables are very efficient in execution time (clock cycles required for completing), but could eventually require much more LEs or cells in applications like this one.
@Max, "Call me "old fashioned" if you will, but I LOVE anything to do with Nixie Tubes...", Call me too.... I specially like those green nixies from the old cassio calculators, all contained in the same vacuum tube.
Okay, I admit I don't know much about VHDL and FPGA programming, but a lookup table for the speed? Was that really the most efficient mechanism? At least I would have expected the leading 0's to have used something shorter.