[Coco] Mounting CoCoSDC Disk Images in NitrOS-9

[Gene Heskett]

On Sunday 30 November 2014 23:59:28 Joel Ewy did opine
And Gene did reply:
> On 11/30/2014 10:39 PM, tim lindner wrote:
> > On Sun, Nov 30, 2014 at 8:27 PM, Joel Ewy <jcewy at swbell.net> wrote:
> >> What I'm gathering, in catching up with the mail list, is that there
> >> are currently no utilities for mounting the disk image files on the
> >> SD card from within NitrOS-9, is that correct?
> > 
> > I finished sdir today. I'm working on sdrive now.
> > 
> > In the nitro repo: 3rdparty/utils/tlindner.
> 
> Very cool.  I need to hang it up for tonight, anyway, so waiting for
> sdrive makes a convenient excuse.
> 
> >> The sdx device descriptors are for big hard disk-like images using
> >> LBA.  But the 4.5M NitrOS-9 image doesn't need LBA -- it's just
> >> like a giant floppy disk, is that about right?
> > 
> > Correct. But the /sdx descriptors are a bit faster.
> 
> So how do you get the /sdx descriptors to point to a disk image file?
> Using the current stock nos96309l2v030300coco3_cocosdc.dsk the boot
> disk shows up as /d0, "dir /sd0" or "dir /dd" results in error #244,
> and I'm getting #247 errors on a disk image in /d1.  Do I need to
> dmode my /dx descriptors to look like the /sdx?  Am I reading
> "cylinders" and "sides" /d0 and /d1 don't think exist?  Nick M.
> mentioned a manual, but I haven't found any documentation pertaining
> to CoCoSDC and NitrOS-9, but I'm probably looking in the wrong place.
> 
> JCE

Joel;

You might be able to use a trick I have used several times, which is to 
look at the device with ded, and locate the starting sector of the image 
file by tracing from the root directories entry for the image, s to that 
FD, get the address of the file from the fd sector, s to that sector and 
verify that it is the LSN0 of that image.  Write that sector down as a 3 
byte hex value.  Quit ded.

Then, use dmode to set that address into wpc(first byte) and ofs(remaining 
hex integer) of the sd cards descriptor.

then do a dir /sd0 (or 1 as the case might be) and if all went well in yur 
detective work, you s/b be looking at that image files root directory 
contents.

I would temporarily hijack the /sd1 descriptor by 'dmode'ing its drv to 
match /sd0, and setting the wpc, ofs values into it, so you could be able 
to see the normal contents of /sd0, and the contents of that image file 
stored on /sd0 by doing a dir /sd1.

cd to the nitros9 directory, do a dir to see if its the right 6x09l2 for 
your machine, if it is, cd to it.

I maintain, or try to, several subdirs of various flavors on my main HD, a 
1Gb Seagate Hawk, 500 megs of which is formatted for os9 & the remainder 
available for hdbdos.  These are all located in nitros9/3.3.0/6309l2, 
6809l2, 6309l3 and 6809l3.

If you are similarly organized, then you should be able to cd to that 
flavors directory in the image, and issue a:

dsave -r -s24 /dd/nitros9/3.3.0/6309l2 >install;install

And when its done, have a repo on your hard drive (or 
/sd0/nitros9/3.3.0/flavername) that you can copy your old mb.* scripts 
into, and do the same with your existing bootlists, and run the old mb 
script to make a new, bootable floppy if thats how you do it, or if you 
have the /sh descriptor setup correctly, you can set that stp to an unused 
hdbdos vdisk, and apply the mb when it asks for a target disk, directly to 
/sh.  I have done that several times too.

Mark setup my HD when I couldn't get it to work, s I spent years booting 
from floppies till it hit sysgo and put me on the hard drive.  Eventually 
I fixed boot_tc3 and I've now been booting from the HD since 2008.

Thinking thru the boot process, it occurred to me that the boottrack never 
changes, or extremely rarely.  So, understanding that the boot_tc3, in the 
boottrack, and I expect any of our 'boot' modules, goes to the LSN0 of the 
boot drive to get the address and size of the OS9Boot file from DD.BT and 
DD.Bsz.  So I wrote bootlink, which allows me to switch to any OS9Boot 
file that exists in any of the hdbdos virtual disks on my hard drive, and 
does this by excruciatingly error checking every step of the way so there 
is a vanishingly small chance of ever putting yourself into a non-bootable 
state. What it does is open the LSN0 of the hard drive, and after 
calculating the actual sector offset into the hard drive where the OS9Boot 
file lives, and rewrites DD.BT and DD.Bsz to point at that particular 
virtual disks OS9Boot file.  Its almost a waste of drive space because 
that virtual disk needs nothing in it except a valid os9 boot file.

Say you have installed a boot image to hdbdos disk 130, then have set the 
/sh descriptors to 82, then used /sh as the target device for an mb 
script, then you can run my 'bootlink $82' or 'bootlink 130' it translates 
the decimal value, to re-adjust DD.BT and DD.Bsz. tap the reset button, 
and it should reboot to the configuration set in that OS9Boot file because 
it will be that OS9Boot that it uses when it reloads.

Complex, yes, works well, yes.  Bootlink can be had from my web page in 
the sig in Genes-os9-stf. Please be my guest.

There is one huge, flashing red lights, caveat about using /sh that way, 
the typ byte as dmode shows it, cannot be set so that d4 of that byte is 
set. If d7 is set, shows $80 in the type, that means its a hard drive, and 
since the sdx.dd descriptors all use rbsuper.dr, and the format program 
looks at the typ & dns bytes to auto-configure itself.  The bit d4 in the 
typ byte cannot ever be set so it reads $90 or more because if it is set, 
format will query the drive for its size and format the whole drive, 
blowing away nearly 30 years work of our coco development.  So bit d4 must 
be zero, forever and ever.

A dmode report on my /sh:
{t2|08}/DD/MAXTOR/CMDS:dmode /sh         

 nam=SH mgr=RBF ddr=rbsuper
 hpn=07 hpa=FF74 drv=07 stp=80 typ=81 dns=08 cyl=0023 sid=01
 vfy=01 sct=0012 t0s=0012 ilv=00 sas=08 wpc=1D ofs=BB90 rwc=

In this case the wpc and ofs values match the drive size recorded in that 
drives LSN0 which is 1DBB8F, so my hdbdos area starts on the next sector 
after the end of my /dd assignment.  Adjust your /sh to match that, and 
save JoelsSH.dd sh into your repo images modules/rbf and use that in your 
bootlist.  I do the same with /dd, /d0, /d1, /d2, /S1, /x0 and /x1. That 
way I build a new boot, and all my custom settings are preserved. Life is 
good.  But I'd better go get the coffee pot started.  Have fun digesting 
the above.

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