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.
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.
Also, rename "Addressed devices" to "Indirect memory access".
I do this because I need to add indirect versions of !, @ and ,
to allow boostrapping directly to EEPROM and that A,, thing I've
added to assemblers felt like really bad names.
With this change, I'd like to generalize the use of the * suffix
for aliases.
The '2' key on my PS/2 keyoard never worked on Collapse OS, I
wasn't sure why. I thought the keyboard was broken, but then I
tried another one, still broken. But it's only the '2'!
The KC sent is 0x1f. Is it a timing problem with the ATtiny? I
have yet to wire my prototype for logic probing. Meanwhile, let's
apply a band-aid.
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.
