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

[Bill Pierce]

Bret, this sounds pretty good. I think it would be a nice change. I just don't have the knowledge of the system module's flow or I'd give you a hand.
 

Bill Pierce
"Today is a good day... I woke up" - Ritchie Havens
 

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com


 
 
-----Original Message-----
From: Brett Gordon <beretta42 at gmail.com>
To: CoCoList for Color Computer Enthusiasts <Coco at maltedmedia.com>
Sent: Tue, Oct 28, 2014 10:25 pm
Subject: [Coco] Request for Discussion new level 2 Nitros9 booting.


Ladies and Gentlemen,

I need help from the more experienced contributers and "old timers" of
the Nitros9 community.  I'm trying to iron out some proposed changes
to my new way of booting Nitros9 Level 2.   I believe I have
modernized the CoCo's Boot process to make it more dynamic and save a
smidgen of system memory.  My way of booting is one step of separating
the booting of Nitros9 from the main Nitros9 runtime.  To the
uninitiated here is a simplified synopsis of current Nitros disk
booting:

- DECB's DOS command loads the boot track from disk
- the boot track contains:  REL BOOT and KRN modules.
- REL setup up some system state and moves BOOT and KRN up to high memory
- REL calls KRN.
- KRN sets up some more system state and call BOOT
- BOOT loads the OS9Boot file from the actual RBF filesystem into high memory
- BOOT returns control back to KRN
- and KRN finishes up system initialization and continues to call INIT.

There is some drawbacks to this bootstrap sequence:
1. BOOT is left in memory and it's space is never reclaimed.
2. ALL three modules (BOOT,KRN,and REL) do some setup. They are
tightly coupled, and near inseparable as implemented.
3. Because of the limited space of the boot-track (4608 bytes) BOOT is
limited to 768 bytes of static code, which limits dynamics (AKA
loading from anything but drive 0 is possible but difficult)
4. Separate BOOT source files have to be maintained for each hardware
device (IDE,SCSI,DW, etc...), and likewise, only one OS9Boot file can
exists on any particular RBF partition (..err... drive).  Ideally the
runtime device drivers would be used to do this, but because of the
limited size of the boot-track, Nitros9 keeps a seperate source files
just for the boot devices. There is none to little code reuse between
BOOT device's and nitros9's runtime devices.
5. The idea of a boot track is a DECB fiction.  Should DECB dictate
how we boot a total different system?
6. The RBF filesystem make no official allowance for the existence of
a boot track.   The two main boot files, the Boot track and OS9Boot,
are not regular RBF files.  Boot track must be in a certain place, and
OS9Boot must be linked into the RBF super-block (LSN0).  This is
illogical, un-beautifull, and NOT simple.

I have read many times on this mailing list, people having trouble
understanding this process. It seems to be a lengthy process of
rebuilding Nitros9 to change anything, let alone changing OS9Boot.


My proposed changes to Nitros9:

1. Creating a chain-loader.   A chain loader is a booter that loads
another OS, then goes away.  The OS, in this case Nitros9, barely
knows this chain-loader exists.  The loaded OS, doesn't load itself -
it depends on chain loader to do this.  In short, we need a LILO or a
GRUB for the CoCo.  ( sorry windows people, these are PC boot loaders
associated with Linux, but it's the closest fitting example I know
of).  My implementation of one such chain loader is my CoCoBoot
project.

2. Modify, simplify, Nitros9:
     a.  There is no BOOT or REL, this is the chain booter's job now.
     b.  Nitros9 can assume OS9Boot is already in-place.
     c.  Nitros9 receives parameters from the booter in a pre-defined
way.  Mr. Pitre  referred to this as a software "contract" between the
booter and the OS.


I have made a rough, parallel hack of the current Nitros9 ver 3.3.0 to
demonstrate proof-of-concept. it:

- Creates a separate distinct KRN module on the RBF called "CCBKRN".
This replaces KRN as found in the current boot-track boot method.
This new KRN module has been modified just enough to NOT load OS9BOOT,
but take single parameter from the booter as to the location of the
start of the preloaded "OS9BOOT" file.  There a few minor
modifications (a bug fix, automatic padding, LWASM compatibility )

Questions remain:

1. F$BOOT no longer "fits" logically.  What do we do when we press the
reset button? We used to cause a *near* clean reboot of the system.
but not anymore?
2. Where to put the new "CCBKRN" module on the RBF filesystem?  I have
put it in the root directory, but it could potentially be placed
anywhere.  My booter, CoCoBoot can navigate the RBF filesystem, but
realistically, the more directories down, the slower booting this way
will become.
3. What should the contract be between the booter and Nitros9 ?!?!

I'm hoping to get this added to the standard Nitros9 branch, and I
have faith this this in no way defeats the old way of booting.   If
you want to boot Nitros9 the old way, it will still work.  The only
drawback would be the parallel maintenance of two KRNs and their
related system calls (F$NPROC and F$RQSYSMEM change slighty)

There's great potential in this:  Having multiple OS9Boot files per
RBF filesystem. Saving some system memory (no BOOT or REL).  We could
even eliminate the idea of a OS9Boot file.  The booter could load each
module one-at-a-time.

I'll do some work to create a workable trial system, most likely a
DriveWire image. and post some Nitros9 patch files on my site soon:

https://sites.google.com/site/cocoboot2/home

Please let me know what you think!  Boisy and I have had a few
discussions on this ( the whole thing was his idea, as far as I know).
Please seriously consider, my changes.  Its time we leave the old ways
behind, and head into the software future!


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

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco