Looping inside ReadC broke the shell's hook logic. We have to
return immediately when nothing is typed.

Also, make tests run in a *BSD environment

Sure, it's a bit slower, but it prevents a lot of hard to debug
problems. I don't have to want to remember "don't use IX if you
have any blk* calls". Let's optimize I/O later.

A routine to conveniently read lines from TTY. Extracted from
shell. Will be used in other places.

That is, send current chr selection, and then, send LF.

This avoids having "ghost" chr selection sticking around.

This allows for outputting a character selection before it's given
through GetC. That allows a pad-oriented character selection scheme.

Still a bit rough around the edges, but still, works rather well.

This hook is called during every iteration, allowing regular screen
refresh when video is involved.

Make ASCII_BS (sent when driven through kbd) make the same thing as
ASCII_DEL. Also, don't crash on filling the buffer.

We'll make them uppercase when we'll add support for shift.

It previously returned success!

When there's a mismatch, retry up to a certain number of times.

This makes random problem related to assembling big kernels go away! But
it also make SD card reading much slower...

For now, this achieves nothing else than wasting cycles, but this is the
first step in enabling CRC verifications (CMD59).

I think that this is where my random problems with assembling large
kernels from SDC come from: bad data that isn't detected. If that
happens when PGM loads programs in memory, then anything can happen.

`sdct`, when ran often enough, will error out or corrupt away (go
crazy)...

It would always load one byte less than told... This time it's right on
the money :)

Calling `load` would always read one more byte than specified. Also,
make `0` mean `0x100`.

Also, make `0` mean `0x100`.

I don't know why I haven't noticed it wasn't protected. It must have
been behind many random problems I've been having...

That was an interesting bug. It didn't cause a problem in emulation, but
in an RC2014 on an SD card, an include that didn't end with two newlines
would cause an infinite loop.

Needed if we want to compile the kernel and zasm from within a SD card.
I didn't go straight for 32-bit because it was significantly more
complex and 24-bit give us 16M. Enough to go on for a while...

It doesn't sound like much, but that backspace key is often useful...

Previously, an optional word argument would only have its first byte set
to zero.

A new app to stress test the SD card driver. Also, accompanying this
commit, changes solidifying the SD card driver so that stress tests
actually pass :)

By not waiting until the SD card wan't busy any more after a write, we
exposed ourselves to errors if another operation was attempted right
after it.

Also, lay out the plan for adding a second buffer.