My first 'job' as a kid was working at Oasis Software on White Lightning, which was a Forth based game making kit for the ZX Spectrum (amongst other platforms). About a million years ago now. Or now ago million, if you know Forth. https://worldofspectrum.org/archive/software/utilities/white...
White Lighting was really a sprite editor packaged with an interrupt driven DSL for games, but back before DSL was a term. Forth was a good choice for a compiled target on the platforms back then, given the constraints. Ironically I do ruby now.
I've picked up Forth to code for Agon Light, which is a new spin on those old platforms - it's BBC Micro-patterned, but uses some modern chips to make things faster and roomier. Easy to develop for on emulator too. One of the complaints I've read about Forth on micros was that even 8Kb interpreter overhead would be too much for a commercial game - what I've gathered is that many people used it primarily as a macroassembler in that context. But I have 512Kb and 20MHz to play with, plus external display processing, so I can probably ignore that overhead and do just fine.
I find Forth quite a bit easier to work with when I treat it as an interactive stack machine and do the bulk of development through offline code generation. That gives me a best-of-both where I can do useful things interactively, but I can add compiler tech to help rein in and structure whatever I'm doing.
I frickin' LOVE the Agon Light. To me it's the most exciting and promising of the "retro-inspired new computer" designs.
I've messed about with Forth on the Commodore 64 (via THEC64). It's fun but I haven't dug too deeply into it, like building a game with it or anything.
I play around with White Lightening occasionally because of the ease of making games with it on C64 and the comprehensive documentation (PDFs of it have been preserved).
Yep, the tape to tape copying days were really happening around 1984 so the manual in either red or green paper was the only way to keep it selling. The sprite library package and Forth's closeness to machine code were its strengths. Not easy to work with though.
Some smaller ones, but nothing big. There was a user submission contest that got some traction, but the jump up from BASIC to using this was not easy. This was the time of 'rock star game devs' but interrupts, memory paging and sprite libraries probably crushed a few teenage dreams. An old video of what it could do https://www.youtube.com/watch?v=IgmZ2Ht-QiQ
From the manual (those were different times indeed!):
> We are also
interested to hear of any extensions or routines you may develop, and if
sufficient interest is shown we will start a News Letter, and possibly, even a
User Group.
I can only compare it with Abersoft Forth on ZX Spectrum. While I admire the Forth implementation in Jupiter Ace a lot, it lacks a lot of basic words. Users can often find them implemented in the manual, but they are not immediately available. 8kB ROM is really on the edge of usability. Jupiter Ace Forth uses an unusual approach to code editing based on decompilation instead of screens, which is closer to how Basic worked. Abersoft Forth was much faster and had better graphics support.
The Jupiter Ace, a comparatively weaker (ZX81-equivalent) computer, came with Forth built into its ROMs. The use of Forth was such an efficiency improvement over BASIC that, as I recall, simple video games could be written in its 1 KiB of program RAM.
I think it is direct threaded Forth but there is a conditional token table in there (tokens.asm). Thought it might be some clever hybrid of threading techniques, but I don’t see how tokens is used.
It's a build option, the variable 'tokenised' controls whether it builds tokenised or direct threaded. The macro DX outputs either a token or word depending on whether a token is available and whether 'tokenised' is set.
