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.
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.
... 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.
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!
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.
Doing SPI bit-banging through a controller port is already really
slow, but doing so with the Forth version of (spix) was really,
really slow.
With this pure z80 version of (spix), it's more bearable.
I do this by adding an inverted version of all glyphs in the upper
range of the pattern memory. This is a big waste of the pattern
space (only one inverted character is needed at once), but it's the
simplest way to proceed. I'll change this if I ever need more
pattern space.
Also, remove _blank. It was wastefully blanking the whole memory.
Only the name table needs to be blanked on initialization.
Replace the "g" arg (glyph) with "c" (character). The reason why "g"
was used was to save a "0x20 -" operation at all CELL! implementations,
but this came with too big a drawback: it made CELL! hardly usable
outside of the Grid subsystem, mostly because the user of CELL! would
often have to do "0x20 -".
For example, I want the SMS's Pad driver to use CELL! directly instead
of having to do EMIT+XYPOS-messing-around. I would have had to do a
"0x20 -" there.
In VE on the SMS, the first contents line would always be cleared
because of NEWLN being called when the FBUF would spit its last
char. Inconvenient...
I've added a "graphical" mode to the grid subsystem to inhibit this
behavior in a graphical situation such as in VE.
Also, write a more complete Grid documentation.
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.
Because that mode behaves exactly like in a regular TMS9918, a new
driver for TMS9918 has been added in blkfs and SMS' VDP now uses it.
Also, fix broken 5x7 font.
Also, rename CLRLN to NEWLN and make it clear that it's only called
on entering a new line. This way, we can set Z offset in there for
the TI-84+ LCD driver.
Rename ROWS to LINES (it's what VE uses). Also, don't use COLS and
LINES as immediates in the Grid subsystem: we expect those words to
be available at runtime.
On the real machine, I ended up at some point getting a weird "bottom
mirroring" issue. It turns out that it was because when I revamped my
VDP flags in an earlier commit, I hadn't read the whole technical
notes about register $02 and falsely thought that B0 was ignored. No
it's not. When set, it mirrors the bottom 8 rows.
This allows us (in the following commit), to stop unvariably
spitting 64 chars by line in LIST. This way, short lines don't use
3 rows per line (the line number uses 3 chars, which brings us to
67 chars per line).
If we don't do that, we end up with the old contents of the line
being kept at the right of the printed line.
Add _TRA!, _THA!, _TRB!, _THB! routines to easily handle those pins'
value without stepping on other pins like the drivers previously
did. For SDC driver, it's going to be important soon because it turns
out that I can't get away with "always on" CS, so I'll need a scheme
where it's important that TH/TR pins have stable values.
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.
