Here is the complete 8086 Assembly source code, commented, for fig-FORTH.

• fig-FORTH 1.0 source code from 1981

The forth interest group created various implementations, all listed here:

• other source code

This list includes implementations for: the 1802, 6502, 6800, 68000, 6809, 8088, 9900, the Alpha Micro, Apple II, Eclipse, IBM-PC, Nova, Pace, the PDP-11, and the VAX.

The point being proven, FORTH is out there with copious amounts of code in various architectures. It was thus easy to get a kind of FORTH running on the SD-8516. I quickly became obsessed with it.

Forth is one of the most fascinating and misunderstood languages ever created. Invented by Charles “Chuck” Moore around 1970 (originally for controlling radio telescopes at Kitt Peak National Radio Astronomy Observatory), it’s a stack-oriented, concatenative, postfix language that feels like a mix of assembly, a REPL, a compiler, an operating system, and a philosophy all in one.

Everything in Forth is a “word” (a subroutine). You define new words that build on old ones, and the language is extremely extensible; you can even change how the compiler works from inside the language itself. It runs in a tiny footprint (many classic implementations fit in 8 to 16 KB total) and gives you immediate, interactive feedback.

Both were born in the interactive era of microcomputers and minicomputers, and both let you type something and see results instantly. That’s where the similarities end:

BASIC is English-like and line-numbered (“10 PRINT ‘HELLO’”). Forth is Reverse Polish Notation (RPN): `5 3 + .` prints 8. It feels closer to a pocket calculator or assembly than to English.

BASIC encourages quick-and-dirty scripts. Forth encourages building a custom vocabulary of words that exactly match your problem domain (e.g. telescope words like `POINT`, `TRACK`, `EXPOSURE`).

BASIC is usually a slow interpreter. Forth uses threaded code (or direct/native compilation in modern versions) — it’s compiled as you type, so it feels blazingly fast even on 1980s hardware.

Forth destroys classic interpreted BASIC on the same machine. On 8-bit computers (Commodore 64, Apple II, etc.) Forth was legendary — often 5–10× faster than Microsoft BASIC for the same tasks. Real benchmarks from the era and modern recreations show Forth loops, math, and hardware control running at near-assembly speeds.

In embedded/microcontroller work, well-written Forth is usually within 10–30% of optimized C (sometimes faster because there’s no function-call overhead or hidden runtime).

What's more, FORTH binaries are dramatically smaller; a 10k FORTH binary will often have an equivalent C program binary of about 100k.

Forth has a steep initial learning curve; you must keep the stack in your head; but once past that it is astonishingly simple. The entire language core can be implemented in a few hundred lines of assembly. There are no complex syntax rules, no precedence battles, no huge standard library to learn.

Chuck Moore’s philosophy was radical minimalism: “If the program is too big, you’re doing it wrong.” Most serious Forth programs stay tiny by modern standards because the language forces you to rethink the problem until the solution shrinks.

You can often use Forth to write more serious or useful applications than in a language like BASIC. FORTH has a different structure to BASIC – and even to C.

Forth was used for:

• Real-time telescope control systems (1970s–80s)
• Image processing at NASA Goddard and Naval labs
• The entire Open Firmware boot system (used in Sun workstations, PowerPC Macs, and many servers)
• Spacecraft: NASA’s Voyager probes, Space Shuttle Star Tracker, Philae lander on Rosetta, Galileo magnetometer, and derivatives of Moore’s RTX2000 chip still fly on NASA missions
• Industrial control (factories, Owens-Corning distributed controllers)
• Embedded microcontrollers today (Mecrisp, FlashForth, etc.) for sensors, robotics, and IoT

You can write “large” applications in Forth – people have built full operating systems, compilers, and CAD tools, but the culture strongly prefers composing many tiny words instead of monolithic code. Still, large Forth programs are usually smaller and more maintainable than equivalent C because of the extreme factoring.

Forth is not a toy language. Companies and agencies paid real money for it in the 1970s–90s because it delivered

• Tiny memory usage
• Real-time performance
• Interactive debugging even in deployed systems (you could patch spacecraft code from Earth!)

It’s still actively used in niches where C is too heavy or too slow to develop: radiation-hardened space systems, FPGA soft cores, boot firmware, and low-power microcontrollers. The language has an official ANS Forth standard (1994), commercial implementations (polyFORTH, SwiftForth), and vibrant open-source ones (Gforth, Mecrisp-Stellaris).

If you’re a BASIC user thinking “I should move to C like everyone else,” consider Forth as the road less traveled. Here’s a direct comparison:

Pros of Forth over C:

• Interactive REPL like Python – edit, test, run instantly. C requires compile-link-run cycles.
• Far smaller code size and memory footprint.
• Blazing development speed for embedded/real-time work. Many Forth programmers claim 2–10× faster productivity than C for hardware-close projects.

1. Extreme extensibility – you can add new control structures, data types, or even change the syntax.
2. Built-in assembler and direct hardware access without pointer bugs biting you as often.
3. The whole system (editor + compiler + OS) lives in RAM with you. You can change anything.

Cons of Forth vs. C - Stack/RPN thinking is weird at first and can lead to “stack spaghetti” if you’re sloppy. - Smaller ecosystem. Fewer libraries, fewer job postings, less Stack Overflow help. - Less portable than C in practice. - Manual memory management is more exposed (no automatic anything). - Community is tiny compared to C.

The three major drawbacks (tiny community compared to C, less portable compared to C, and the hardware is more exposed) can be mitigated or turned into strengths.

One, if it's a tiny community, it's easier to stand out. Two, less portable means that you might not find a good FORTH compiler for your system. This is mitigated strongly by GNU Forth and by the ease at which you can get a FORTH running on your own, in assembly language. I did it on the SD-8516 in just a couple of days (see source code above). Finally, the hardware being more exposed is often considered a plus; pointers in C being one of it's most beloved and central features, you have “even more” of this pointer loving goodness in FORTH. Seen this way, I don't think FORTH is inferior to C, it's just different. The world went with C mainly, I think, because it's easier to think in C logic. FORTH is a stack machine. What else to say?

If you loved BASIC’s immediacy but hated its slowness and lack of power, Forth gives you the best of both worlds: BASIC-level interactivity + C-level (or better) performance and control, plus a ridiculously small footprint. You stay in an interactive environment the whole time – no leaving the “interpreter” to compile. With FORTH, you get instant compilation that feels like an interpeeter. And, you can add Assembly code natively in the sytsem. Unlike in C, which requires special rules for interfacing with Assembly. With FORTH, it's immediate and direct. For embedded, retro computing, hardware hacking, or just wanting to feel close to the metal without C’s ceremony, Forth is often the more enjoyable and productive choice.

Many people who “graduated” from BASIC in the 1980s went to Forth first (especially on machines like the Jupiter Ace or BBC Micro) and only later touched C – and some never left Forth because it just felt right.

C “won” over Forth (and many other contemporaries) in the programming landscape of the 1970s and 80s not because it was objectively superior in every technical dimension, but because of a combination of ecosystem momentum, practical engineering trade-offs, institutional adoption, and social/cultural factors that favored C for large-scale, team-based, and cross-platform work.

Many people who loved Forth's immediacy, minimalism, and raw power (especially on constrained 8-bit machines like the Jupiter Ace or BBC Micro extensions) stuck with it for decades, particularly in embedded, real-time, or niche hardware control. But C pulled ahead decisively in the mainstream due to it's connection with UNIX.

Unix (and later Linux) were written in C from very early on. After a brief PDP-7 experiment with assembly/B, UNIX in C spread through universities, research labs, and eventually commercial workstations (Sun, DEC, HP, etc.), C became the de facto “implementation language” for operating systems, tools, and everything built on top of them.

Once you have the OS kernel, compiler, editor, debugger, make, libraries, and userland utilities all in C, the incentive to use anything else drops dramatically.

Forth never had an equivalent “killer app” ecosystem that pulled in masses of developers. It stayed more niche (telescope control, industrial automation, some embedded, Open Firmware on PowerPC/SPARC).

C has a relatively fixed syntax and semantics protocol (even with preprocessor tricks). C code mostly looks like C. You can read someone else's C code without learning a completely new dialect. This is important when discussing maintainability of code in teams. See: Rob Pike's 5 Rules of Programming.

