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...
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.
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.
By default, it changes nothing, but it allows interesting
setups, such as using AT28! for directly uploading to EEPROM.
I've also updated the EEPROM recipe to upload directly to 0x2000.
I'm not sure what has changed, but it's working fine now.
So far, I hadn't managed to run those tools properly on OpenBSD. I
was too confused by its stty peculiarities. I'm still confused, but
at least I managed to make them work... most of the time...
By uploading a BASIC loop and then run it, we can reduce the serial
communication to pure content which greatly reduces the overhead and make
the process much much faster.
