Haven't had a lot of chance to update this over the last week, but work has been ongoing.
I fixed up the scope-walking enough to get the whole Sonic 1 source parsing and assembling. Thankfully it's faster than before, especially considering that it's doing more -- both token stream and AST are being built -- and should speed up much more once the old token stream is removed and the now unnecessary validation in the assembler can be cleaned up.
More shortcomings with the grammar design: The way OZ80 allows you to define RAM needs to be more flexible than I originally envisioned. The purpose of OZ80 is to allow assembly programs to be as flexible as high-level programs, therefore one can imagine that one has a 'library' of code and also possibly that one code base will extend another (ROM hacks). Much like how the Z80 code/data is arranged in the ROM automatically by OZ80, we should allow multiple blocks of RAM to be independently defined and let OZ80 choose the layout. This would allow discreet parts of the codebase to define their own RAM rather than all RAM having to be defined before the code (preventing 'extensions').
We also need to support more than one 'page' of RAM (the main system memory), as there will be pages of RAM that overlap the same address space; SRAM has two banks that can be switched between in the same Slot. We also need to consider VRAM and the Z80 ports ($00-$FF).
To that end I'll be changing OZ80 to work as such:
An instance of an anonymous RAM block will simply define a chunk of RAM to be laid out in the default system memory ($C000-$DFFF on the SMS)
These can be littered throughout the codebase freely and OZ80 will fit them into system memory (
Some kind of statement to define a new page of RAM will be needed:
RAM PAGE $_SRAM1 $8000 16 KB
This will define a new page of RAM with its own address space to be auto-numbered from $8000, for 16 KBs length. Then, when you want to add some variables to the SRAM you plop a named RAM block into your code:
RAM $_SRAM1 [