Mitch Bradley was the author of a great deal of that Forth; his CForth is on GitHub : https://github.com/MitchBradley/cforth

(It might be easier than finding an old Sun machine)

I'm not a Forth programmer, but I used to be a Sun sysadmin. From what I recall, the Forth code on a SPARCstation is interpreted and pretty slow.

These docs support that: https://docs.oracle.com/cd/E19455-01/816-1177-10/816-1177-10...

The system supports FCode, which is processor-independent byte code. This allows expansion devices (like a card or peripheral) to bring with them their own platform-independent device drivers, which is pretty cool. So you could make a disk controller card and then any system that you plug it into could boot off it, no matter the CPU architecture.

Anyway, the point is, since it was mainly used for booting and diagnostics, I don't think they put much effort into performance. For it to be an actually good Forth environment, I think you'd want to have some way to run Forth programs as native code, either by adding the option to JIT the FCode instead of interpreting it or by adding a compiler that compiles Forth source to native.

Also, I believe the old PowerPC Macs (like G3, G4, and G5) used Open Firmware, so if you wanted this Forth experience, you have that option in addition to Sun workstations.

The G4 did indeed support Open Firmware: I had an MDD.

The text mode on the framebuffer was terrible on most machines, too.

Still, stop-a and then e.g. 3719 824 + 53 * . when you needed a little bit of arithmetic help was always a possibility ;)

> Also, I believe the old PowerPC Macs (like G3, G4, and G5) used Open Firmware, so if you wanted this Forth experience, you have that option in addition to Sun workstations.

So did the OLPC-1 where the non-FOSS nature of "Open" Firmware was a bit alien.