It seems that xcomp can't manage to reliably compile core+ units.
Let's limit the role of xcomp to z80c+icore.
I'm getting a little desperate here. I'll revisit the link.fs approach
with a new idea I had...
Since the fix of its RAM addr, we use the wrong CURRENT in every
usage of IMMEDIATE in icore. We therefore have to manually set the
flag for all 3 immediate words in that unit.
This should help with the bootstrapping of non-emulated environment.
For example, I have a problem with the RC2014: I can't send it
bootstrap info until the ACIA is up. I need to find a way...
All "stop pings" are now explicitly made at appropriate places. This
fixes a problem I've introduced in the last commit where RAM+ was
unexpectedly part of a stable ABI because of "HERE" usage in dummy.fs.
This system will, anyways, soon change because boot.bin and z80c.bin
will be built during the same process (but there's a bit of retooling
to do before I get there).
Doing this was a bit stupid. These offsets are constants. Moreover,
having them in stable ABI had us construct the boot binary from the
stable ABI of the host, making it very difficult to change RAMSTART
for a new system.
There is an alternate git history where I continued the Forth-ification of
words, including "SKIP?", but that was a bad idea: because that word was
written by flow control immediates, I stepped into quicksands where stability
became necessary in z80c.fs and I couldn't gracefully get out of it.
I'm stepping back and take this opportunity to replace the shoddy SKIP? algo
with a more straightforward (?br) implementation.
(br) and (?br) will always stay in boot code where it's easier manage a stable
ABI.
