[Coco] Where are the separate bootfiles?

[Gene Heskett]

On Saturday 27 December 2003 03:18, Mark Marlette wrote:
>At 05:00 PM 12/26/2003 -0800, you wrote:
>
>Paul,
>
>If I understand this question......
>
>They are in the .dsk image file. The scripts build the kernel track.
>
>????????
>
>The distribution is very well structured.....?????
>
>Regards,
>
>Mark
>
>>Boisy (or whomever),
>>
>>I'm looking to fine the bootfiles (track-34)
>>on the www.nitros9.org site. How do
>>I find those separate files? (path?)
>>Specifically, I want "Kernel".
>>
>>Thanks,
>>Paul
>>
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
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.