There’s something quietly impressive about getting modern AI ideas to run on old hardware (like OP's project or running LLM inference on Windows 3.1 machines). It’s easy to think all the progress is just bigger GPUs and more compute, but moments like that remind you how much of it is just more clever math and algorithms squeezing signal out of limited resources. Feels closer to the spirit of early computing than the current “throw hardware at it” narrative.
There is an absolutely beautiful rendering of the Mona Lisa encoded at some point in the digits of pi. If you know the position, it's really easy to plot the image.
But first you have to find that position.
This is both simultaneously false, and true but largely meaningless. If you mean the Mona Lisa is somehow directly encoded somewhere in pi, then of course it’s not. It’s just a number.
If you mean that when you feed the numbers starting with some offset of pi into a specific algorithm you will get a rendering of the Mona Lisa, then yes, but so what? Allow me to introduce you to the PiMona algorithm. I won’t bother you with the implementation details, but it takes exactly one integer parameter. If it’s 3, it produces a beautiful rendering of the Mona Lisa. Anything else and it generates random garbage. Turns out, it’s really easy to find where the Mona Lisa is encoded in pi! It’s right there at the start.
But let’s say you meant that the digits of pi at some offset, when encoded properly and fed into any algorithm that is theoretically capable of generating the Mona Lisa will cause that algorithm to do so, then sure. But that’s also true of random noise, and says more about the algorithm and the nature of random numbers than about the Mona Lisa somehow being encoded into the fabric of the universe (which I’m sure isn’t what you meant, but I’m just saying there’s nothing really special about pi in that regard, except that as far as we know, it continues infinitely).
I think they're going for more of a 'monkeys will eventually produce shakespeare' thing here. Which you can apply the same argument to - monkeys do not know english, don't know what they're typing, and theoretically english could devolve to a state where every sentence could be qualified as shakespeare, right? Your argument just seems unnecessarily pedantic.
Exactly. Working in a constrained environment invites innovation.
Now do this on a Casio Watch next :)
Hello, if there are no XCMDs it should work adequately in HyperCard Simulator. I am only on my phone but I took a minute to import it.
I had no idea your simulator existed. No XCMDs, correct; everything is pure HyperTalk. I just ran a few training steps and they complete in a second or two. Thank you for importing it!
I gotta ask. Your scripts have comments like -- handlers_math.hypertalk.txt at the top. Are you using some kind of build process for a stack?
More of a copy-paste process. The scripts are written as .txt files in Nova on my Mac Studio, then pasted one at a time into HyperCard's script editor on the classic Mac. The files are kept separate because SimpleText has a 32 KB text limit.
As an alternative, you might consider letting Hypercard itself open the text files and 'set the script of' as needed.
Yup, that would have been easier. It's been decades since I've done anything with HyperCard. I had to re-take the built-in intro course again :)
Would that overcome the size limit?
Does HyperCard implement its on text handling for the HyperTalk editor that doesn't rely on the TextEdit toolbox service (which IIRC is the source of SimpleText's 32 kB limit)?
Fields appeared to use TE and I suppose the script editor was pretty much limited to 32 kB of text for that reason, although you could have any size of text in a variable.
Curiousity got the better of me, and I just tested it in Infinite Mac.
The HyperTalk editor is indeed limited to 32 kB.
It's certainly possible that this limit only applies to editing scripts, as it's unlikely TextEdit was used in the process of interpreting them, but I don't have time tonight to investigate.
Later versions of HyperCard supported OSA scripts as well, now I'm also curious what the size limit is for (presumably) compiled AppleScripts stored in HyperCard stacks.
This is great!
I first studied back-propagation in 1988, at the same time I fell in love with HyperCard programming. This project helps me recall this elegant weapon for a more civilized age.
Building this definitely felt like constructing a lightsaber from spare parts: slow, deliberate, but it works and you understand every piece of it.
I love this. From reading the nuts-and-bolts "parameters" (haha) of your implementation, I get the impression that the fundamental limit is, well, using a 32-bit platform to address the sizes of data that usually need at least 48 bits!
Thanks! The precision was a happy surprises, HyperTalk uses Apple's SANE library, which gives you 80-bit extended precision. The interpreter speed and the lack of arrays were a challenge. Rediscovering what HyperCard could do was half the fun of this project.
It's strange to think how modern concepts are only modern because no one thought of them back then. This feels (to me) like the germ theory being transferred back to the ancient greeks.
Right? Backprop was published in 1986, a year before HyperCard shipped. Attention is newer, but a small model like this was buildable.
Lisp is from 1960's and with s9 you can do even calculus with ease, in an interpreter small enough to fit in two floppies.
On the Greeks, Archimede almost did 'Calculus 0.9'.
People did think of many of these core concepts decades ago, but they did not have the resources to put them into practice.
I think it's incredible to see the potential that is still locked up in old hardware. For example the 8088 MPH demo. Amazing what he was able to do with an 8088 and CGA. All this time the hardware had that potential, but it took decades to figure out how to unlock it, long after the hardware was considered obsolete. Imagine the sort of things that might be done later down the road with hardware of 0-20 years ago if somebody really dug into it to that level.
Retro console homebrew and demoscene are all about this. There's a lot of fun stuff going on in N64 homebrew right now: https://www.youtube.com/watch?v=rNEo0aQkGnU
On the N64, an equirectangular viewer a la QT3D or the current street view is not precisely a wonder.. m68k's could do that at a similar resolution. It's simple 3D in the end.
For the rest, yes, it's really astounding until you push these polygons while moving around in a game loop...
8088 MPH demo is revolutionary. I have a plan to try and backport the developments from that demo, plus other optimizations learned in the last 40 years, back into the original 8088 Elite PC version. I had Gemini Pro write a PoC using 8088 assembler to create a CGA flat-poly renderer for the ships, which worked great. Next step is to use Claude to disassemble the original Elite binary so I can figure out where the rendering code lives and try to start patching it.
8088 MPH: this one, right?
They created a better Pacman for Atari 2600, better Outruns for Amiga's and whatnot.
That 8088 MPH demo is a tour de force. Which tells you that the millions of Apple laptops being bricked right now instead of being recycled could have some amazing use if it were possible to wipe them clean and reuse. Sigh.
Well, we've set it up so the survival of employees and their families is tied to old products being bricked.
Where's the code for the actual HyperCard and building of the .img? I only see the python validator in the repo.
The stack is the code. You can view it directly for each button or examine the per-page script. As far as I know there isn't a compiler that lets you write standalone code and turn it into a stack. The stacks are dropped into Disk Copy disk images to preserve their resource forks. Both modern macOS and Git both strip resource forks, so the disk image is the only reliable container for distribution.
So a hypercard is compiled machine code of button clicks and key presses? Weird. I guess that could be macro'd somehow
HyperTalk is an interpreted scripting language. The scripts are stored as plain text inside the stack and interpreted at runtime. It's kind of like a Visual Basic form where the UI and the code live in the same file. You can open any script, read it, edit it and immediately run the newly edited script.
Neat. Looks like I found my new benchmark for my ARM64 JIT for BasiliskII :)
(still debugging it, but getting closer to full coverage)
The training loop is heavy on floating-point math and string parsing, so it should exercise the JIT nicely. I'd love to hear how it performs!
I just started doing PPC/SheepShaver as well, since 68K was stalling… Will come back to this eventually.
The architecture of macmind looks pretty interesting
Thank you! The constraints made it interesting. HyperCard doesn't have arrays, so the entire model, weights, activations, gradients, is stored as strings in hidden fields. All of the matrix math is done with "item i of field".
This is very cool. Any more demos of inference output?
Thanks! The quickest way to try it is the HyperCard Simulator link someone just posted in this thread: https://hcsimulator.com/imports/MacMind---Trained-69E0132C — go to the Inference card, click New Random to fill in 8 digits, then click Permute. The model predicts the bit-reversed permutation of all 8 positions. The pre-trained stack gets all inputs correct.