[Coco] CocoSDC disk format

Sun Nov 30 22:47:56 EST 2014

On Sunday 30 November 2014 21:53:33 Bob Devries did opine
And Gene did reply:
> 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.
> 
Humm, that may be, but the default value in the typ report from dmode is 
$80, aka its a hard drive AND unless the typ is changed to 90, format will 
not query the drive for its size, but will use the descriptors values when 
doing the formatting.  This particular detail I find, did NOT make it into 
the rbf.d file when that stuff was moved.  The default is not to query the 
drive, and setting typ to 90 will enable it. UNK to me if the sdc will 
return sensible data in that event.

FWIW, the default typ byte in my /s1 descriptor, which is another 1Gb 
seagate hawk just like /dd is, ws set to $91, so when I formatted it, it 
formatted the whole drive, and it uses a 16 sector "cluster", where each 
bit in the fat represents 16 sectors.  On a drive that big it likely would 
not care in comparison to how much data is on it.  I dsave /dd to it about 
once a year for backups mainly.  I should setup a cron job and do that 
every week or so and really keep my backups up to date. ;-)

A Cron I hear you say?  Yup, I rewrote one I saw in the rainbow a couple 
decades back, uses about 1% of the cpu the Rainbow version did. Somebody 
that needs it should poke at me & I'll put it on my web page if its not 
already there.

> 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.

Depends, how large is your sdc card?  That would correspond to 
3,745,145,344, bytes which they may call a 4Gb card, but the shortage is 
for spare sector substitution remapping when a sector gets funkity. But 
3,745,145,344 bytes is all it will let _you_ use.
> 
> 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

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS