This allows a COS shell to remotely control another shell from a
serial line. It's very crude now, but the plan is to add tools much
like the POSIX tools, but for COS.
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$.
In the beginning of Collapse OS' Forth version, the readline sub-
system was optional. This is why we had this separate RDLN$ routine
and that the input buffer was allocated at boot time.
It's been a while since the RDLN system has been made mandatory, but
we still paid the complexity tax of this separation. Not anymore.
It's been a long while since I visited this part of the code and it
has become a bit messy after having gone through all evolutions of
the core code.
It is now simpler, more compact.
Previously, these words would be ascii emitters, but seldom used
except for the SPC emitter. However, I would often end up hardcoding
these constants. With useless emitters removed and ASCII constants
added, we have a more usable system.
Also, fix broken test harness.
Also, remove extraneous uses of it. In the rdln routine, we would
spit a new line after each line input, but that NL was spurious:
we already spit the newline we receive as it is typed.
The textual introduction of blk 0 was there when documentation was
inside the blkfs. Now that it's outside it, it serves no purpose:
you're expected to have read the documentation already before seeing
blk 0.
... 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.
In emulation, emitting is near-immediate. On a real machine, it's
often not-so-near-immediate. These little things help usability.
Again, this commit was meta-developed!
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!
On a TRS-80 4P, spitting control chars, in addition to being
visually distasteful, generated a bug where the blinking cursor
would disappear, making using VE much, much harder.
I had a hard time reproducing the bug: you don't trigger it by
simply spitting control chars, it had to be a specific number of
them in a specific order. I didn't identify the sequence, but I
know that "bufp" triggered it.
This commit was written on a TRS-80 4P and downloaded from my work
floppies!
So far, I've been using this tool on remotes that had no control
character handling, but it doesn't work on a TRS-80 4P remote.
Much slower, but at least it works.
Later, I'll try to put some order in this so that we use the fast
lane when possible.
This optimisation appears to make the upload process unreliable in
some cases. I can't appear to reliably upload to my TRS-80 with this
version. I prefer reliability than speed...
A ~C! override can, if it wants, go put an error code in there,
which ~AT28 does.
This way, after a copy or xcomp process directly to EEPROM, one
can verify whether all bytes were successfully written by checking
whether "~C!ERR C@" is zero.
Also, turn AT28! and AT28, into ~AT28, pluggable into ~C!.
~AT28 doesn't check for mismatches. It was too complicated to turn
a mismatch into a compiled word we would jump to next. Data
integrity has to be checked through another path.
Also, remove MOVEW. Without indirect memory access, this word
doesn't make sense. Some AVR-specific words will have to be
defined.
I got bitten again, I've over-designed my solution. The last time
it happened, it was that memory mapping thing I was wanting to add.
The indirect memory access feature I was adding was to solve a
specific problem: Allow Collapse OS to cross-compile directly on a
AT28 EEPROM.
It began well. As long as we were staying in the assembler realm,
things were looking good. However, when we got into the xcomp realm
(B260), things became ugly, and I had to creep up indirection where
I didn't want to.
All of this because I wanted to solve my initial problem in a
slightly more generalized way. The broad idea was that these indirect
memory access could allow xcomp into a broad kind of memory-like
devices.
This idea broke on the "@" part of the equation. If I want
indirections to be two-way and allow xcomp to work properly, I have
to add this indirection to FIND (and possibly others) and this just
isn't practical or elegant.
So, I'm taking a step back and accepting that the solution I design
for now is exclusively for the AT28. What I'm thinking is to add a
low-level hook for memory writing, at the assembly level.
