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 word, suitable to plug to A, , increases HERE before doing its
verification to minimize waiting time: While we increase HERE, the
AT28 has the time to do its programming, and thus we'll need to idle
for less time afterwards.
Also, made the mismatch check silently ignore MSB. Previously, writing
a value larger than 0xff with AT28! would always result in a mismatch.
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.
At-XY+EMIT is slow compared to direct CELL! usage. It is seen very
clearly on a SMS when VE is doing its initial clrscr (yes, I could
manage to load VE from a SD card and run it on a real SMS!).
The grid protocol wasn't there when I wrote VE initially. I only had
AT-XY. Now that we have a solid protocol to build on, let's do it.
In CURSOR!, I was using a write commande to read from VRAM and the
emulator didn't properly behave and did as if everything was fine.
The result on a real SMS was that the cursor would contain the
inverted glyph of the contents of the *old* cursor position.
I do this by adding an inverted version of all glyphs in the upper
range of the pattern memory. This is a big waste of the pattern
space (only one inverted character is needed at once), but it's the
simplest way to proceed. I'll change this if I ever need more
pattern space.
Also, remove _blank. It was wastefully blanking the whole memory.
Only the name table needs to be blanked on initialization.
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.
Working in "blk/" folder from a modern system is harder than it
should be. Moving blocks around is a bit awkward, grepping is a
bit less convenient than it could be, git blame has troubles
following, etc.
In this commit, we modify blkpack and blkunpack to work with single
text files with blocks being separated by a special markup.
I think this will make the code significantly more convenient to
work into.
