[Coco] OS-9 loading NEW WAY

[Boisy Pitre]

Parts of REL and specifically, BOOT, are kept around in RAM so that when you hit the Reset button on the back of the CoCo, you get back to the “NITROS9 BOOT” screen.

If we wanted to forego having that and just go back to BASIC when hitting the Reset button, REL and BOOT’s memory could be reclaimed.

The last time I saw Brett’s CoCoBoot, it was noticeably slower than the REL/BOOT combo. And I don’t mean that as a criticism to Brett’s great work at all. That’s just the nature of using a Forth interpreter on the CoCo.

I’ve always envisioned a modular boot structure that could incorporate a low level console driver (either CoCo 3 40/80 column, VDG or even serial I/O) and a series of booters for different devices that could fit inside of either the 4608 byte boot track or an 8K ROM.
—
Boisy G. Pitre
CoCo Projects Coordinator
http://www.cloud9tech.com <http://www.cloud9tech.com/>
http://www.nitros9.org <http://www.nitros9.org/>
http://sourceforge.net/projects/drivewireserver/ <http://sourceforge.net/projects/drivewireserver/>
http://sourceforge.net/projects <http://sourceforge.net/projects/drivewireserver/>/toolshed
http://http://liber809.blogspot.com <http://http//liber809.blogspot.com>
http://github.com/boisy/DriveWire-MacServer

> On Apr 22, 2015, at 4:00 PM, Bill Pierce via Coco <coco at maltedmedia.com> 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....
> 
> 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?), 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.
> 
> 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
> 
> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco