[Coco] CocoSDC booting OS9

[Brett Gordon]

That sounds like a fine idea!  It's just a matter of changing OS9 and
BASIC to agree to do something different.











On Mon, Nov 17, 2014 at 6:37 PM, Bob Devries <devries.bob at gmail.com> wrote:
> 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
>>
>>
>>
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco



-- 
Brett M. Gordon,
beretta42 at gmail.com