[Coco] Bootlink

Wed May 1 02:56:30 EDT 2013

On Wednesday 01 May 2013 01:29:34 Willard Goosey did opine:

> On Wed, May 01, 2013 at 12:35:23AM -0400, Gene Heskett wrote:
> > Thanks Kip.  Now I hope my checking to see if the vdisk you want to
> > boot
> 
> Sorry, running stock Tandy Disk BASIC and glenside IDE drivers here...
> 
> Willard

I don't believe bootlink will help you then.

But let me describe what the superdriver. combined with hdbdos can do.
+
Using my first scsi drive (scsi/ide, with nitros9 are now interchangeable 
as far as functional interface to the disk is concerned) as an example, it 
is a 1Gib drive.  I can use that whole drive as one os9 drive, in which 
case the cluster size is 16 sectors per bit in the F.A.T.

But the first drive is setup so that about 498 megs is formatted as an os9 
partition, with a cluster size of 4.

Now, HDBDOS has a 3 byte offset, in my case burned into the rom that Mark 
prepared quite a few years ago now, located at a fixed address in the rom, 
and which when used a a base offset, points at the first sector after the 
end of the os9 portion of the drive.  When in rsbasic, you tell it 
'driveoff' or 'driveon', you are switching HDBDOS from floppy access, to 
addressing the hard drive, starting at that address for a drive0 access.  A 
drive1 access adds 630 to that offset, drive2 adds another 630, wash rinse 
and repeat till you've hit drive255, so you effectively have 256 floppy 
disks of the original 35 track single sided formatting, but actually 
located on your hard drive.  That takes up only a bit over 41 megabytes of 
your hard drive. 41,287,680 bytes TBE.  And there is no reason why, on a 
coco3 thats in the all-ram mode, so that rom image is actually in ram, you 
can't poke those 3 addresses, whatever they are with those 3 byte 
incremented by another $0x27600, and have another 256 virtual floppies, 
stepping and repeating till you've run out of disks to copy, or you are out 
of drive.

Now, enter the superdriver kit, with some enhanced bit meanings in a device 
descriptor, and you can do exactly the same effective thing in nitros9.  
Here is the /sh version of dmodes output:

{t2|09}/DD: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=

Note the wpc and ofs values in the bottom line, containing $1D and $BB90, 
which combined are $1DBB90, the address of the first sector of virtual 
drive0 on _my_ hard drive.

Next, please note the stp=80 above.  This is the number of the virtual 
drive that will be accessed if I do a dir /sh, which because it contains a 
bootable os9 disk image, looks legit to nitros9:

{t2|09}/DD:dir /sh  

 Directory of /sh  1927/12/10 22:15 
OS9Boot         bttemp          mb.dw3fd        mb.dw3hd        dw3hd.bl 
sysgo           CMDS            ChangeLog       

Only one of those files is needed because my init module puts me on the 
hard drive before sysgo or anything else in that image is accessed,meaning 
the sysgo and grfdrv on my HD are used full time.  My mb scripts leave a 
copy of the scripts that generated that disk on the disk, for recovery 
purposes and my convenience.  The bttemp file is a copy of track 34, and 
also serves no purpose other than as a way to vfy I have the correct stuff 
hidden on track 34.

If I dmode /sh stp=00, then I will be looking at the vdisk known as drive0 
to hdbdos.  The 80 there now says I am looking at HDBDOS's drive 128.  This 
is my default drive to boot from if I boot from the HD.

This 'virtual disk' is os9gen-able with the mb script!  No floppy disks 
needed to make a new boot.  Say I wanted to make a boot specifically to run 
UmuseIII with, use dmode to set /sh to virtual disk 136, aka stp=88 (its a 
hex value of course), adjust the *.bl file to contain the stuff UmuseIII 
needs, and run your mb script, giving it /sh as the drive to build the new 
boot on.

When you have what you think is an image suitable for UmuseIII, ded the hd 
as /dd, and write down the values in DD.BT and DD.BSZ just in case things 
go south.  I'd also keep a floppy handy that is a complete boot, and which 
has a copy of ded on it too.  I made one, but have not needed it, but it 
would be good insurance, something to threaten Murphy with if he's nosing 
about. :)

Insurance on the shelf, run "bootlink $88".  When its done, about 3 or so 
seconds, and it reports no errors, tap the coco3's reset button for a hot 
reboot, or enter 'reboot' if you have it for a full cold reboot.  It will 
load track 34 from vdisk $80, but when the boot module is executed, it 
knows nothing of the file system on the disk, so it reads LSN0 of the HD to 
get DD.BT, and DD.BSZ for where and how long that OS9Boot file is.  But the 
surprise is that it will NOT get the address of the OS9Boot file on drive 
128, but the address of the OS9Boot file on drive 136, so it will load the 
one you just made to run UmuseIII with.

To restore it to where you were, 'bootlink 128' or 'bootlink $80' and you 
should be right back where you started.

Now, I think I'd keep a list taped to the monitor of which vdisk was to run 
what game or other special program that needs its custom version of nitros9 
to work right.

And to me, its all a lot handier than rebooting to rsdos so you can run 
link.bas.  ;-)

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
He who is known as an early riser need not get up until noon.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.