[Coco] [CoCo] bootlink, SH, NitrOS-9 info needed

[Gene Heskett]

On Friday 08 September 2017 01:45:46 Gene Heskett wrote:

> On Friday 08 September 2017 00:11:41 David Ladd wrote:
> > Gene Heskett,
> >
> > I am asking this if you still remember off hand or anyone else whom
> > has used the /SH descriptor for accessing the HDBDOS vdisk #'s from
> > within NitrOS-9.
> >
> > I was reading your documentation Gene for bootlink and see that
> > using this SH descriptor for what ever superdrive HDD interface you
> > are using you can access your virtual HDBDOS drive's.  What I would
> > like to know is where does one find this SH driver or build it?
> >
> > I have been browsing the NitrOS-9 repo looking for a reference to
> > this SH descriptor and didn't see one other than listed in your
> > documentation. Just wanted to know if this is still a valid option
> > in current NitrOS-9 and RBSuper or no?
> >
> > Thanks :D
>
> Sure is, or was the last time I pulled and built nitros9. About 18
> months back now.
>
> Let me see if I can describe the requirements to use it. Starting with
> the superdesc.asm, you'll need to set the descriptor option that
> splits the 512 byte sector into a low half and high half of 256 bytes
> each, so that you can make use of every byte of the 512 byte disk
> sector.
>
> This, when a disk read is done, hands os9 the low half of the sector
> if the sector address is an even number, and the high half of the
> sector if the address is odd.
>
> Next, get the hard drives lsn0, first 3 bytes, which is the hex
> representation of the size of the portion of the disk which is
> allocated to os9's use. Call it a partition if you'd like because
> thats what it is.
>
> Add 1 to that hex value and break it into 2 pieces to be written to
> the sh descriptors ofs and wpc positions in the descriptor. What you
> just did was to give that descriptor the starting address of the first
> byte of the first 35 track floppy image, in the first bank of 256 disk
> images usable by hdb-dos and basic. There's another bit in the /sh
> descriptor that enables the "stp" value to set the disk images offset
> so that all 256 disk image locations can be used from one descriptor,
> just change the stp with dmode and you are looking at a new disk
> image. This won't work for hd to hd copies, you'll need two
> descriptors for that since the stp does not take effect until os9 has
> had a chance to reread lsn0 and update its drive tables. That never
> gets a chance to be done while doing a copy.
>
> This scheme can be repeated by setting up an additional descriptor and
> adding 35*18*256 to the value placed in /sh for the initial 3 byte
> sector offset to establish the start of the 2nd bank in /si, step &
> repeat for /sj, /sk etc until the hard drive has been fully allocated.
>
> There are several other ways to make use of the basic /sh skeleton, I
> have even, before I had drivewire working, located where I had put an
> install .dsk image on the hard drive using a serial cable and rzsz,
> took its address from the file descriptor, and pointed /sh at the
> image, and actually installed it from where that file was sitting just
> as if it was a floppy image, except it was much faster since it was
> being accessed at the hard drives speed.
>
> One huge, HUGE caveat! Once you have first of all these descriptors
> configured, make a new directory someplace safe (marked real floppy?)
> and save all those descriptors as you get them figured out, because
> all this data is going to be unique to your system.  And recovering it
> if its lost is going to be a 9 digit excedrin headache.
>
> This means you will need to write a script so that anytime you make a
> new build, you can copy all those descriptors back over the top of the
> ones just built else you will be reinventing several different sized
> wheels before you are up and running on the new install. I usually do
> that while the install image is mounted by drivewire.
>
> And I've no doubt left out some vital details, so use superdesc.asm as
> the final word. Unfortunately its too terse and concise and will need
> several reads.  Or it sure did for me. But as I come up on 83 next
> month, I find myself pleading oldtimers way too often. :)
>
> It can be complex until the lights come on but don't give up.
>
And I missed that your question was asking about a driver.  Its not a 
driver, but a pair of descriptors, one for the scsi_tc3 systems, and a 
duplicate functionwise, for the ide using systems. Because the drivers 
and descriptors have been broken up so much in order to save some 
bootfile memory, we now have a 4 name chain for each descriptor. doing 
an os9dump of one of the two:


  Addr     0 1  2 3  4 5  6 7  8 9  A B  C D  E F 0 2 4 6 8 A C E
--------  ---- ---- ---- ---- ---- ---- ---- ---- ----------------
00000000  87cd 0041 002b f189 a700 2d00 30ff ffff .M.A.+q.'.-.0...
00000010  7416 0100 0081 0800 2301 0100 1200 1203 t.......#.......
00000020  0800 0000 0000 0000 0037 0253 c852 42c6 .........7.SHRBF
00000030  7262 7375 7065 f26c 6c74 63b3 0000 e450 rbsuperlltc3..dP
00000040  51                                      Q

Shows the device name, SH, with the msb of the H set to mark the end of 
the descriptors name, followed by RBF with the msb of the F set for the 
same reason, then the main drivers name rbsuper with the last r's msb 
set, and finally the hardware adapter, lltc3 that translates the rbsuper 
connands to the actual hardware that does the work, in this case 
lltc3 "low level tc3", which for an ide system would have been llide.

Neither of these two descriptors exist in the src tree until the Makefile 
actually assembles "sh_tc3.dd" or "ih_ide.dd", and you choose one or the 
other to use as the RBF foundation of your disk system by selecting it 
from the bootlist when you do an "mb"

All this modularization moves more data into "sysram", at least doubling 
the sysram useage per device descriptor and my machine is now out of 
sysram to the point that I don't have enough left to format a floppy.  
There are other ways to empty a disk, but they are a right pain in the 
ass.  They do work, but it can be a bunch of putzing around.  All 
compounded into that right pain in the ass by the fact that os9gen, if 
it finds track 34 pre-allocated, does a skip of writing a new boottrack, 
skipping it silently without a report of any kind to alert the user that 
his boottrack did NOT get updated.  Grrr.  So you have to make it 
visible by creating a directory entry to it along with an fd.sector just 
so it can be deleted, clearing those 18  bits in the FAT. KRNL_2_DIR 
does that, get it from my web page.

But this should explain why you cannot find them in the repo pull until 
you have built the pull.

Does this help explain things?

> Cheers David, 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>


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>