[Coco] CocoSDC disk format

Bob Devries devries.bob at gmail.com
Sun Nov 30 15:28:47 EST 2014



On 1/12/2014 12:34 AM, Gene Heskett wrote:

> If you do make an os9 boot disk using the defaults, I have no clue where
> it would put the boottrack since its being treated as a hard drive. In
> that event, what is the stp doing? Something like our /sh does?  Which if
> set correctly is used as the index into which vdisk hdbdos would access.

Currently the boot track is placed at offset $0264 sectors by the 
NitrOS9 build. This is correct for a single-sided disk. It boots 
correctly. All attempts by me so far to build a new boot track have 
failed. Also a new OS9Boot file appears to be ignored. This part I 
cannot understand.

>
> Does it still put the boottrack starting at sector 612 decimal? ded can
> answer that.

Yes.

>
> I think we have a learning event here folks.  Perhaps format it in 500
> megabyte chunks for nitros9, then a whole series of "hdbdos" partitions?
> Generating a whole series of sdch, sdci etc partitions, each of which
> could have the proper wpc amd ofs settings and using the individual vdisks
> by setting the stp value as we do now?  Interesting possibilities here.
> Like taking the drv number back to zero in sdc1, and setting the offsets
> to start at the end of drive 0. Using the defaults I see above, that would
> put a wpc=3 and an ofs=F800 based on the sdc0 settings giving 0x3F800
> sectors, or 66,584,576 bytes for "partition 0".  That could be expanded
> but not quite to 2 times, as beyond 131 megabytes the cluster size has to
> increment in powers of two because the FAT table can only be 65535 bytes
> maximum.
>
> I need to get mine plugged in and play, but I've spent more than my share
> of time in the basement already this week, trying to make a good level 3
> boot floppy, using broken tools, I have found that os9gen will not replace
> the boottrack, so I am trying to add a -f force option to it.
> Unsuccessfully so far.
>
> But I have an 25th anniversary coming up Tuesday that I have to act like
> I'm interested in.  Unforch, at my age & diabetic condition, and her COPD
> condition, its likely to be just a date on the calendar. :(
>
> The highlight of the day will probably be dinner at the local steak house
> buffet. But early enough we get back in time for Wheel & Jeapardy, can't
> miss those.  :)
>
>   Also trying to get my milling machine setup with good enough jigs on the
> table to make the huge box joint fingers it takes to do Green & Green
> joinery. I've already rounded up some Gabon Ebony, solid black for the
> trim bits, and enough Mahogany for the ends of the chest, but I'll have to
> have about 25 bd/ft of it shipped in for the sides, bottom & lid because
> no one stocks any Mahogany locally.  And I'm going one step farther by
> lining it with aromatic cedar.  Thats the plan at this point anyway.
>
> Its on the cover, and is a feature article in this months Fine WoodWorking
> magazine if anybody wants to see it.
>
>> Now, there no problem with this in normal usage, but when I try to
>> create a new OS9Boot file, and specifically a new boot track, it fails
>> miserably; I cannot boot from the resultant disk image.
>>
>> Is there a technical reason for this apparent discrepancy? If not, can
>> the descriptor and the format command in the build be made the same?
>
> Format, unless told not to by a bit in the descriptor, will query the
> device for its capacity and will arbitrarily calculate all that so as to
> use the whole device, see the docs for superdesc about that. You'd want to
> set that bit in the descriptor with dmode that makes format use the
> descriptor values instead. Fixing that is makefile twiddling so its done
> by default.
>
> And once you have done that, SAVE those descriptors with a unique name and
> modify your bootlist to use those rather than the repo's versions. When
> doing custom devices, its best to have continuity when making a new boot
> disk.
>> Regards, Bob Devries
>> Dalby, QLD, Australia
>
>
> Cheers, Gene Heskett
>

Regards, Bob Devries
Dalby, QLD, Australia


More information about the Coco mailing list