[Coco] CocoSDC: updating OS9Boot

[Gene Heskett]

On Monday 24 November 2014 01:03:20 Bob Devries did opine
And Gene did reply:
> Hi all,
> 
> now that I have partitions working, I want to add the descriptor to the
> boot file.
> 
> I can use Kwikgen to add the descriptor to the OS9Boot file, and if I
> ident it, everything appears to be good. The values of DD.BT and DD.BSZ
> in LSN0 of the boot disk (/sd0) are correct.
> 
> But... it won't boot. I end up with *j at the end of the boot sequence,
> which IIRC, means error 234 - module not found.
> 
> As well, the module I added is not printed on the screen at boot time,
> suggesting that the boot sequence is not reading the new OS9Boot file
> but still reading the old one.

I would have to point a finger at Kwikgen not properly updating DD.BT and 
DD.BSZ then.  Or, more likely, the offset bits in the cocos ram, at 
$D958-59-5A (check that address, thats from pretty ancient wet ram and 
something I have never modified, so while I know about it I won't swear 
its correct) wasn't updated to point at the new version.

My own prefered method is make a directory to hold the contents of the 
bootfile, cd to it, and then "vfy -s /path/to/OS9Boot", which will split 
out the individual modules saving them in this directory.

Then do an "ident -s /path/to/OS9Boot >bootlist.bl"

Then edit this bootlist.bl to remove the extra output from ident, making a 
list of modules that vfy spit out that can be fed back into os9gen.

Put a copy of your new descriptor in this directory, and add its name to 
the bootlist.bl file.  I'm sure you have copies of rel, a boot module for 
your hardware, and a copy of krn which comprize the boottrack, or whats 
there now in that hidden track can be recovered by making a directory 
entry that points at it using something like my krnl_to_dir.b09, which 
will make a visible file out of the boottrack by adding a directory entry 
in the root dir of that device (which will also shut dchecks mewling about 
thse 18 sectors that are in the allocation map but not in the file 
structure. My krnl_to_dir.b09 will use the name KERNAL, miss-spelling 
intentional.

Once that has been done, you run "vfy -sk /path/to/KERNAL" which will 
generate 5 files, a file called KernelHead IIRC, the rel used, the boot 
used, and depending on the age of the track, either os9p1 or krn, followed 
by a last file called KernelTail. Then when running os9gen, merge them 
back into a single file, the mb scripts use bttemp as this files name.

From an mb file to make a ew floppy boot, that merge line looks like this:
merge ../MODULES/BOOTTRACK/rel_80 ../MODULES/BOOTTRACK/boot_1773_6ms 
../MODULES/BOOTTRACK/krn>bttemp

but modify that long line to use the 5 files you just split out of the 
existing boottrack.

Next, as the mb scripts do
os9gen %1 -t=bttemp<../BOOTLISTS/bootlist.bl

where the %1 is the shell variable that contains the devices name, and of 
course fix the ../path/to/bootlist so that is correct.

It's a pita to set it up, but once its done, all you have to do is edit 
the bootlist.bl, adding or subtracting the modules you want in the new 
boot disk, and run the mb script. Simplify's the heck out of making a new 
boot once its setup.

KernelHead is those 6 identifier and exec byte in front of rel, KernalTail 
is the list of vectors that live beyond the end of os9p1 or krn

If targeting the /sh descriptor which will make a new 35trkss image in 
whatever HDBDOS vdisk that the /sh's stp is set to, that will NOT update 
the hard drives LSN0 and it shouldn't but it will update the LSN0 of the 
HDBDOS vdisk.

Then, you can change the three offset bytes I mentioned above to point at 
the new hidden track you just made, or you can run bootlink using the same 
number as /sh's stp is, adding a $ sign in front so bootlink knows its a 
hexidecimal number, which will adjust DD.BT and DD.BSZ in the devices LSN0 
to point at the newly generated OS9Boot file. The old boottrack will be 
used, but the newly generated OS9Boot will be used IF the boot module is a 
boot from this drive module.  At least, boot_tc3 works that way and it 
would be surprising if boot_ide didn't work in the same manner.

Obviously, because stuff has been moved around by Boisy over the last 20 
years, you cannot use a newer krnp2 with the older os9p1, or vice-versa.

> Can anyone suggest what I'm doing wrong?
> Does the CocoSDC work differently? Does it store some information which
> is then not being updated?
> 
> Regards, Bob Devries
> Dalby, QLD, Australia


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>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS