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

[Bill Nobel]

You know, looking at this closer, it seems to be a request for a version of level 3 nitros9.  I am currently disassembling Aaron’s last known code so it will be a little time before I get a feasible compile.  Still matching the defs. to code.

Bill Nobel

> On Oct 28, 2014, at 8:24 PM, Brett Gordon <beretta42 at gmail.com> wrote:
> 
> 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
>