[Coco] CocoSDC disk format

[Bob Devries]

Hi Gene,

I will repeat: I am not using HDBDOS.

I am using the CocoSDC ROM that's built into the CocoSDC. It treats the 
disk as a single-sided floppy, and hence (as with all Coco OS-9 
single-sided boot disks), when I type DOS, it seeks to track 35 sector 
1, which is sector offset $0264 of the disk.

The offset into the HDBDOS ROM is meaningless with respect to the 
CocoSDC ROM. A value of $DF3A62 is way out of bounds for the disk image.

Regards, Bob Devries
Dalby, QLD, Australia

On 1/12/2014 12:42 PM, Gene Heskett wrote:
> On Sunday 30 November 2014 15:28:47 Bob Devries did opine
> And Gene did reply:
>> 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.
>
> That might be the problem because that is likely NOT the LSN address that
> is in the $D939-3A-3B (I think thats the right address but dbl-check the
> hdbdos docs on that, and write an rsbasic script that pokes those
> addresses with $00, $02,$64 and see if it at least tries to boot.
>
> Also, take ded to that disk and check to see if the sector address for
> os9boot and its size are properly stored in  DD.BT and DD.Bsz.
>
> Gotta be a disconnect there someplace Bob.
>>
>>> 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
>
>
> Cheers, Gene Heskett
>