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.
Because that mode behaves exactly like in a regular TMS9918, a new
driver for TMS9918 has been added in blkfs and SMS' VDP now uses it.
Also, fix broken 5x7 font.
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.
On the real machine, I ended up at some point getting a weird "bottom
mirroring" issue. It turns out that it was because when I revamped my
VDP flags in an earlier commit, I hadn't read the whole technical
notes about register $02 and falsely thought that B0 was ignored. No
it's not. When set, it mirrors the bottom 8 rows.
This allows us (in the following commit), to stop unvariably
spitting 64 chars by line in LIST. This way, short lines don't use
3 rows per line (the line number uses 3 chars, which brings us to
67 chars per line).
If we don't do that, we end up with the old contents of the line
being kept at the right of the printed line.
Add _TRA!, _THA!, _TRB!, _THB! routines to easily handle those pins'
value without stepping on other pins like the drivers previously
did. For SDC driver, it's going to be important soon because it turns
out that I can't get away with "always on" CS, so I'll need a scheme
where it's important that TH/TR pins have stable values.
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.
