... 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.
The buffer's implementation wasn't buying us much in exchange for its
complexity. A modern machine was still too fast for it (copy/pasting
text from a modern machine would send bytes too fast for the RC2014)
and in the (theoretical so far) case of COS-to-COS communication, the
buffer didn't help in cases where the baud rate was faster than the
processing of each byte received (for example, if the byte was written
directly to EEPROM).
I'm scrapping it and, instead, use the RTS flag to signal the other
side when we're ready to receive a new byte.
Also, implement driver for channel B in SIO. I will need it to talk
to my TRS-80 4P.
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.
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.
