I wanted to make CVM's forth use the Grid subsystem, but doing so
would break the stage binary. Hence, this split.

Previously, display would be completely broken. We have yet to add
a way to display the "right" part of a buffer on such smaller
displays.

I'm planning on de-hardcoding columns in VE a bit to add support
for screens narrower than 67 columns. There's a lot of hardcoding.

Let's begin with not using core's LIST anymore. This allows us to
spit 1-16 numbers only at startup.

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.

I'm planning on supporting Text Mode soon, and SMS' VDP, when mode
4 is not active, behaves mostly like a regular TMS9918.

By having this behavior in a separate unit, we'll be able to use it
in other systems.

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.

Instead of clearing the rest of the line on a _lf, it's simpler
to just clear any new line we're entering into.

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 goal is to offload the SMS VDP driver a little bit.

it has been removed from the core.

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.

I've noticed that under certain conditions, such as a stack overflow,
I would segfault, something I though was impossible because my memory
size is 0x10000 and all my integer variables are uint16_t.

After having re-read my C handbook, it seems I wasn't sufficiently
knowledgeable about type conversion rules.

It isn't used in there anymore. Moved it to VE, the only place
where it's used.

If a line has a char below 0x20, we consider the line ended, we
stop the EMIT loop for this line and spit our NL.

This makes LIST stop wasting rows in environments with a tight
screen.

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.

I was sampling DO at the wrong moment, so my input was always
one-off.

why did I think that I could read from it?

NetBSD doesn't have ncurses. Linking to curses doesn't seem to change
anything. Tried on OpenBSD and Ubuntu.

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.

Previous instructions would only work with an AT28C64. Now, it also
work with an AT28C256.

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.

Theoretically, it works. I can access an emulated SD card on it.

Will it work on real hardware?

I've also made SMS emulation faster. It was unbearably slow for SDC
access.

My idea of plugging a RC2014 bridge directly onto a Sega Master System
cartridge doesn't work. The SMS eats all I/O addr space, we can't use
it. Therefore, this naive idea, in the emulator, of reusing sdc.c in
sms.c as-is, doesn't work either.

I'll have to find another way of communicating to a SPI device on the
SMS. I'll probably do it through a controller port. Meanwhile, I need
to decouple SPI from SDC in the emulator code so that I can reuse
sdc.c. This is what is done here.

There are many situations where it can be useful. Worth it.

This allows us to remove AMOVE* words.

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.

With KEY and EMIT being switch words, most of the high layer can
be defined before drivers.

In addition to this change, I've compacted core blocks which were
becoming quite sparse.

This allows us to remove one layer of indirection in (wnf). This is
possible now that EMIT is a switch word.

Slightly larger binary, but clearer code and slightly faster.

RAM+ is the host's setup! Use SYSVARS instead, which is the guest's
value.

I'm pretty happy about how lightweight the implementation turns
out to be.

1 whole byte!

I think that when I added NL, I had troubles having access to CRLF's
address at boot time, which is why I had this system. But now that
CRLF is easily accessible during BOOT, we can simplify.

(and that will help us in the hopefully-upcoming change, which is
quite nice...)

They were only used in the ti84 recipe and were not worth their cost.

It works (in emulation, but soon on real hardware!), but the LIST
command is awkward due to tight screen estate...

I'm about to reuse sdc.c in sms.c and the old directory structure
was becoming awkward.