[Coco] CocoSDC disk format

[Gene Heskett]

On Sunday 30 November 2014 03:05:29 Bob Devries did opine
And Gene did reply:
> Hi All,
> 
> I have a question regarding the disk format used by the CocoSDC.
> More correctly, the format used by the NitrOS9 build.
> 
> The format command used in the makefile sets the tracks to 1024, but
> leaves all else alone. Thus, the format is 1024 tracks, 1 side, 18
> sectors per track.
> 
You should be able to make a bootable image using that dmode setting. But 
I am faintly recalling, don't have the wd1773 docs handy, that both the 
track and sector registers in the 1773 are only 8 bits wide, limiting the 
tracks to 255, and sectors at 255.  This would allow something over 16 
decimal megabytes.

But the sdc isn't using a normal floppy sdc.  So that limitation probably 
does not exist. The driver in all likelyhood uses LBA addressing.

> The device descriptors /DD, /SD0 and /SD1 all have tracks set to 255,
> and sides set to 64, with 32 sectors per track. I'm referring here to
> the disk image produced as nos96309l2v030300coco3_cocosdc.dsk

I see, when that image is mounted in drivewire, different settings for 
sd0_cocosdc.dd;

{t2|08}/X0/NITROS9/6809L2/MODULES/RBF:dmode -sd0_cocosdc.dd                   

 nam=SD0 mgr=RBF ddr=rbsuper
 hpn=07 hpa=FF4A drv=00 stp=00 typ=80 dns=00 cyl=007F sid=40
 vfy=01 sct=0020 t0s=0020 ilv=01 sas=10 wpc=00 ofs=0000 rwc=

Which would yield about 66 megs.  But its using rbsuper, with the 
llccoscd.dr co-driver.  I'd think we could learn something from that 
source.  But not much, its pretty simplistic, only 247 bytes assembled.

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.

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

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