[Coco] Request for Discussion new level 2 Nitros9 booting.

[Brett Gordon]

> This should work for Level1 also, I suppose. The boot structure is
> pretty much the same, isn't it?

I *think* this new boot scheme will work with Level 1 and maybe even
Level 3.  From the current Level 3 source and discussion, I'm not sure
there is anything working in Level 3 to test.  Until then, I'll
continue to improve the CoCoBoot2 implementation, and do some testing
with my CoCo2 and XRoar (thanks sixxie!)  for dragons.

> I also think this will be great for other platforms which run NitrOS-9
> or might do in the future. Why should it be called /coco/ boot? As a
> loyal Dragon user I have problems with this ;) You can call it
> brettboot for what I am concerned. Or brub :) Of course the program
> you write for the Coco can have that name, but this new boot system
> and "contract" between NitrOS-9 and the chainloader deserves a better
> name.

If I can get this scheme working for a Dragon and Level 1, I don't see
why we couldn't change the name.  I like "brub".

> The difference between fsrqmem.asm and ccbfsrqmem.asm is so small that
> they can be merged with conditionals. This might wait until it has
> settled a bit, but it will avoid unnecessary double-maintenance or
> divergence in the future (if both systems are kept). The same is maybe
> true for krn.asm/ccbkrn.asm. Some of the changes (e.g. the fill)
> should probably be applied to krn.asm in any case. It would be good if
> you can work on making the difference as small as needed.

Yes, conditionals would help eliminate the parallel parts. I did not
like the idea of breaking the exisiting booting so I kept the new
booting stuff separate until people could review my code


> In ccbfsrqmem.asm you have hardcoded $FF00 as top of memory. I believe
> there should be macro for this, to make it easier to port to systems
> where top of RAM is elsewhere or somebody wants to reserve some memory
> for something.

Indeed.  That was laziness on my part.

> BTW, I have noticed the persistence of REL and BOOT in my level-1
> system. Especially with only 32K RAM a few modules make a large
> difference :) Independent of your solution, wouldn't it be possible to
> make REL and BOOT "disposable"? I can see very little use for direct
> rebooting, if something goes wrong, a full cold boot is likely needed
> anyway.

You are the second person that expressed that opinion about RESET.
I'm inclined just to have ccbkrn just cold boot.  This seems like the
appropriate action until disk caching or "mounting" is implemented,
requiring a safe shutdown of Nitros9.  Then another behavior on RESET
is probably best.



-- 
Brett M. Gordon,
beretta42 at gmail.com