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.

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.

Building this definitely felt like constructing a lightsaber from spare parts: slow, deliberate, but it works and you understand every piece of it.

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.

Exactly. Working in a constrained environment invites innovation.

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".

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.

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.

Right? Backprop was published in 1986, a year before HyperCard shipped. Attention is newer, but a small model like this was buildable.

I built a system that lets AI agents (like Claude) interact with Classic Mac OS System 7 through OS 9 on real hardware and emulators.

The architecture is simple: AgentBridge is a native Mac app that polls an inbox folder for text-file commands, executes them via the Mac Toolbox, and writes responses to an outbox folder. An MCP server on the modern side reads and writes those files. The shared folder can be a NAS, an emulator's host directory, or anything else both sides can access.

No SSH. No screen capture. No input injection at the host level. No system extensions or modifications. AgentBridge is just a regular Mac application, the only interface between the AI and the Mac is a folder full of text files.

The protocol is intentionally minimal: line-oriented key-value pairs, CR line endings, MacRoman encoding, parseable in ~50 lines of C with zero dynamic memory allocation. Commands cover window enumeration, app launching, menu selection, mouse/keyboard input, clipboard access, file browsing, and process listing.

The whole pipeline is verified working end-to-end: Claude Desktop -> MCP server -> Synology NAS -> AgentBridge on a Mac -> launches AppleWorks and types into a document.

Some fun bugs I hit along the way: a short overflow that silently prevented the text buffer from ever being populated (the 32KB max message size overflowed a 16-bit signed parameter to -32768, causing an early return), and PostEvent delivering keyboard events to AgentBridge's own event queue instead of the frontmost app under cooperative multitasking.

Built with Retro68 (GCC cross-compiler for 68k/PPC Macs). The MCP server is GPLv3 TypeScript; the Mac app is closed-source with pre-built binaries available. The protocol itself is open for anyone to implement.

This is awesome.