If you are all-out for the smallest code possible, and you are going to be writing different games, which means you're going to keep running into the size problem, you might want to consider creating a Token Thread Code (TTC) Forth instead of using Tali. See http://www.bradrodriguez.com/papers/moving1.htm for the AFAIK best introduction to the differences. It will be slower - possibly a lot slower - but you could strip the Forth down to the bare essentials and use single-byte tokens for fantastic size games.

I'd quite like to understand what's going on with this game which makes it so large: it is certain that the game can't be more compact? (Having said which, how much memory are we talking about?)

If I was writing a graphics intensive Forth application, I'd try a really lean Indirect Thread Code (ITC) Forth ( or maybe even a Token Thread Code Forth if memory was really tight ) and write the graphics routines as code words.

Just from a quick look at the examples presented, it looks like this Forth code might be a direct translation of C into Forth. That is something Jeff Fox advised against.

It depends on what you mean by "direct." Most of the highest level words like ColorTile have the same purpose as the corresponding C functions, but the subwords and internal functionality are implemented from scratch. I knew the purpose of the functions, so there was no need to translate the C to Forth line by line.

The great part about Forth is that you can actually go in and change the things that you think should work differently. I'll be interested to see what you come up with for a solution to this problem, as I also end up pasting very large inputs at times, and it would be nice to have it stop at the first error instead of having to scroll back and find it. I often want to throw away all the rest of the input, as a word that didn't compile will mess up most of the code that follows, and I would need to modify ACCEPT to do that. A flag in zero page, like you suggested might work well for my situation, and I could look for a control code (perhaps CTRL-Q) to allow regular input again. You will find (although I commented it out) where CTRL-P and CTRL-N were handled in ACCEPT for the input history. Do be careful as some CTRL combinations are handled by the terminal and not passed to the application (at least on Linux, anyway), such as CTRL-L (clears the screen).

ABORT (which you will find really just falls into QUIT) might be one place to make changes. It is called (jumped to, really, as it resets the stack anyway) after the error message has been printed. If you want the location where the error message is actually printed, you will need to look at "error:" in taliforth.asm. I believe this routine is used for all of the errors that would end up calling ABORT. You'll also want to look in "xt_number:" (just before the "_all_converted:" label) in native_words.asm if you want the name of an unknown word.

If Forth can't find a word, it tries to turn it into a number, so the spot where it realizes that the text at the input is not a number (and therefore an unknown word) is actually in the NUMBER routine.

You have the luxury of writing your own emulator, so you could make a "stderr" that goes somewhere else without actually needing to add hardware. You could just make an extra address that you write to for output, and then write some forth words to use it.

Keep us posted on whatever you end up with for a solution.

Symetric math is often better for polar math. Floored math is better for single lines or XY rectangular vectors. Symetric math makes zero an unique point. Floored math makes zero an offset. This can be vary important when doing multiple precision math on things like XY tables. Using math that rounds towards zero can really mess things up because it makes zero a unique point. You can't smoothly cross zero. As soon as you try to include offsets, thing go bad quickly.
It is easier to understand which is which by doing /mod instead of just mod. Both still need to follow the rule Dividend=Divisor*Quotient+Remainder. I've learned that I prefer floored math for most calculations but most processors round toward zero.
As an example. If one makes a table of sine and cosine with symetric math and incrementally calculates the next point around a circle, it won't close. If you use floored math, the circle will be a little off center but will close. This happens even for floating point but most don't notice the tiny error until many revolutions have been completed.
Dwight

Creating a headerless version is going to be more work than I thought, so I won't be going down the rabbit hole after all. Instead, I should be able to fit the remaining code into additional banks by copying the entire 12k Tali Forth 2 installation into each of those banks.

It looks like you might be thinking in 'C' or at least not as much in Forth. For example, this piece of code from the word ColorTile:

What about a version of TaliForth2 with separated headers? The headers could reside in a separate set of banks. Each header would need an additional field to point to the word's executable code. The header banks could be switched in just long enough for the interpreter/compiler to get the address of the word to interpret or compile.

If you mean defining a word called count that does "dup c@ swap 1+ swap" then you are no better off if your goal is performance. Either Tali Forth 2 will inline the word, which is essentially what I am doing by hand, or it will keep count and you lose performance jumping into it and out of it. The only improvement, if I understand you right, is making the source slightly more readable but possibly at the cost of speed.

No. I mean using the word COUNT already supplied by TaliForth2.