I could drive my RC2014 from my TRS-80 4P (using the Remote Shell
coming in the next commit)! A challenge I faced was that the RC2014
spits characters too fast and the CTS line of its ACIA modules
(both the 6850 and SIO/2 ones) are hard-wired to ground, making
flow control difficult. I solved this, for now, by lowering comm
speed.
This driver improvement makes CL<? faster and makes baud rate
configurable in CL$.
... 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.
Loading the grid subsystem on top of the TRS-80 driver, which is
an interface to its ROM BIOS, would be counter-productive because
the BIOS already has the concept of cursor.
However, VE needs the Grid interface, so we implement a shim for it.
Again, all this work (and the re-assembly that it entails) has been
done from within Collapse OS on the TRS-80!
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.
Virgil Dupras