One of the big difficulties with programming on 8-bit machines was that if you wanted to use anything other than the built in Basic, compilers were generally expensive. Usually the cheapest alternative to Basic was Assembly, a huge leap for a self taught programmer to make.
Compilers for C, Pascal, and other languages of the time were hundreds of dollars, which was a lot for a (often young) hobbyist to pay. When I first heard about gcc in the early 90s, I was blown away because compilers in my head were something that only big corporations, universities, and the government could afford.
While there was no shortage of homebrew software in the 8-bit era, I have to wonder how much more there would have been if the major manufacturers of computers had made access to developer tools inexpensive and easy instead of letting the third-party market fill that role with small volume, high cost products.
64FORTH was relatively inexpensive ($40-$50) and might be another reason why the C64 had so much software developed for it.
There were C and Pascal compilers in the $50 - $60 price range for the C64, but they were often time consuming to use. The process of editing a source file, saving it, loading a compiler, compiling it to find errors, then re-loading the editor was tedious with a stock 1541 disk drive. ( Some editors had syntax-checkers built in to avoid having to exit the editor to find simple mistakes ... others used the BASIC editor to enter source with BASIC line-numbers. )
For me, tinkering with Forth on a C64 was attractive because I could interact quickly with the compiler, getting immediate feedback when I was toying with different concepts.
Indeed. That feeling wrt to GCC (although way before my time) is why I always found the GNU/Linux meme a bit harsh. The GNU project moved heaven and earth to make free software a reality, I don't mind giving them credit.
I purchased my Commodore 1541 floppy drive at Kmart which I think is still barely in business. The more commonly known equivalent today would be Walmart. In other words they were common enough to be stocked at low end discount department stores.
You can tell the difference between regions by watching retro computing YouTube channels. Those with North American creators generally use floppy drives or emulators with their retro equipment. European/UK creators are more likely to use tape or tape emulators and if they use floppies reference that they would have never been able to do so back in the day.
This is really neat. Not so long ago I happened upon a disk image containing FIG-Forth for the Atari 8-bit computers and had some fun playing with it on an emulator for a couple hours - poking registers to toggle on the hardware sprites, dumping the display list and modifying it to create custom display modes, etc. Unfortunately this was some stripped down version in a single EXE file that was missing the editor or anything stored in blocks on the disk, so it wasn't practical to really write anything interesting with it.
I can’t believe anyone made Adventure Construction Set in Forth. That was a great C64 game. I’ve never programmed in Forth, but I can’t imagine writing something so complex in it.
> I can’t imagine writing something so complex in it
Actually FORTH despite being so low level lends itself perfectly for writing complex software in it because it allows for a great bottom up style programming in a similar fashion as LISP does. You would start your application (or game) with higher level words abstracting all machine details and then write your game engine on top. Then you would go on defining a set of words allowing you to define levels and characters easily on top of the engine. So well written FORTH applications were just layers and layers of specialized DSLs working together to solve complex problems. With the right abstractions, the code was easy to read in the end and also easy to port across different architectures.
Unlike LISP, however, FORTH did not come with memory management or a complex run time. So it was way better suited for the small 8-bit micros back in the 80s. One of the British micros even came with a FORTH runtime instead of BASIC: https://en.wikipedia.org/wiki/Jupiter_Ace. But, unfortunately, BASIC turned out to be much more popular, although usually being too slow and inflexible.
I remember BASIC 2.0 -- which shipped with the C64 -- not providing any kind of abstractions around the particular hardware features the machine provided (like sound, graphics and sprites). It was very frustrating especially for beginners that just wanted to create their own little games. But that was almost impossible without embedded machine codes and the resulting BASIC programs much harder to read and understand than FORTH code.
> BASIC 2.0 [...] not providing any kind of abstractions around [...] sound, graphics and sprites [...] almost impossible without embedded machine codes
I remember trying this a handful of times with code examples I found in magazines or books, using arcane strings of seemingly arbitrary numbers manipulated by POKE and PEEK commands. I felt very limited in what I could do considering the amount of time required, and like I was doing data entry instead of learning something I could use in the future. So I gave up on that.
It's hard when you're the only person you know interested in coding and there's no internet.
I remember watching this video yesterday and realizing how how expressive FORTH can get. The wikipedia page really doesn't do it justice. Fortunately their second program made use of multiple words and better shows off the language but it would be cool to see someone do a real deep dive into some of the cool DSLs you can effectively write.
It's not the C64, but the DOS game Starflight was written in Forth.
And hey, considerably more and even larger games have been written in assembly, compared to which Forth is definitely high level (arguably even to other programming languages, but let's not get into that unless Don Hopkins joins this thread)
I've also heard it's proponents say that it also provides very high functionality density for for a given memory footprint. Statically compiled languages tend to inline and unroll a lot and optimization control can be very coarse or fiddly. Forth forces (forthes?) you to decide this because is it more like a structured assembly language + runtime. Certainly intriguing.
I've benchmarked every 8-bit language I could get my hands on. Interpreted BASIC is typically 1/50th the speed of assembly. Forths are typically 1/5th to 1/10th the speed of assembly, depending on the function, which means Forth is 5 to 10 times faster than BASIC, depending on the function. Python is also about 1/50th the speed of C.
Forth is always faster than interpreted BASIC. The speed of compiled BASIC depends on the compiler. Some compilers did very little and didn't increase the speed much because they tried to remain compatible with the ROM BASIC in the system. Compiled BASICs which went their own way were as fast as Forth, occasionally faster.
I think of an example like the ZX Spectrum which is pseudo-compiled. Stuff like addresses for goto line references and variable addresses were pre-baked (I think?), it was stored tokenised, and the maths library was stack-based like Forth. Under the hood they don't even have to be that different, tokenised Forths are a thing.
And Forths and BASICs can be fast or slow, really depends how much time is spent optimising.
Compilers for C, Pascal, and other languages of the time were hundreds of dollars, which was a lot for a (often young) hobbyist to pay. When I first heard about gcc in the early 90s, I was blown away because compilers in my head were something that only big corporations, universities, and the government could afford.
While there was no shortage of homebrew software in the 8-bit era, I have to wonder how much more there would have been if the major manufacturers of computers had made access to developer tools inexpensive and easy instead of letting the third-party market fill that role with small volume, high cost products.
64FORTH was relatively inexpensive ($40-$50) and might be another reason why the C64 had so much software developed for it.