I built a whimsical LLM-driven robot to provide running commentary for my yard: https://www.chrisfenton.com/meet-grasso-the-yard-robot/
HN user
fentonc
I was an architect on the Anton 2 and 3 machines - the systolic arrays that computed pairwise interactions were a significant component of the chips, but there were also an enormous number of fairly normal looking general-purpose (32-bit / 4-way SIMD) processor cores that we just programmed with C++.
I love stuff like this! I have a Kaypro 2/84, which supports a display resolution of 160x100 with colors ranging from green, to 'less green' to black, and I went down a rabbit hole of trying to push the graphics: https://www.chrisfenton.com/exploring-kaypro-video-performan... - I was eventually able to get it do display (short!) 50 fps video clips.
I built a more whimsical version of this - my daughter and I basically built a 'junk robot' from a 1980s movie, told it 'you're an independent and free junk robot living in a yard', and let it go: https://www.chrisfenton.com/meet-grasso-the-yard-robot/
I did this like 18 months ago, so it uses a webcam + multimodal LLM to figure out what it's looking at, it has a motor in its base to let it look back and forth, and it use a python wrapper around another LLM as its 'brain'. It worked pretty well!
Awesome project! I built a somewhat similar 30-pixel display: https://www.chrisfenton.com/the-pixelweaver/
Mine was entirely mechanical (driven by punch cards and a hand-crank), and changed all of the pixels in parallel, but a lot of the mechanism development looked extremely familiar to me.
I think a quad-CPU X-MP is probably the first computer that could have run (not train!) a reasonably impressive LLM if you could magically transport one back in time. It supported a 4GB (512 MWord) SRAM-based "Solid State Drive" with a supported transfer bandwidth of 2 GB/s, and about 800 MFLOPS CPU performance on something like a big matmul. You could probably run a 7B parameter model with 4-bit quantization on it with careful programming, and get a token every couple seconds.
The Cray PVP line was also doing double precision floating point, and could overlap vector memory operations with math operations. My guess is that you would need a microcontroller operating at several hundred MHz to beat a Cray-1 in practice. The later Cray-1/S and /M variants also supported a 10gbps link to an SSD of several hundred megabytes, which is hard to beat in a microcontroller.
Fun article! I was one of the architects on Anton 2 and Anton 3 at DESRES.
This is awesome! I recovered the only copy of COS (http://www.chrisfenton.com/cos-recovery/), but we never really had a way to use it.
I took a different approach by just making an FPGA-based multi-core Z80 setup. One core is dedicated to running 'supervisor' CP/NET server, and all of the applications run on CP/NET clients and can run normal CP/M software. I built a 16-core version of this, and each CPU gets its own dedicated 'terminal' window, with all of the windowing handled by the display hardware (and ultimately controlled by the supervisor CPU). It's a fun 'what-if' architecture that works way better than one might expect in practice. It would have made an amazing mid-to-late 1980s machine.
That's awesome sounding - I love how creative people got with mechanical designs before everything went digital.
This was one of my rare projects that was as fun to use as it was to build!
I spend all day writing C++ or Python, and like playing around with Turbo Pascal on a circa-1984 Kaypro 2 as a hobby machine - the projects are certainly smaller, but my edit-compile-run loop on my Kaypro is usually faster in practice (even running on a 4 MHz Z80 with 64KB of RAM compared to an 8-core 3+ GHz workstation with 64GB of RAM) than my 'modern' work. It's genuinely crazy to me how usable a 40 year old machine is for development work.
FPGAs are particularly amazing for this sort of project where you would otherwise need a custom ASIC that could never be even remotely economical to build (see my 16-core Z80 laptop as another excellent example: http://www.chrisfenton.com/the-zedripper-part-1/). It lets you play 'fantasy computer architect.'
I am now adding "Silicon Carver" to my resume.
It updates in pretty close to realtime (ie the simulator timestep is extremely close to the actual wall clock time required to compute the next timestep), so “animation” isn’t really the right word. If you let it go for a few hours it leaves fun star trails though!
I'm definitely packing this with me if I ever time travel.
It's . . . not great.
Author here! Most of my projects are kind of like this penny arcade comic (https://www.penny-arcade.com/comic/2011/06/13/the-hippothala...) - I saw where something was not, and said "No. This will not do." It's 2024 and a supercomputer wrist watch is possible, so now it exists =)
I came pretty close: http://www.chrisfenton.com/the-turbo-entabulator/
But mine was only 1/10-scale!
You're correct this isn't really a Cray other than the vaguely rounded shape, but it is still adorable and looks super fun to program.
I built this! It's amazing! It's a 16-core Z80 running at 140 MHz: http://www.chrisfenton.com/the-zedripper-part-1/
Many CPU/SoC systems could be made vastly simpler while maintaining binary compatibility if you're willing to sacrifice performance/area. Anything that's not visible from the ISA level can be implemented however one wants. You can cram more logic per pipeline stage, stall instead of having complicated bypass logic, etc. Much of the complexity of modern circuit design comes from the desire to eek out every last percent of performance from a process, which is completely unnecessary for a historical project like this.
Neat - I had never heard of ACE. In my (fairly limited) experience it works fine, although running the cores at 140 MHz (and the network) forgives a lot of sins. I actually wrote my CP/NET server as a regular CP/M application in Turbo Pascal, so I can't speak to other server solutions. The idea behind my ZedRipper was to basically turn a 'multi-user' CP/M system into a single-user/multi-tasking system, and it worked better than expected.
I still play around with Turbo Pascal on CP/M a lot for fun - it is a shockingly good development environment (even on a 4 MHz CPU my edit/compile/debug loop is usually <10 seconds, which is pretty fast even by modern standards). And it could all trivially fit in the L1 cache of a modern CPU.
I built a 16-core Z80 laptop running CP/NOS (the networked version of CP/M 2.2) - it's surprisingly great and useable: http://www.chrisfenton.com/the-zedripper-part-1/
It's like a windowed, multi-tasking environment where each process actually gets its own dedicated CPU/memory/display hardware and can run fully independent of the others.
We design custom silicon for doing molecular dynamics simulations for drug-discovery work: https://www.deshawresearch.com/technology.html
Lol - I built a standalone version of this for my 4yo (at her request). It has a temperature sensor and a bunch of LEDs that light up next to little pictures of outfits to tell her what she’s allowed to wear.
I believe his plans did include a general shift function - what he referred to as “stepping” up/down was just shifting by a digit
I've been very interested in mechanical computing for a while (even going so far as to build my own simple 3D-printed, hand-cranked computer!), but the whole analytical engine thing makes me wonder what might have happened if computing had developed more from the industrial-control / power-loom side of things rather than a need for scientific number crunching. A truly impressive amount of work was done by the mid-to-late 1800s with power looms - 'programs' 10s of thousands of cards long, speeds in excess of 3 Hz, 'production-level' reliability. The people building weaving mechanisms could have readily implemented something equivalent to a 4-bit microcontroller if they had been sufficiently motivated, which might have kicked off a computing revolution from the bottom up rather than starting with supercomputers and gradually figuring out how useful very limited microcontrollers were.