[Coco] Where are the separate bootfiles?

[Paul T. Barton]

--- Gene Heskett <gene.heskett at verizon.net>
wrote:
--snipped--
> Paul;  If I understand you, and even though the
> pieces are there on 
> disk2's image to make a new kernel track, I get
> the impression you 
> want the kernel track from disk1, right?
> 
> I have published a utility called kernel2dir if
> I recall the name 
> correctly.  Maybe krnl2dir?
> 
> It will build a directory entry that points to
> the kernel track, which 
> in turn will allow that track to be copied to
> another disk, but as a 
> normal file.  Or one can cd to an empty
> directory and use "vfy -sk 
> path2file" to split it up into its 5 component
> parts, which are:
> 
> 1: The 6 byte header required by rsdos when it
> loads and execs a 
> binary file
> 
> 2: rel, the util that copies the kernel track
> to its proper location 
> in memory, and which once done, jumps (IIRC) to
> the boot module to 
> load the os9boot file.  If my IIRC is wrong,
> and it jumps first to 
> os9p1, then once os9p1 has set things up it
> returns to rel or jumps 
> to boot.
> 
> 3: the boot module, which interrogates LSN0 of
> the designated disk to 
> get the location and length of the os9boot file
> and loads it.
> 
> 4: os9p1, now kernelp1, which sets up a
> boatload of variables and 
> jumps to os9p2(kernelp2 now) which completes
> the system init, 
> including a search for os9p3, a seperate module
> that looks up any 
> error numbers in the errno file on the disk.
> 
> 5: a table of jump addresses that lives past
> the end of kernelp1, and 
> which normally occupy the top few bytes of
> system memory.  These are 
> the addresses the hardware jumps to when one of
> the hardware 
> interrupts or SWI's is executed among other
> things.
> 
> vfy works that way as it looks for the 87cd
> header of a module, and 
> gets the module size from that modules header. 
> If it hasn't 
> triggered an 87cd as it reads the files first
> integer, then it puts 
> that into a kernelhead file, ditto for the next
> 2 integers.  On the 
> next read it finds rel's 87cd and starts to
> write that module out.  
> This continues until it has reached the end of
> os9p1.  But it has not 
> reached the end of the file at that point so it
> writes the remaining 
> few bytes as a file called kerneltail.
> 
> To rebuild a kernel track for the new os9gen to
> use, all 5 of these 
> files must be merged back into one 4608 byte
> long kernel track in the 
> proper order.  Its the boot module that gets
> patched to control which 
> device the booting is actually done from.  This
> is required because 
> there is not, at that point in the bootup,
> knowledge of a valid 
> filesystem, so its all by absolute addresses
> direct to the disk 
> controller chip.
> 
> I found this krnl2dir to be a very handy tool
> many years ago when 
> nitro9 was going through its genesis.
> 
> Does this explain it adequately?
> 
> -- 
> Cheers, Gene
--snipped--
 No, I already know some of this,
but I appreciate the really detailed
information, Thanks. It gave me more info
about the track-34 setup. I need explanations
as detailed as this. Again, thanks.

I guess I was being lazy and just asking for
the "kernelp1" file so that I can put
it directly into my coco3.rom source.
Then I can make another boot-rom to boot
directly into nitros9 without floppies
(to my IDE drives). Sorry I didn't elaborate.

Paul T Barton (so you can tell which Paul)


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/