[Coco] CocoSDC booting OS9

[Bob Devries]

Unlike Nick, I don't dabble in BASIC. I'm exclusively an OS9 user.

Tricking the DOS command into thinking that the disk is a *standard* 
disk limits the size that the disk can be, because the sector allocation 
table starts at sector 1 and continues for 1 byte for every 8 sectors 
until all the disk is accounted for. This means that the disk's size 
*must* have a sector allocation table of less than 612 bytes. This means 
that I would have a relatively small boot disk, which to my mind is a waste.

Regards, Bob Devries
Dalby, QLD, Australia


On 18/11/2014 8:34 AM, Brett Gordon wrote:
> Bob:
>
> BASIC can only access so much drive (much less than OS9).  I think the
> SDC docs explain some of the assumptions SDC DOS makes about Large
> Disks.  The DOS command ALWAYS loads the Boottrack from logical Drive
> 0, Track 34, sectors 1-19.  Once the second stage is loaded (BOOT and
> REL, and those fellows)  the entire disk is available.   Its a minor
> problem very similar to Linux's LILO Bootloader had: BIOS limited the
> kernel file to the first 1024 Cylinders.  But after the kernel was
> loaded really big disks where accessible.   I'm assuming the OS9GEN or
> COBBLER take care of making sure the boottrack is where its supposed
> to be at (and marks those sectors as used in OS9 )
>
> Shameless plug:
> Try my boot-trackless booting:
> http://sites.google.com/site/cocoboot2.  Any Nitros9 compiled from
> source in the last couple weeks supports it.
>
> On Mon, Nov 17, 2014 at 4:53 PM, Bill Pierce via Coco
> <coco at maltedmedia.com> wrote:
>>
>> 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
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>
>
>