Re: [M100] Loading cross platform .CO files

[John Gardner]

Thanks to everyone who contributed to this  -  Amazing what pops up on this
list...  😎🤔

   /br

On Wed, Feb 25, 2026 at 7:50 AM B 9 <hacke...@gmail.com> wrote:

> That sounds fantastic, John! Y’know, I think I heard about TBACK years ago
> but I wasn’t ready to appreciate it at the time. The description does make
> it sound very similar to the problems I’m trying to solve now. Where can I
> find the source code for TBACK? I’d love to see how the magic is done.
>
> One of the “future improvements” on the TBACK wiki page reminds me of
> another question I’ve run into: When (and how) to use CLEAR in the loader.
> I’m guessing there isn’t going to be a clear cut answer that works 100% of
> the time since, if it was obvious, Microsoft would have done it
> automatically whenever we use “RUNM” or “LOADM” instead of giving an error.
>
> Currently my <https://github.com/hackerb9/co2do/>co2do
> <https://github.com/hackerb9/co2do/> program always starts out with:
> CLEAR 10, *X*, where X is the load address (“TOP”) of the .CO file. That
> seems to work for most things, but I’d like it to also handle the cases
> when people have squirreled away code in the little nooks and crannies of
> high-memory. For example, that
> <https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-10-TANDY200/LCDTXT.200>smooth
> scrolling effect
> <https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-10-TANDY200/LCDTXT.200>
> fits in the Tandy 200 ALTLCD buffer between 63574 and 63804, which would
> cause a ?FC Error if I tried to CLEAR it.
>
> I see a few solutions to this:
>
>    1.
>
>    Add code in the BASIC loader similar to what James Yi put in his
>    smooth scroller that checks the machine’s current MAXRAM and skips CLEAR if
>    TOP > MAXRAM.
>
>     10 IF NOT MAXRAM THEN MAXRAM=62336 : REM For NEC PC-8201
>     20 IF 63574 <= MAXRAM THEN CLEAR 10, 63574
>
>    One problem with this is that the NEC PC-8201/8300 lacks the MAXRAM
>    variable. From scouring the technical reference, it seems to be a fixed
>    value of F380H (62336). (Perhaps of note is that that address is FSIDSV,
>    which is a “poisoned red zone”, to use the ASAN parlance, which causes a
>    cold boot if the data is modified).
>    2.
>
>    Just blithely use CLEAR and trap any error. This should work in both
>    Kyotronic BASIC and N82 BASIC.
>
>     10 ON ERROR GOTO 100
>     20 MAXFILES=0 : CLEAR 10, 63574
>     30 ...
>     40 ?0/0
>     90 END100 'It's a trap!110 IF ERR=5 AND ERL=20 THEN RESUME NEXT ELSE CONT
>
>    My concern with doing this is that it might not be correct or might
>    mask actual errors. Also, it’s a tad verbose when I’m trying to minimize
>    the size of the BASIC loader.
>    3.
>
>    Try to statically guess what the .CO file is intended to do in my
>    co2do script so it generates the right BASIC loader. For example, if the
>    TOP address is 63574, that’s higher than any Model-T’s MAXRAM, so there’s
>    no point in generating BASIC code to check it and optionally run CLEAR. On
>    the other hand, if the TOP address is 60000, that’s lower than any
>    Model-T’s MAXRAM, and once again there’s no need to check: the loader can
>    just go ahead and use CLEAR.
>
>    One issue with this is that there’s no single table out there that
>    lists all the different Model T’s and what their MAXRAM (and MINRAM) values
>    are for different memory sizes. Also, there’s the gray middle area where
>    some addresses might need CLEAR but only on some machines, in which case
>    I’d probably have the script fall back to one of the other solutions,
>    anyway.
>    4.
>
>    Just punt and make it the user’s problem either when they run the
>    co2do script or the BASIC loader. While I dislike programs that add any
>    cognitive burden, sometimes it’s necessary. Microsoft certainly seemed to
>    think that this was one of those times, as they chose to make RUNM “
>    FOO.CO” die in flames with ?FC error if the space hadn’t been
>    pre-CLEARed. (I admit that I don’t understand why they did it that way.
>    Does anybody know?)
>
> —b9
>
> On Tue, Feb 24, 2026 at 8:17 PM John R. Hogerhuis <jho...@pobox.com>
> wrote:
>
>>
>>
>> On Tue, Feb 24, 2026 at 5:20 PM B 9 <hacke...@gmail.com> wrote:
>>
>>> For instance, instead of having a large BASIC program in memory with the
>>> entire .CO file encoded in it, perhaps it could be two stages, with the
>>> first being a minimal program that receives the .CO file over the serial
>>> port and POKEs it directly into the correct location. Essentially, what I
>>> want is for RUNM "COM:98N1" to actually work, with the one addition
>>> that it would call CLEAR first based on the .CO header.
>>>
>>>>
>>>>
>> Yes, this would work.
>>
>> I do something similar in TBACK, it can actually backup/restore the
>> entire RAM of the Model 100 in short order.
>>
>> I don't think I wrote a CO injector for it yet, but that was the
>> intent... to make a universal host side injector / bootstrap/ memory
>> configuration utility.
>>
>> https://bitchin100.com/wiki/index.php?title=TBACK
>>
>> -- John.
>>
>