Very very simplistic, but works with our driver.

The idea is to consider assemblers as "runtime" apps instead of
placing them in the "bootstrap" section of the blocks. These apps
will be used for much more than bootstrapping.

Moved its documentation to doc/asm.txt and made its code blocks
more compact.

Working on programming AVR chips exposes a glaring omission in my
first design of the SPI Relay: not allowing multiple devices make
this task hard. I constantly have to unplug my SD card before, plug
the AVR chip holder, then play a bit, then unplug the AVR holder,
then replug the SD card...

My prototype for a SPI relay design is built, but I haven't tested
it yet. I need to adapt the code first, which is what I do here.

When the prototype is tested, I'll update the SDC recipe with a new
schema.

"-ansi" is not supported by tcc, but according to gcc
documentation, "-std=c89" produces identical behavior.

See: https://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Standards.html

Only its jump at 0x33 remains.

I've also fixed a strange offset oddity in 8086's (n) placement.
It was off by 2, but strangely, it ran properly. Anyway, now it's
fixed.

It's more descriptive this way. Also, I'll soon add a new HERESTART
config.

The stage binary is now there.

The C VM now runs the show.

Previously, recipes that began spitting binary contents before
loading block 282 would end up with VARIABLE code in their binary,
thus breaking them. We fix this by making this loading process
2-part.

It helps a bit with staging times.

Was previously referred to by name+find, which was wasteful.

This commit adds ?DUP IF guards to MOVE and MOVE- that make them exit
when u is 0. Without these guards a DO loop was executed 65535 times
instead of 0.

In particular, this fixes a crash when "105 LOAD I " is executed
immediately after boot. Block editor word "I" passes IBUF length (0)
to MOVE- and MOVE in this case, causing a crash.

I always keep it on myself. I can imagine it's especially useful to
newcomers.

We now have a stable ABI that is pretty cleared up...

The only calls still using the stable ABI indirection are those
made before the next routine is created.

Instead of having wordref point to core word routines, I made them
into word 4 word types. It liberates space into the stable ABI and
should make porting to other arches easier.

I'm also thinking of combining word type with the namelen field
for precious bytes saving, but not now...

It was useful when we still had the relinker, but now it has no use.
I was waiting a bit to see if the distinction would be useful again,
but it seems like it won't.

Only 2>R in actually needed in the RSP family (for LOOP). Reducing
the scope of the stable ABI makes porting to other arches easier.

I had more ambitious goals, but I backed out of it: not worth it.
This small optimization is an easy picking though.

Inline it in next and make chkPS, call a newly reserved label for
it directly, removing a layer of indirection. This frees a spot in
the stable ABI.

Otherwise, when editing a file with VE, we would constantly write
to disk, which is a bit inefficient.

It's a quite useful word and it doesn't make sense to reload it from
disk after each usage.

All recipe makesfiles would previously assume a built emul/.

Fixes #113

There wasn't much of a reason to leave a loop early on 0x0d or null.
The idea was that once you have a CR or null, the rest is garbage
and you shouldn't see it.

However, it brought a problem: In VE, you couldn't insert characters
past that limit. It would be written, but never displayed. So let's
get rid of this logic and simply always display a 64x16 grid.

not needed

The address returned in the error condition would be off by one.

I'm not sure why I chose null-terminated initially. Probably because
the z80asm version had null-terminated strings.

Length-prefixes strings are the traditional form of strings in Forth
and it's a bit easier to work with them with traditional forth words
when they're under this form.

I'm planning a string reform and it's standing in the way.

I'm planning on going back to 8-bit branching. 16-bit br cells incur
a non-negligible penalty and, while at first 64 words (128 bytes
forward or backward) seemed a bit limiting, I now don't see why one
would ever construct such a big branch. It would be un-forthy.

Also, I looked at using BC instead of IY to hold IP and the transition
would be a lot easier with 8-bit branching.

In this commit, all I do is add overflow checks in IF. The mechanic
below doesn't change. I'll give myself some time to think it over so
that I avoid yet another back and forth.

Prebiously, when encountering an error during a : ; definition from
input buffer, because the input buffer wasn't flushed, we would continue
interpreting and quit the whole program when encountering ;.

VI, here we come!

Writing directly to forth.bin seems to cause problems in some
environments such as Travis CI.

it was broken in the move to ncurses.