My daughters came home for the summer soon after my last post and as my work area is in their normally vacant bedroom, I chose to work more on the software side of things for the summer. Well, that turned into an adventure that’s kept me occupied for the last six months. They’ll be home for the holidays soon again, so vacating their bedroom once again, I’ll write briefly about my experiences with the Forth programming language (if there’s some interest, I’ll write more, but given that my source code isn’t anywhere close to being publishable I’ll leave it here for now).
My monitor program was coming along well, having gained the ability to disassemble code and spit out debug information on breakpoints. But I was getting tired of adding functionality one piece at a time. What I needed was a programming language.
A common next step at this point in a 6502 project is to get Basic up and running. Being a popular option, there are plenty resources available for the 6502 hobbyist, here, here and here for example. But I’ve never liked Basic and wanted something more modern.
There are many cross compilers for the 6502, cc65 being one I discuss in my Coding post. But I wanted something that ran natively on the 6502, like Basic, but not Basic itself. But what modern language would work with the 6502’s limited resources? A google search yields plenty of answers. David Wheeler has a very good summary of programming languages for the 6502 and some good ideas are presented on Stack Exchange. Browsing through the lists looking for something modern, I noticed Python. That looked interesting.
I’ve done a few things in Python before, but not enough to really get to know it. I like that you could do so much with so little code and always wanted to get more into it. Also, it’s interpretive style seemed perfect for the native programming language I wanted for my 6502. Implementing it on the 6502 seemed like a great opportunity to accomplish many objectives.
However, practicality destroys many a wish and it did here as well. Python is very resource heavy and not really practical as a 6502 operating system. That doesn’t mean people haven’t tried developing it for 8-bit systems. See here and here for example. But I wanted something a bit more full-fledged.
Diving deeper I saw a lot of references to Forth. I’d never heard of the language before, but it offered an interpretive environment, was low on resources and offered low level interaction with the underlying hardware. Standard Forth contained all of the routines I had been developing for my operating system as well as the ability to extend itself by compiling new routines right from the command line. It seemed perfect for my 6502. Want to try it out? Check out Easy Forth to give it a quick go.
The classic Starting Forth tutorial provides a good overview of the language though personally I find the illustrations juvenile and don’t think they add anything to understanding the language. Given the longevity of the book, I suppose I’m in the minority in that viewpoint. I’ll leave it for you to form your own opinion. Reddit has a Forth sub that also has links to a lot of resources.
Given the ease of implementation and likely the independent nature of developers, numerous versions of Forth are available. FIG-Forth was written for the 6502 based Apple II back in 1979. It’s still very relevant today over 40 years later.
A not uncommon implementation of Forth from back in the day started with a small kernel of machine specific code with the remainder of the system written in Forth itself. This allowed Forth to be easily ported to a new system by simply writing a new kernel.
JonesForth follows this path and is a great primer for learning how to write your own Forth operating system (the source code links in that post are likely broken so try this GitHub mirror if you’re interested). For those wanting something more off the shelf, Scot Stevenson’s Tali Forth 2 is a fairly modern Forth package for the 6502. The downside, there’s always at least one, is that it requires 24k of ROM. My build 3 only has 16k so I had to strip out a few components to get it working on my system. Luckily Scot’s design makes this fairly easy to accomplish.
There have been efforts to standardize Forth over the years which seem to have had some success. I’ve found programs from decades ago that today aren’t far from standard. The nice thing about Forth is that if you come across something non-standard, you can easily modify it to work on standard systems.
Take for example the 1982 real-time strategy game Cosmic Conquest. As a kind-of Reddit challenge, several of us got this old game working on modern systems. Surprisingly the hardest part was typing in the code from an old Byte magazine article. The code was mostly standard with only slight modifications needed to accommodate current hardware. Here is the main GitHub of the effort and my own version for the 6502. Here’s a short video of the game running on my 6502, posted on Reddit.
For me, I’ve adopted the Forth-2012 Standard as the basis for my 6502-Forth. I don’t know how widely adopted this is, but it is convenient for me in that it provides a readily available web-based reference. It appears however, that Forth remains a highly individualized language that users customize for their own systems. This is perfect for the 6502 and today’s embedded systems.
My work on Forth has caused me to rethink the memory allocation for my current build. It’s not so much that I’ve been memory constrained with my current Forth, it takes up only about 9k so far. Rather, I found in working on the Cosmic Conquest game that having extra ROM allowed an easy path to loading source code into py65, a 6502 emulator (probably worth a separate post itself). As such, wasting almost 16k on I/O doesn’t make sense. With this I’ve ordered a programable logic device to better refine my address decoding and get back most of that wasted 16k. More on that in my next post.
What are your experiences with Forth? Let me know in the comments.