[Coco] OS-9 loading NEW WAY

[Gene Heskett]

On Wednesday 22 April 2015 16:00:29 Bill Pierce via Coco wrote:
> Are any of the system modules 'expected' to be at any address in
> particular? I guess what I'm getting at is, if rel/boot are removed,
> everything moves down a notch in memory, so is there anything that
> would affect (address wize)? If after the boottrack loads and
> initiates the system, why can't they (rel/boot) just be forgotten
> (overwritten)?
>
> If rel copies the entire boottrack from $2600 to $ED00 (according to
> the manual), then why not have rel only copy krn to it's new location.
> Then krn, which calls boot, would have to call boot from it's original
> position in the $2600-$3800 area. Once boot is done with loading
> OS9Boot and setting up it's pointers, it returns to krn and at that
> point, rel & boot could be forgotten.
>
> I know it's not as simple as that, and calls would have to be shifted
> and modified, but releasing just those 2 modules would return almost 3
> 256-byte pages to system ram.
>
> Then if krn & krnp2 could be combined (as Gene suggested), I would
> imaging that would compact things a little more. The problem here is
> that krn is called before boot which loads OS9Boot, so krn has to
> already be in place for boot to use to allocate memory for OS9Boot.
> hmmmmm....
>
Whatever loads the os9boot should be smart enough so that if the bootfile 
started with krn, it goes into a smarter copy outine, copying just krn 
to the fixed hiram place it is now.  I had forgotten that there are 
circa $0C bytes beyond the official end of krn that become the IRQ 
tables at $FFE0?  Or something like that.  These bytes are relatively 
easily inspected as they will be output as "kernaltail" if as directory 
entry pointing at the boot track is created with my krnl2dir utility, 
and a session of vfy -sk is run against it, splitting out the 6 byte 
RSDOS header as "kernalhead" , the 3 modules in the boot track, and the 
IRQ table appended to the rest of it as "kernaltail"to bring it to 
exactly a track full.  The miss-spelling of kernel to kernal was 
intentional at the time I wrote vfy, but the reason escapes me now.

> Or, write a new krnp2 that includes the parts of krn that are needed
> for normal system use (after booting), and leave the old krn in the
> $2600/$3800 area. Then rel becomes obsolete (no files to relocate),
> krn execs, calls boot, boot loads OS9Boot, sets the ponters, and jumps
> to krnp2. The whole boottrack is then eliminated from system ram. That
> releases quite a few pages of system ram.
>
> Again, I know it's not that simple, but is as simple as I can explain
> it (if that makes any sense).
>
> It all reminds me of the way L2 uses SysGo as opposed to L1. In L1, it
> resides in the bootfile and remains in memory (why?),

ISTR I made it a loadable module that was discarded on several of my 
later level 1 installs.  The trick was in the init module IIRC by giving 
it a full path to ccgo or whatever it was named then.  But hey, that was 
circa 1988 so that name is gone in 2015, 27 years later.

> in L2, it's 
> loaded, then discarded when it's done it's job. Rel & boot are
> one-trick-ponies and should be treated this way as well. I've always
> wondered why Microware did it the way it was done.

Agreed.

> I haven't looked at the src to Cocoboot, so it may be doing something
> similar already.
>
>
> 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-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
>
>
>
>
> -----Original Message-----
> From: Gene Heskett <gheskett at wdtv.com>
> To: coco <coco at maltedmedia.com>
> Sent: Wed, Apr 22, 2015 2:24 pm
> Subject: Re: [Coco] OS-9 loading NEW WAY

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>