[Coco] CocoSDC booting OS9

[Bill Pierce]

Bob, I think (but not sure), the whole basis of these "big disks" with custom NOS9 boots is that if you're booting from HDBDOS and/or DW4 (how else would you use them?), DW4 doesn't know about disk size (and doesn't care), and as long as the kernel is on track 34 when you type DOS, HDBDOS will load it. For that matter, with a little modding, the kernel can be on disk 255 of an RSDOS/OS9 partitioned drive and still boot :-) After that, RSDOS/HDBDOS is no longer in control and the whole process is determined by the "boot" file in the kernel... be it dw4, becker, cocosdc, superide... whatever. The "boot" for that kernel is setup for that bootfile and it "Just Works"(tm)
Ingenious I tell ya... FREAKIN INGENIOUS!

BTW... I was told not to worry about stuff like that... that it was just Majic and not to question it or it would go "poof!".
 

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-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com


 
 
-----Original Message-----
From: Bob Devries <devries.bob at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Mon, Nov 17, 2014 4:02 pm
Subject: [Coco] CocoSDC booting OS9


Hi all,

I don't have my CocoSDC yet.... (soon!)

I was looking through the NitrOS9 repo and found a disk image which can 
be used with it. I was surprised to see that even though it's a ~4.5MB 
disk, it can still boot OS9 without any extra disks.

Now that makes me wonder what the largest size a disk can be and still 
be bootable under the current boot method. The limitation would seem to 
be $0264 sectors for the sector allocation table, since the DOS command 
gets the kernel track from there (34 tracks * 18 sectors = 612 ($0264)).

Perhaps the "DOS" command could be made more intelligent by having it 
check the size of the disk by grabbing the first three bytes from LSN0, 
and then subtracting 18 sectors, and load the kernel track from there, 
thus putting the kernel out of the way of the sector allocation table, 
and thereby allowing for almost any size (hard) disk.

One gotcha would be if the file system used a cluster size of more than 
1, which would make the allocation of the kernel's sectors in the sector 
allocation table a bit more curly.

Chris Burke used a method by which track 128 of the drive was used as 
the kernel track, but IIRC it could be changed. He also had utilities to 
allocate the sectors in the sector allocation table.

My $0.02

Regards, Bob Devries
Dalby, QLD, Australia

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco