The Sinclair ZX81 and Timex/Sinclair 1000 computers, despite their limited hardware specifications, attracted several FORTH language implementations in the early 1980s. Two notable versions — Tree-Forth (originally called Pluri-Forth) by Tree Systems (1983) and ZX Forth by Artic (1982) — took distinctly different approaches to bringing this powerful programming language to these machines.
Background: The fig-FORTH Standard
Before diving into the specifics, it’s important to understand the baseline. The FORTH Interest Group (FIG) established the fig-FORTH standard to provide consistency across different FORTH implementations. This standard, developed through the community established by FORTH’s creator Charles H. Moore, defined core vocabulary, stack operations, memory management, and control structures that programmers could expect across platforms.
Traditional fig-FORTH implementations were threaded interpretive languages (TILs), using an inner interpreter that stepped through addresses for each word. This architecture provided flexibility but came with performance overhead.
Tree-Forth: The Compiler Directive Approach
Architecture and Philosophy
Tree Systems’ Tree-Forth took a fundamentally different architectural approach. Rather than implementing a traditional threaded interpretive language, Tree-Forth functioned as a “compiler directive language” or “Threaded Compiler Language.” Instead of storing addresses that an inner interpreter would process, it compiled direct subroutine calls for each word. This eliminated the inner interpreter overhead entirely, resulting in faster execution in most programming applications.
The implementation resided in an 8KB EPROM and required a minimum of 2KB RAM.
Standards Compliance
Tree Systems explicitly acknowledged that Tree-Forth deviated from the fig-FORTH standard in several ways:
Adherence to Standards:
- Contained “most of the standard FORTH commands”
- Matched fig-FORTH standards where possible
- Supported standard FORTH structures like colon definitions (
: word ... ;) - Implemented standard control structures (IF…ELSE…THEN, DO…LOOP, BEGIN…UNTIL, etc.)
- Used standard stack manipulation commands (DUP, DROP, SWAP, ROT, etc.)
Notable Deviations:
- Could not include all fig-FORTH commands due to memory space constraints
- Added non-standard commands specifically for multi-tasking functionality
- Implemented a compiler directive architecture rather than the standard interpretive approach
Unique Features
Tree-Forth’s standout feature was its sophisticated multi-tasking system—unprecedented for a computer in this price range:
- Event Scheduling: Tasks could be scheduled with AT, IN, and EVERY commands
- Task Resolution: 1/60th of a second maximum resolution
- Concurrent Tasks: Up to 18 tasks could be scheduled simultaneously
- Background Execution: Tasks could run in the background while editing
- Individual Clocks: Each task had its own 32-bit clock
- Event Queue: 63-deep event queue for pending tasks
The implementation also featured a unique visual editor with split-screen functionality. The upper portion served as an editing area while the lower portion functioned as an execution console, allowing programmers to test code interactively while editing.
Memory Architecture
Tree-Forth implemented a sophisticated memory organization:
- Separate 16-bit number stack and 8-bit character stack (both independent from the processor stack)
- Dictionary space growing upward from 4000H
- User-definable screens for custom display layouts
- System variables and buffers organized in fixed memory locations
ZX Forth: The Traditional Approach
Design Philosophy
ZX Forth, released a year earlier than Tree-Forth, took a more conventional approach to FORTH implementation. The documentation emphasized it as a “compiled language” that ran “very fast, usually five times faster than in BASIC,” while maintaining FORTH’s characteristic flexibility and interactive nature.
Standards Compliance
The ZX Forth glossary reveals strong adherence to FORTH-78 standards:
Standard Features:
- Complete implementation of standard stack operations
- Standard comparison and logical operators
- Traditional colon-definition syntax
- Standard control structures
- The
<BUILDS...DOES>construct for creating defining words - Standard memory access operators (@, !, C@, C!)
The glossary explicitly marks certain definitions with flags like “LO” (Level Zero definition of FORTH-78) and “L1” (Level One definition), indicating conscious adherence to the FORTH-78 specification hierarchy.
Character Set: ZX Forth supported ASCII characters, though excluding lowercase—a concession to the limitations of the Sinclair’s character set. The documentation noted that “the following listing includes all of the ASCII characters,” demonstrating an intent to work within industry standards despite hardware limitations.
Implementation Characteristics
Unlike Tree-Forth’s compiler directive approach, ZX Forth appeared to maintain a more traditional FORTH architecture:
- Interactive command execution
- Standard word definition and dictionary management
- Traditional FORTH glossary notation (showing stack effects like “n1 n2 — f”)
- Support for both execution and compilation modes
The documentation showed a standard FORTH learning curve, with the User’s Manual explicitly stating it was “not meant to be a tutorial for learning FORTH” and recommending Starting FORTH by Leo Brodie, the same reference book used throughout the FORTH community.
Memory Requirements and System Integration
Both implementations required specific memory configurations:
Tree-Forth:
- 8KB EPROM for the language itself
- Minimum 2KB RAM required
- Could be installed via circuit board replacement
- Supported switching between FORTH and BASIC via hardware switch
ZX Forth:
- Loaded from cassette tape (compiler took 3½ minutes to load)
- Minimum 16K RAM required
- Required separate editor loading (4 segments)
- More flexible deployment but slower startup
Development Environment
Tree-Forth’s Integrated Approach
Tree-Forth provided a sophisticated integrated development environment:
- Split-screen editor: Visual editing with cursor control
- Real-time compilation: Compile individual lines or entire screens
- Screen management: User-definable screen regions
- Immediate feedback: OK prompts after successful operations
- Error codes: Comprehensive error reporting system
- Printer support: Toggle output to printer with single command
ZX Forth’s Modular System
ZX Forth took a more modular approach:
- Separate editor: Loaded as a distinct component (4 segments)
- Interactive execution: Direct command execution at the prompt
- Glossary-driven: Strong emphasis on understanding word definitions
- Standard FORTH workflow: Traditional compile/test cycle
Performance Characteristics
Tree-Forth
Tree Systems claimed exceptional performance:
- “Extremely Fast. Run 30000 0 DO LOOP in 1 second”
- Faster than interpretive FORTH due to elimination of inner interpreter overhead
- Claims supported by the architectural difference (subroutine calls vs. address interpretation)
ZX Forth
ZX Forth emphasized:
- “Five times faster than in BASIC”
- Compiled language execution
- No specific benchmark comparisons to other FORTH implementations
Use Cases and Target Audience
Tree-Forth
The multi-tasking capabilities and real-time clock suggested Tree-Forth targeted:
- Real-time control applications
- Data acquisition systems
- Multi-process monitoring (the documentation gives an example of monitoring patient respiratory rates)
- Users willing to invest in hardware modifications
- Advanced programmers needing maximum performance
ZX Forth
The more traditional implementation suggested ZX Forth aimed at:
- FORTH learners and educators
- Users wanting standard FORTH portability
- Those preferring software-only solutions (no hardware modification)
- Programmers familiar with other FORTH implementations
Extensibility and Customization
Tree-Forth
- Custom vocabularies: Development fee for adding custom words to EPROM
- Hardware expansion: Support for extension ROM/RAM
- Floating-point: Promised as future extension EPROM
ZX Forth
- Standard FORTH extensibility: Full support for defining words
- <BUILDS…DOES> construct: High-level defining word creation
- Software-based: All extensions through standard FORTH definition mechanisms
Adherence to FORTH Philosophy
Both implementations maintained FORTH’s core philosophy of:
- Extensibility: Users could define new words using existing vocabulary
- Low-level access: Direct memory manipulation capabilities
- Stack-based operation: All operations centered around stack manipulation
- Structured programming: Support for control structures without line numbers
However, they differed in emphasis:
Tree-Forth prioritized:
- Performance through architectural innovation
- Real-time capabilities
- Integration with the Sinclair hardware
- Practical real-world applications
ZX Forth prioritized:
- Standards compliance
- Compatibility with FORTH literature and examples
- Accessibility (software-only installation)
- Traditional FORTH learning path
Limitations and Compromises
Tree-Forth
- Incomplete fig-FORTH vocabulary
- Required hardware modification
- Higher learning curve for the multi-tasking features
- Non-standard commands that might not port to other FORTH systems
ZX Forth
- Slower startup (cassette loading)
- Multi-segment loading process
- Less sophisticated development environment
- No built-in multi-tasking capability
Historical Context and Legacy
Both implementations represented significant achievements in bringing a sophisticated programming language to extremely limited hardware. The ZX81/TS1000, with its Z80 processor running at 3.25 MHz and minimal RAM, was hardly an obvious platform for FORTH. Yet both Tree-Forth and ZX Forth demonstrated that careful design could overcome hardware limitations.
Tree-Forth’s compiler directive approach anticipated later optimization strategies in FORTH implementations, showing that adherence to traditional architecture wasn’t necessary to capture FORTH’s essential characteristics. Its multi-tasking capabilities were genuinely remarkable for the hardware platform.
ZX Forth’s more conservative approach ensured compatibility with the broader FORTH ecosystem, making it easier for programmers to transfer knowledge and code between systems. Its closer adherence to standards meant that examples from FORTH literature would work with minimal modification.
Conclusion
The comparison between Tree-Forth and ZX Forth illustrates two valid philosophies in language implementation:
Tree-Forth asked: “How can we maximize what this hardware can do?” It sacrificed some standards compliance and required hardware modification, but delivered exceptional performance and unique capabilities like multi-tasking that were typically found only on much more expensive systems.
ZX Forth asked: “How can we bring standard FORTH to this platform?” It maintained closer compatibility with fig-FORTH standards and required no hardware changes, making it more accessible to users and more compatible with existing FORTH resources.
Neither approach was inherently superior, they simply served different needs. Tree-Forth appealed to users who needed maximum performance and real-time capabilities and were willing to invest in hardware modifications. ZX Forth served those who wanted a more standard FORTH experience without hardware changes, accepting the performance trade-offs that entailed.
Both implementations demonstrated the flexibility of FORTH as a language concept—it could be adapted to different architectures and use cases while maintaining its core characteristics. This adaptability was itself a validation of Charles H. Moore’s original vision for FORTH as an extensible, customizable language that programmers could shape to their specific needs.
For enthusiasts and historians of vintage computing, both implementations represent fascinating examples of what skilled programmers could achieve with limited resources. They stand as testaments to an era when language implementation was as much about creative problem-solving in constrained environments as it was about following specifications—a spirit that continues to influence systems programming to this day.