The forum version of the source for that developing language implementation went into the same void where links to abandoned online image storage accounts go, and the laptop that it was most recently been moved onto proceeded to die.
However, I've restarted the project. Spurred by the tease of the CX16 GS prototype, I have simplified my target for the initial system, so that the reboot has gone faster -- in part because of experience in the original boot, but also because it did not have so far to travel.
The current development plan is:
- xForth02, to have a 64KB memory map 65C02 version for the CX16, and also a closely aligned version NMOS6502 version for the C64.
- xForth16, a 64KB memory bank 65816 version for the CX16, and
- xForth1, a "Native Bank 1" 65816 version to provide close to a 64KB dictionary in Native Bank 1, plus support scaffolding and infrastructure in the 64KB address space
- And maybe, if the spirit so moves me, an xForthH "Harvard" memory model Forth, with codespace in Native Bank 1 and dataspace in Native Bank 2.
But I've dropped that for the simplicity of mingled headers. It turns out, the implementation of executable Modules to execute from the HighRAM window is much easier to work out when the headers for the Modules are mixed in with the compiled (and/or assembled) code.
It's still a "two ring circus", with both BLOCKs and Modules using High RAM ... but since the classic Forth BLOCKs were designed to hold raw sectors from drives, with a tried and tested system of working in 1KB BLOCK Buffers, there is no interference between the two, because the access to the High RAM segments containing BLOCKs only occurs while executing the Forth word "BLOCK", and that use is already designed to stack the current High RAM segment before putting the desired one in place, and restoring it when finished. Indeed ... it has to be designed that way, because BLOCKs can hold source code, which can in turn contain calls to BLOCK.
So High RAM Modules and Blocks won't interfere with each other. I am only working on the Block system up front, but I've sketched out the Module system semantics elsewhere.
Anyway, I plunged back into sorting out my Forth inner interpreter, porting Brad Rodriguez's Camel Forth for the z80 primitives to 65C02 assembly, porting his Header macros into plain ACME pseudo-ops, and working through the small (but critical) adjustments between his Z80 inner interpreter and my 65C02 inner interpreter. I've made it through the process of using ACME as a spell checker until the source assembled, and am now grinding through the process of debugging in monitor to find the actual bugs preventing it from coming up ... the inner interpreter is working, the compiled code entry routine is working, and shortly the start up display should be working, and, fingers crossed, in another couple of days (or weeks, or months), I'll have the outer interpreter up and running so I will be able to test individual primitives on the command line, dramatically speeding up the debugging process.
This is part of my evening relaxation process in the Semester on those evenings where relaxation is an option, and the Semester is coming to an end. It's up in the air whether I will be finding time to work on it during the summer, but even if not, hopefully progress will be able to continue in the Fall ... so I wanted to lay a marker down that work on xForth has begin anew.