Julian Skidmore aka Snial is writing about writing a Forth for the VIC-20 - a classic small-RAM 6502 keyboard-sized computer.

Part 1, the appeal of the VIC-20.





Part 2, the different types of Forth interpreter.



(For me, these diagrams are much more digestible than a textual description.)

Consider a hybrid of the two. A secondary would be a list of one-byte or two-byte tokens

• One byte (with the sign bit set) treated as an index into a 128-element table of addresses of most common words
• Two bytes, (with the sign bit clear), to be treated as the high address byte
  The second byte is the lower address byte

The inner interpreter NEXT routine might look something like:

The diagrams *are* well done. They're found at the second of the two links Ed posted.


Something like, yes.

But I think...... should be...
Also, when a two-byte token is fetched there's another increment of the pointer at ippage -- but it's just an 8-bit increment. It's lacking a test for roll-over into the high byte.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

wups, yes ippage+1. contents of ippage is always a 0, and the pointer within that page is in Y


True. In PETTIL (a direct-threaded Forth) I'm used to having the compiler insert the word PAGE (to increment IP+1) within a secondary when it crosses a page boundary. That might be possible here too.

I wondered about that. It's an idea worth remembering.

Yup. And it could be applied in all cases -- ie, regardless of whether the page crossing results from the fetch of an 8-bit or of a 16-bit token.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The intended tradeoff here is lose clocks to gain bytes, so we can squeeze more code into a stock 5K VIC-20, so a one-byte PAGE token is the way to go. But include the ability to have more than 128 words in the dictionary. I can imagine using this approach in some type of target-compiled project. It should also be noted that two-byte addresses within a secondary are stored in big-endian format, which is the opposite of the 6502's native little-endianness. Here's a hopefully improved partial inner interpreter implementation

Instead of making a 128/128 split, you could also start out with 256 single-byte codes. As the table gets full, the last entry is set to point to a secondary dispatcher using a new table.

This all-token model makes more sense for an unexpanded VIC-20 (5K) than a maxed-out PET (32K) which neatly divides the RAM from the ROM + I/O at the 32K boundary.

Including the Assembler and a bunch of other stuff that won't be in the final edition, PETTIL has about 600 words in it right now (approximately 5 screens, 5 columns, 25 lines per screen). Even a minimalist Forth plus any application code would push a 256 token limit. It's pretty easy to add a token that treats the following two bytes as an address.

One could even use the BRK instruction as a way to toggle back and forth (get it?) between separate 8-bit and 16-bit NEXT routines, e.g. token1 token2 token3 00 addr1 addr2 00 token1 ...

Heck, make the "long token" signifier $00 and you can just short-circuit the dispatch routine with a BEQ when it's loaded from memory. (Or, if you're doing the 128/128 split, a BMI - depends on whether you want your long tokens to be two bytes or three, I suppose.)

If "long tokens" are more rarely executed than short tokens, it makes sense to keep the fast path fast, and not have extra checks whether or not to branch out. Nested dispatches keep the outer dispatch as lean as possible.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Yes, that's exactly what I was thinking. Most likely the first 250 or so tokens are executed much more frequently than the rest. They are also likely smaller so the relative gain of a few cycles matters more.

Part 3 of the series is up...