Part 1 talks about the appeal of the VIC-20 and what a squeeze it will be to fit Forth into it's meagre RAM.
In Part 2 I discussed choices for the inner interpreter and found out that a token Forth model could be both compact and about as fast as DTC.
Now I'm going to allocate the various parts of the Forth system to VIC-20 memory to make the best of what's there. Some of it will be fairly conventional and some somewhat unorthodox.
(An Aside, The Slow uxForth Development Process)
From the presentation of the blog entries it looks like I'm working these things out as I'm going along. For example, it's worthwhile asking why it looks like I can leap to fairly concrete decisions about the inner interpreter or even that I think I'll be able to fit the entire system into the available space.
The simple answer is that I've already done much of the work to make this possible. I've already written the code that implements the primitives (in fact I've written, modified and rewritten it a few times as I've improved it). I've made use of the wonderful resources at 6502 org, particularly the idea of splitting the instruction pointer (called gIp in my implementation) into a page offset and using the Y register to hold the byte offset: it really does improve the performance of the core Next function.
Similarly, I've written the non-primitive code and accounted for the space. It's written in Forth with a home-brew meta-forth compiler written in 'C'. So, there will be a future blog on that too!
However, it's not a cheat as such. The code is not tested yet; nor even loaded into a real VIC-20 nor emulator (I don't have a real VIC-20 :-( ). I have real decisions to make as the blog continues, which means I can make real mistakes too and have to correct them. What I've done, really, is basically a feasibility study, so that you don't waste your time reading the blog. And of course, the whole of uxForth will be released publicly, on a GPL licence via my GitHub account.
Admittedly, it's being released slowly, a 2.75Kb program I hope to release over the course of 2017!
Admittedly, it's being released slowly, a 2.75Kb program I hope to release over the course of 2017!
The Memory Map
Page 0
Page 0 is the gold dust of every 6502 system: versatile and in short supply. BASIC uses the first 0x90 bytes and the KERNAL uses the rest. We'll use all 0x90 bytes for the data stack and some key system variables:
| Addr | Size | Name | Comment |
|---|---|---|---|
| $00 | 2 | gIp | Instruction pointer, lower byte always 0. |
| $02 | 1 | gTmpLo | Temporary byte |
| $03 | 1 | gTmpHi | Temporary byte used for indirect access. |
| $04 | 2 | gILimit | The limit for the inner-most do.. loop. uxForth (and FIGnition Forth) differ from most Forths in that the inner most loops values, the limit and the current value are held in global locations. do causes the previous gILimit and gCurrent to be pushed to the stack; thus r is equivalent to j on other forths. |
| $06 | 2 | gICount | The current loop count for the inner-most do.. loop. |
| $08 | 1 | gUpState | The current compilation state. |
| $09 | 1 | gUpBase | The current number base |
| $0a | 2 | gUpDp | The current dictionary pointer. |
| $0c | 2 | gUpLast | A pointer to the header of the most recent dictionary entry compiled |
| $0e | 2 | gUpTib | The pointer to the input buffer (I'm not sure if we need this) |
| $10 | 128 | gDs | The data stack |
| $fb | 2 | gTmpPtr0 | Spare pointer 0 |
| $fd | 2 | gTmpPtr1 | Spare pointer 1 |
Page 1
Page 1 is the return stack as you might expect. Oddly enough, we only get 192b, because the KERNAL uses $100 to $13F.
Page 2
There are 89 bytes available here, because they're used by BASIC. I plan to use them for the byte code vectors which are:
| # | Name | # | Name | # | Name | # | Name |
|---|---|---|---|---|---|---|---|
| $00 | (nop) | $0b | (+loop) | $16 | u/ | $21 | rp! |
| $01 | ;s | $0c | 0< | $17 | @ | $22 | drop |
| $02 | exec | $0d | 0= | $18 | c@ | $23 | dup |
| $03 | (native) | $0e | + | $19 | ! | $24 | over |
| $04 | (lit8) | $0f | neg | $1a | c! | $25 | swap |
| $05 | (lit16) | $10 | and | $1b | r> | $26 | (vardoes) |
| $06 | 0 | $11 | or | $1c | >r | $27 | (constdoes) |
| $07 | (0branch) | $12 | xor | $1d | r | $28 | inkey |
| $08 | (branch) | $13 | >> | $1e | sp@ | $29 | emit |
| $09 | (do) | $14 | << | $1f | sp! | $2a | at |
| $0a | (loop) | $15 | * | $20 | rp@ | $2b |
The codes that are greyed out have no names in the dictionary to save space; the way you'd insert them into code would be with [ nn c, ] sequences.
Page 3 and Page 4
There are a total of 116 bytes free from $2A0 to $313, I'll fill that area with some of the actual native definitions.
The cassette buffer is at $33c to $3fb. We'll be using the cassette for storage so we can't use it for code.
Pages 16 to 31 ish ($1000 to $1dff)
This is the area of RAM reserved for BASIC. It will contain the rest of the Forth system.
The screen RAM ($1e00 to $1ff9)
The end of RAM for an unexpanded VIC-20 is used for the screen. The plan here is to use that area for the editing space. Instead of implementing a line editor (ACCEPT in FIG-forth and early FIGnition Forth), we use key to call the KERNAL editor and allow it to manage the editing of a line including cursor movement. Pressing Return doesn't execute the command line, instead, pressing F1 exits the editor and sets the interpretation point to the current cursor position. The end of the interpretation point is set to the end of the screen and emit is turned off until interpretation gets to the end of the screen. Importantly, pressing return doesn't start interpretation.
In addition, pressing F2 saves the screen bytes onto cassette.
This is how I'll implement storage in a fairly minimal way. By implementing save via F2 I can save a block (actually the 506 screen bytes are roughly half a traditional block), but LOAD is a normal word, so multiple blocks can be loaded (you just add load to the end of the block).
So, this is how you'd do normal editing operations. For normal words you would place the cursor near the end of the screen and edit to the end of the screen; cursor to return to the first character you want to interpret and then press F1. In a sense this is easy, because you can just press Return and then cursor up until you get there. The same method would also work if you wanted to compile a whole screen's worth of code. Load itself would reset the cursor position to [home] and then return to the interpreter, so placing a load at the end of the screen would load the next screen without any recursion. That way you'd be able to develop programs that were longer than just one screen without manual reloading.
This is how I'll implement storage in a fairly minimal way. By implementing save via F2 I can save a block (actually the 506 screen bytes are roughly half a traditional block), but LOAD is a normal word, so multiple blocks can be loaded (you just add load to the end of the block).
So, this is how you'd do normal editing operations. For normal words you would place the cursor near the end of the screen and edit to the end of the screen; cursor to return to the first character you want to interpret and then press F1. In a sense this is easy, because you can just press Return and then cursor up until you get there. The same method would also work if you wanted to compile a whole screen's worth of code. Load itself would reset the cursor position to [home] and then return to the interpreter, so placing a load at the end of the screen would load the next screen without any recursion. That way you'd be able to develop programs that were longer than just one screen without manual reloading.
Conclusion
In the memory allocation of uxForth, we've squirrelled away about 1053 bytes of RAM, embedding the line buffer in the screen and a number of system variables in page 0. We've also included 212 bytes of what we'd use for the program proper. It won't get much better than this!
In the next post I hope to talk in more detail about the implementation of the primitive words and the code used to test them.
