I got bitten again, I've over-designed my solution. The last time
it happened, it was that memory mapping thing I was wanting to add.
The indirect memory access feature I was adding was to solve a
specific problem: Allow Collapse OS to cross-compile directly on a
AT28 EEPROM.
It began well. As long as we were staying in the assembler realm,
things were looking good. However, when we got into the xcomp realm
(B260), things became ugly, and I had to creep up indirection where
I didn't want to.
All of this because I wanted to solve my initial problem in a
slightly more generalized way. The broad idea was that these indirect
memory access could allow xcomp into a broad kind of memory-like
devices.
This idea broke on the "@" part of the equation. If I want
indirections to be two-way and allow xcomp to work properly, I have
to add this indirection to FIND (and possibly others) and this just
isn't practical or elegant.
So, I'm taking a step back and accepting that the solution I design
for now is exclusively for the AT28. What I'm thinking is to add a
low-level hook for memory writing, at the assembly level.
Also, rename "Addressed devices" to "Indirect memory access".
I do this because I need to add indirect versions of !, @ and ,
to allow boostrapping directly to EEPROM and that A,, thing I've
added to assemblers felt like really bad names.
With this change, I'd like to generalize the use of the * suffix
for aliases.
This brings us a bit closer to TYPE from Forth 2012. I don't think
I'll add TYPE (sig "addr len") anytime soon because there is few
use cases for it, but having "STYPE" instead of "(print)" feels
cleaner.
Replace the "g" arg (glyph) with "c" (character). The reason why "g"
was used was to save a "0x20 -" operation at all CELL! implementations,
but this came with too big a drawback: it made CELL! hardly usable
outside of the Grid subsystem, mostly because the user of CELL! would
often have to do "0x20 -".
For example, I want the SMS's Pad driver to use CELL! directly instead
of having to do EMIT+XYPOS-messing-around. I would have had to do a
"0x20 -" there.
With the move of CVM's forth to the grid protocol, we've lost the
cursor's visual indication. Now, we have it back.
The challenge now is in implementing it in SMS' text mode. In mode
4, it's easy to mark a cell as inverted, but in text mode, that's
not possible.
In VE on the SMS, the first contents line would always be cleared
because of NEWLN being called when the FBUF would spit its last
char. Inconvenient...
I've added a "graphical" mode to the grid subsystem to inhibit this
behavior in a graphical situation such as in VE.
Also, write a more complete Grid documentation.
Also, rename CLRLN to NEWLN and make it clear that it's only called
on entering a new line. This way, we can set Z offset in there for
the TI-84+ LCD driver.
Rename ROWS to LINES (it's what VE uses). Also, don't use COLS and
LINES as immediates in the Grid subsystem: we expect those words to
be available at runtime.
The '2' key on my PS/2 keyoard never worked on Collapse OS, I
wasn't sure why. I thought the keyboard was broken, but then I
tried another one, still broken. But it's only the '2'!
The KC sent is 0x1f. Is it a timing problem with the ATtiny? I
have yet to wire my prototype for logic probing. Meanwhile, let's
apply a band-aid.
Recipes contain bits and pieces of hardware-related knowledge, but
these bits feel sparse. I've been wanting to consolidate hardware-
related documentation for a while, but always fell at odds with the
recipes organisation.
We don't have recipes anymore, just a /doc/hw section that contains
hardware-related documentation which often translate to precise
instructions to run Collapse OS on a specific machine.
With this new organisation, I hope to end up with a better, more
solid documentation.
This would be useful, for example, to allow the assembler to write
straight to an AT28 EEPROM without going to RAM. This would be a
life saver in machines with tight RAM such as the SMS.
also, verify all 3 first bytes of SPI commands. I'm not sure why
I wasn't doing that, probably because I was getting a lot of AVR
err and thought that only 2 bytes of the cmd were echoed. But now,
with a reliable SPI setup, verifying 3 bytes seems to work.
After many trials and errors in reliably accessing AVR chips through
my SPI relay design, I resigned myself to accepting 125kHz communication
speed with it. I find the complexity of solutions allowing to keep 250kHz
speeds to be excessive.
Adding a delay such as the 20ms one we have in AVR programmer's
initialization routine is tricky without a word like TICKS.
This implementation is highly inaccurate, but more accurate and
reliable than a "ballpark" DO..LOOP...
Also, move doc to doc/asm.txt.
Also, fix the pcat recipe which was broken since the overlay change.
I hadn't noticed it because I didn't have to rebuild the MBR.
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.
The ":" now takes care of scanning for ";". Conceptually, having
";" as an immediate word is slightly simpler than the approach in
this commit, but when bootstrapping is involved, this simpler
approach gets murkier.
Moreover, it got even murkier-er when trying to de-stabilize EXIT,
so here we are.
This duplicated feature existed because of bootstrapping issues
with LIT", but again, with careful threading, we can clean things
up.
We can now have a proper "Collapse OS" prompt :)
When writing the xcomp documentation, I realized that with careful
threading and by accepting a bit of code duplication in the xcomp
toolset, I could de-stabilize a couple of words.
(n) and EXIT are a bit trickier, but I think it can be done. It
would be nice to get rid of stable wordrefs...
