F83 is an astonishing system. If you want to see the remnants of just a boatload of work, dig deep into the F83 system.
F83 is a top drawer Forth system. It implements the Forth 83 standard, and it’s in the public domain.
It runs on CP/M and MS-DOS.
It has the editor, a single step debugger, virtual memory, multi tasking, an assembler, full source code, and it is self hosting (on top of its host OS) via its meta-compiler. But you could readily port it to a system with no real OS, needing little more than console I/O and some kind of block device.
It’s a hybrid block file based system. Historically you would just hand entire block volumes that would then be managed by Forth directly. Here, you create pre-allocated files that are then used in a customary Forth block style. It did not use text files for source code. It also has shadow screens for documentation. Shadow screens are where you divide the block volume in two, and the first half is source code, and the second is documentation. So if you have a 200 block volume, then screen 4 is code and screen 104 is documentation.
If you want to see the source code of a word, just type VIEW <word> and it will show you the screen that defines the word. The compiler embeds the source screen in each definition. A simple command will bring up the shadow screen to show the documentation.
It also has a word decompiler, and a threaded dictionary for better search performance. It has hundreds of words.
The real trick is imagining the work that went into this system. The bootstrapping process that converted this from a likely hand keyed, assembly based FIG Forth to what became F83. Starting with a pure, block screen based system to one that works with a file system, shifting code around on disk with little more than offsets and a copy routine that’s little more than a block move.
On a slow, 2 floppy 8080, where resetting the system was the routine way to get back to a known state. Using a powerful, yet very dangerous language, rife with traps. It’s like doing self surgery with a mirror.
The holes they must have blasted in the floor trying to avoid shooting themselves in the foot. Repeatedly. I’ve spent hundreds of hours studying this system, it’s really an amazing effort.
Forth! I was programming in those days myself (though only a little bit on CP/M), and was getting surprised that many people here seemed to think the only alternatives were C or assembly. I learned to program in Basic, then learned some assembly, and finally discovered Forth circa 1984. It was perfectly suited to developing on 8-bit machines -- about as powerful as C, trivial to compile, easy to drop into assembly if you needed to optimize a low-level function.
If I remember correctly, I didn't learn C until 1989, when I was working on 16-bit machines...
i agree that forth is a pretty bug-prone language. it's only about as low-level as c (less type-checking, but more metaprogramming) but far more bug-prone. more so than assembly i think. but i haven't written a lot of forth; i wrote this game in forth last weekend: https://asciinema.org/a/672405
(i might actually try porting it to f83)
incidentally f83 also apparently ran on the 68000, but generally with a 32k limit
tom zimmer's f-pc was an ms-dos forth with all of f83's features but able to use the full 640 kibibytes of ram, which f83 couldn't
one thing that 8080 floppy systems excelled at was resetting. you could reboot cp/m in a second or two
F83 is a top drawer Forth system. It implements the Forth 83 standard, and it’s in the public domain.
It runs on CP/M and MS-DOS.
It has the editor, a single step debugger, virtual memory, multi tasking, an assembler, full source code, and it is self hosting (on top of its host OS) via its meta-compiler. But you could readily port it to a system with no real OS, needing little more than console I/O and some kind of block device.
It’s a hybrid block file based system. Historically you would just hand entire block volumes that would then be managed by Forth directly. Here, you create pre-allocated files that are then used in a customary Forth block style. It did not use text files for source code. It also has shadow screens for documentation. Shadow screens are where you divide the block volume in two, and the first half is source code, and the second is documentation. So if you have a 200 block volume, then screen 4 is code and screen 104 is documentation.
If you want to see the source code of a word, just type VIEW <word> and it will show you the screen that defines the word. The compiler embeds the source screen in each definition. A simple command will bring up the shadow screen to show the documentation.
It also has a word decompiler, and a threaded dictionary for better search performance. It has hundreds of words.
The real trick is imagining the work that went into this system. The bootstrapping process that converted this from a likely hand keyed, assembly based FIG Forth to what became F83. Starting with a pure, block screen based system to one that works with a file system, shifting code around on disk with little more than offsets and a copy routine that’s little more than a block move.
On a slow, 2 floppy 8080, where resetting the system was the routine way to get back to a known state. Using a powerful, yet very dangerous language, rife with traps. It’s like doing self surgery with a mirror.
The holes they must have blasted in the floor trying to avoid shooting themselves in the foot. Repeatedly. I’ve spent hundreds of hours studying this system, it’s really an amazing effort.