Commit Graph

9 Commits

Author SHA1 Message Date
Virgil Dupras 2d9a07d215 blkunpack: don't include trailing empty lines
This was becoming heavy to manage.
2020-06-23 06:52:34 -04:00
Virgil Dupras f6ded7712e VE: add 't'
This is the first commit I do entirely in VE. It's a habit I'm planning
on taking as it helps a lot to find usability issues.
2020-06-11 18:12:01 -04:00
Virgil Dupras ed2b91411a Limit ourselves to 8-bit branching
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.
2020-05-24 10:16:25 -04:00
Virgil Dupras bd38d80f9c Move Cross-compiled core from B390 to B350
and renamed it "Core words". Also, reworded the presentation.
2020-05-15 22:44:49 -04:00
Virgil Dupras 3d908cef3a Move all parsing words to Inner core
This allows us to get rid of the (parse*) indirection.
2020-05-02 21:21:47 -04:00
Virgil Dupras 389b23fe1a Change C<? mechanic
It's now a simple flag updated by the C< implementation. No more
routine pointer.

The goal is to avoid tons of "ok" during a LOAD operation.
2020-04-25 09:10:25 -04:00
Virgil Dupras 816563e2e3 Stop LOADing on ABORT
This is done by adding a "C<* override" layer that is reset to 0 on
ABORT.

The problem was that when ABORT happened during a LOAD, we had a
resetted RSP and started from a clean INTERPRET, but LOAD didn't
have the opportunity to restore C<*, which caused it to continue
interpreting from the faulty BLK.

With a C<* override, we don't need to *restore* C<*, we just need to
clear the override.
2020-04-24 14:10:40 -04:00
Virgil Dupras af39b37dd1 Replace the "> " prompt with the more traditional "ok" one
This is more than cosmetic, it's also highly usable. The presence
or absence of the "ok" message allows us to know whether the command
aborted. Previously, the "> " prompt appeared when the system expected
a prompt in the INTERPRET context, whether the previous command aborted
or not.

Also, this allows us to get rid of that ugly FLAGS global variable.
2020-04-24 12:10:07 -04:00
Virgil Dupras 44403c3d4c Move icore to blkfs
The way is clear for complete stage1 bootstrapping on the RC2014
target!
2020-04-23 15:14:14 -04:00