... and rename it to KEY?. Then, add KEY from KEY? for its blocking
version.

I need this for an upcoming Remote Shell feature. If a Collapse OS
system remotely controls another shell, it needs to be able to poll
both the remote system and the local keyboard at the same time. A
blocking KEY is incompatible with this.

In some places, the polling mechanism doesn't make sense, so this
new KEY? always returns a character. In some places, I just haven't
implemented the mechanism yet, so I kept the old blocking code and
added a "always 1" flag as a temporary shim.

I have probably broken something, but in emulators, Collapse OS runs
fine. It's an important reminder of what will be lost with the new
"dogfooding" approach (see recent mailing list message): without
emulators, it's much harder to to sweeping changes like this without
breaking stuff.

It's fine, I don't expect many more of these core changes to the
system. It's nearly feature-complete.

This will facilitate the development of a solution for
cross-compiling directly to EEPROM.

Not complete yet, but has @KEY and @DSP, enough to get prompt.

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.

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.

I'm planning on adding other subfolders. 8086 for example...

Very very simplistic, but works with our driver.

Working on programming AVR chips exposes a glaring omission in my
first design of the SPI Relay: not allowing multiple devices make
this task hard. I constantly have to unplug my SD card before, plug
the AVR chip holder, then play a bit, then unplug the AVR holder,
then replug the SD card...

My prototype for a SPI relay design is built, but I haven't tested
it yet. I need to adapt the code first, which is what I do here.

When the prototype is tested, I'll update the SDC recipe with a new
schema.

I now get to "fls" in recipes/rc2014/sdcard!

so far, it goes through initialization with the rc2014/sdcard recipe.

Why didn't I think of adding it before?

I implement the screen using XCB which is much more friendly
than z80e's SDL+CMake for development machines that want to install
minimal dependencies (for example, a port-less OpenBSD rig).