Yeah, I'm not 100% sold on "drive". There's a few competing ideas here -- initially I called it a "loom", but then I wanted to lean more into the analogy of loading a disk, so "drive" kinda won out.
I get the feeling there's some word in the vicinity of "clock" that I'm missing. Something like "metronome", "pulse", "synchronizer" etc -- because you're right, the (primary) purpose of the drive is to deliver phase information to the disks. Drawing a bit of a blank tho.
That's exactly what I was aiming for! I always thought Turing Tumble was such a cool concept, by why not miniaturise it?
Funnily enough I'm currently building out a "Duplo" concept to make roons easier for kids. It's a disk with double-thickness bars (so a 4x4 grid instead of 8x8) but that loads directly onto the standard disk drive, so everything stays compatible. Still a WIP tho!
So I don't think this specific implementation has practical use cases (someone prove me wrong!), but there's a really really cool general point here--
We've had this technology for centuries.
Seriously. This doesn't need transistors or clever materials. Mechanically, it's much less complicated than what (say) 18th century clockmakers were doing -- it's just bars going up and down!
So if you'd asked me 200+ years ago, I'd say: this device can compute nautical charts, calculate differential equations, and some third incredibly useful thing. Nowadays we can do all that much better with silicon etc, and I don't see this competing practically on that playing field...
... but I think it's useful mental technology to notice that there were simple ways to perform arbitrary computations, accessible much earlier on in the tech tree, that sort of got skipped for some reason. So while roons is probably siloed to education/experimentation/fun, I really hope it inspires someone to go -- what else are we missing?
Thank you! Yeah, I was trying to lean into the idea of "shrink yourself down into a computer and physically manipulate the bits", think it's the best way to understand what computers are actually doing.
Spintronics is really wonderful, not just for its cleverness (which is extreme) but also the total concept and aesthetics -- absolutely something I'm aspiring to.
And yeah these are all 3D printed. Agree with your sentiments around community stuff, I don't have any fixed ideas there but I would be absolutely delighted to see how people can build on this. There are so many possible physical cellular automata to explore; this is just one.
If you ever open up the designs or want another set of eyes to print on some other devices / take a crack at generating new components, please let me know (looking forward to the kickstarter).
With the FDM-printed prototype version there's a noticeable "a mechanism is occuring" sound, largely due to layer lines. Tbh it's not too loud rn but I'm confident we can get it smooth and whisper-quiet using any vaguely sane manufacturing technique (defaulting to injection moulded ABS but we have some options). The marbles/roons themselves are silent, it's just a question of getting the barrel cams to play nice.
That sounds like the right general category, but maybe not specific enough? We could call it an Uticus Key and see if we can get the name to stick, that might be funny. (Thanks for the kind words!)
Yes, fantastic question! 10x10 is actually way more than we need -- don't know the minimum but I suspect 2x2 is possible. The interactive tutorials sketch out an approach to this. My instinct is to use SAM with timers for memory/program, then there's a couple of approaches in the tutorial for the instruction processor. Toying with the idea of an OISC to minimise space requirements. Tho we can always add a motor to the encabulator if we need to drive a larger grid!
Would subleq work on this? Also, the 'ascii' output array/grid would be like a whiteboard, and a Forth on this would look like the computers from "Slouching towarsf Bedlam" text adventure.
Maybe it would need 5 minutes to show a prompt, but, if it works, it would be the greatest homage to computing (and Chuck Moore) ever.
There's Eforth for subleq, and the muxleq version
feels almost like a native Forth on speed.
The muxleq repo has the original subleq too.
You can set the options for floating point and the do...loop
(among others) in the Forth file and then you could
just recompile the DEC file.
With the do...loop it's closer to the standards.
And, yes, I can mimic for...next with ease with
most ans forths such as pforth.
If any, I can link an already recompiled and more featured DEC file here.
I'm absolutely going to need a few hours to properly digest this, but here are my preliminary thoughts:
You could almost certainly do a subleq in roons! Tbh it may end up being a practical approach to making a compact full computer -- though seems like it might compromise legibility. This is way outside my wheelhouse, thank you for the links, I have a lot of reading to do.
Re: an ASCII grid -- I explore this a little bit in the tutorials, but because of the up/down nature of the loom, each marble only occupies 25% of the surrounding whitespace, so this kind of display doesn't end up very visible. This is why I'm leaning more towards the peripherals approach for rendering stuff.
Or just send the keys to a typewriter, as some guy did with a ZMachine, Asterisk and the mentioned device. But it would need a microcontroller, or a way to roll a ball in a precise way to type down a letter.
Absolutely yes! I prototyped a hopper peripheral that doubled as marble storage. It hooked into the gear grid and used the rotation to drive a helical lift to carry the marbles up to the surface, where they'd enter the edge of an adjacent disk.
I ended up setting it aside for 2 reasons:
1) Lack of time -- sad to say but I had to focus on getting the roons core ready. Too much to do!
2) The HDD peripheral -- this is a WIP that compactly stores and emits bitstreams. The way it's designed, it can be set to "reservoir" mode, which emits the continuous marble bitstream like you suggest. I figured it'd be redundant to have both a hopper and HDD, so I scrapped the hopper for now.
I'm grateful to Rockwell for their excellent research, but I think they really dropped the ball on side fumbling -- any competitive encabulator in 2025 really needs to be using bifurcated resonance.
Thanks! Glad to hear the simulator was worthwhile, took me ages to hack it into shape.
I did actually experiment with adding markings on the edges of the path roons, so that when you put them together, the "phantom channel" becomes visible. Ended up looking pretty cluttered though so I scrapped it.
I get the feeling there's some word in the vicinity of "clock" that I'm missing. Something like "metronome", "pulse", "synchronizer" etc -- because you're right, the (primary) purpose of the drive is to deliver phase information to the disks. Drawing a bit of a blank tho.
(Thank you for the feedback and encouragement!)