On the other hand, Forth is extensible to the point of being a meta-language. Every serious Forth project reinvents parts of the language (new control structures, parsing, object systems, etc.). This makes large team collaboration harder. You have to learn the local “dialect” of Forth for each codebase. To be absolutely fair, many C programs essentially define their own language by writing helper functions. But because the interface is so well defined (i.e. header files) it still “looks like C” and can be somewhat excused. FORTH programmers may consider this unfair, but forcing people to implicitly document their code via header files played a huge role in C's adoption. It is ironic that today, header files are considered bad meta.

The result of the above is that Forth excelled for solo hackers or small expert teams who control the whole stack; but C was seeon to scale better for 10–100+ person projects, open-source libraries, and commercial software houses. Forth programmers will tell you that means, by the law of averages, you can't have as many smart people on a large project and that is the “real reason” and there is some truth to that. So if this perception is to be averted documentation must be king, no FORTH project can survive without source code level comments and an external design document. If played right, external design documents can be more useful and user-friendly than browsing comments in a header file.

C compilers produce standalone binaries/libraries that are easy to ship, link, and integrate (`.o` files, `.a`/`.so`/`.dll`, headers). Forth systems are usually interactive environments – you ship source + “load this file/block” instructions. Binary distribution was rare outside commercial Forths (polyFORTH, SwiftForth).

In the 1980s–90s, when floppy disks, slow networks, and proprietary hardware ruled, shipping pre-compiled C binaries/libraries was vastly more practical for vendors, ISVs, and end-users.

By the mid-1980s, high-quality C compilers existed for almost every architecture. The introduction of GCC from 1987 onward exploded this. OTOH, Forth implementations often required hand-porting the tiny kernel–assembly primitives for threading/NEXT/etc. to each new CPU. Fun for hobbyists, but a barrier for production work.

C's “portable assembler” reputation (with `#ifdef` for quirks) won out for writing drivers, firmware, and cross-platform tools.

Forth's stack/RPN style and “write worse programs faster” risk polarized people. You either loved the freedom and minimalism or hated the mental overhead. “dup swap rot drop” spaghetti is real. In contrast, C felt “normal” – step by step – structured like Algol/Pascal but with low-level power. It didn't force a paradigm shift as radical as Forth's.

C quickly became the safe, fashionable choice. It has resume value. If you knew FORTH that was great, but if you didn't know C, it was bad.

In short, C won because it was good enough technically while being excellent sociologically and economically. It rode the Unix wave, scaled to teams and enterprises, and became the lowest-common-denominator glue language.

Forth “lost” the popularity war but it never really died – too legit to quit! It carved out (and still holds) strong niches where its strengths – tiny footprint, interactive on-target development, extreme factoring, real-time predictability – matter more than broad adoption. People who “never left Forth” often stuck with it because those niches aligned perfectly with their work. Spacecraft, microcontrollers, custom hardware, personal hacking joy.

Let me close with a list of games and programs written in FORTH. What's on this list might surprise you!

Several official Atari 7800 console games were developed in Forth as well. It was surprisingly common for quick ports and prototypes. Games like Karateka, Hat Trick, and Worms were written in Forth. Notably the Forth source code for Worms (1983) is available on GitHub.

FORTH saw critical commercial success in the business world as well. RapidFile (1986, Ashton-Tate) was a flat-file database manager written in Forth. Ashton-Tate was big in databases back then (dBase III fame), so this reached business users.

The open boot / open firmware on Sun SPARC stations and PowerPC Macs, as well as many embedded systems were written in FORTH. You dropped to an “ok” prompt on boot for diagnostics/config. Millions of machines ran Forth at startup without users knowing. Millions. Forth does have it's legacy to consider!

• BASIC: Can write programs immediately. Easy, linear learning curve.
• Python: 80 to 90% of BASIC or Lua programmers can be comfortable in under a week.
• C takes 2 or 3 weeks of pain to get pointers and structs and such, and you get better at it with time over the long run.
• Java takes 3 to 6 weeks due to it's OOP and verbosity.
• Forth The learning curve of C or Java compressed into the first week. Most will quit in the first week. But those survivors who make it through the first week often say they began writing real code faster than in C afterward, because there’s so little to learn.

Bindings for SDL, SDL2, OpenGL and many other vital libraries exist for FORTH – as well as C bindings. In the end, it is a blue sky language, yours to discover.