[Coco] rbsuper

Gene Heskett gheskett at shentel.net
Sat Feb 4 16:45:49 EST 2017 

On Saturday 04 February 2017 13:31:29 Tim Fadden wrote:

> On 2/4/2017 9:19 AM, Gene Heskett wrote:
> > On Saturday 04 February 2017 07:28:49 Tormod Volden wrote:
> >> On Sat, Feb 4, 2017 at 12:06 PM, Gene Heskett
> >> <gheskett at shentel.net>
> >
> > wrote:
> >>> On Saturday 04 February 2017 00:10:20 Tim Fadden wrote:
> >>>> On 2/3/2017 8:02 PM, Gene Heskett wrote:
> >>>
> >>>  From the track 34 module boot_scsi.asm code:
> >>>
> >>> * So now, this can be a base zero decimal value!
> >>>                 IFNDEF    ITDNS
> >>> ITDNS          EQU       0
> >>>                 ENDC
> >>> WhichDrv       FCB       ITDNS
> >>>                 EMOD
> >>> eom            EQU       *
> >>>                 END
> >>>
> >>> ================
> >>> So it also keeps track of which slot the drive controller is in in
> >>> the mpi, its base address in the top page of ram,, and WhichDrv
> >>> now contains the decimal scsi bus address of the drive its going
> >>> to access once track 34 is loaded and exec'd.
> >>
> >> Trying to distill above information from Gene: The boot loader
> >> module doesn't use any descriptor, so the SCSI ID is hardcoded into
> >> the last byte of that module (before CRC bytes). With the later
> >> boot module code, this ID is 0,1,2,3 etc and not 1,2,4,8 as in
> >> older boot modules.
> >>
> >> OK, so that's the boot module. However, Tim cannot access the SCSI
> >> disk even after booting from floppy, so something else is wrong
> >> too.
> >>
> >> I see in level2/coco3/modules/makefile that the different s0_tc3.dd
> >> to s6_tc3.dd descriptors are built from superdesc.asm with
> >> different ID0 to ID6 defines. These are defined in rules.mak to be
> >> different settings (0-6) of ITDRV whereas ITDNS is used for
> >> slave/master (1/0). These fill in the "drive number" and "drive
> >> density" fields in the generic superdesc template.
> >>
> >> Is this correct? Apparently the use of ITDRV/ITDNS is not
> >> consistent with the boot module code but that doesn't necessarily
> >> mean it is wrong although it is surely confusing.
> >>
> >> The descriptor will be handled by rbsuper.dr which will pass on
> >> this descriptor info to the lltc3.dr low-level driver (built from
> >> llscsi.asm). More precisely it is line 793 of llscsi.asm where the
> >> SCSI ID is read from V.DnsByte, which is cached from the PD.DNS
> >> offset of the path descriptor (line 545). However PD.DNS is not
> >> referenced explicitly in rbsuper.asm (other than for extracting a
> >> HDBDOS flag in bit 3) so that is where I lose track of the
> >> parameter.
> >>
> >> Regards,
> >> Tormod
> >
> > That may bear some additional digging into then, Tormod.
> >
> > I have not done a fresh pull from the hg repo since March 26 2016. 
> > And that pull gave me no such problems that I am aware of. I don't
> > do updates, but rename the old nitros9 with the current date-time,
> > and pull fresh, that way I have untouched, working history.
> >
> > However, stirring up things in my ageing wet ram, I now recall that
> > I have a script that overwrites the new descriptors I would use with
> > my old ones because that preserves my ofs and wpc offsets. It also
> > preserves a lot of stuffs the makefile might not be getting right
> > yet. So I am not testing the new descriptors, and thats a data point
> > to remember.
> >
> > I'll see about lugging it out to the air hose for a good dusting and
> > cleaning in the next day or so. And if those drives will spin up, I
> > had to give them a bump push the last time they sat this long.
> >
> > Tim, just to be sure I'm on the same page, what controller do you
> > have? Mine is a tc3. And, what is the io address in the old
> > descriptor vs the new ones?  The tc3 has alternate addresses
> > available.
> >
> > Tim , can we see the dmode -olddesc and dmode -newdesc for
> > the "s0_tc3.dd" ?
> >
> > Tormod, does the hg pull build on a windows machine if he has lwasm
> > and the toolshed installed and built? I have little to zero problems
> > building it here, but this is a pure linux house too. However,
> > everything but the pi running the newest lathe, is still on debian
> > wheezy(7.9), only the pi has jessie (8.6 iirc) on it. I'm gradually
> > getting my feet wet on jessie IOW. :)
> >
> > Cheers, Gene Heskett
>
> OLD s0_tc3.dd .......untouched as it came on the disk from cloud9 June
> 01, 2008
> nam=s0 mgr=RBF ddr=rbsuper
> hpn=07 hpa=FF74 drv=00  stp=00 typ=91 dns=00 cyl=007F sid=40
> vfy=01  sct=020    t0s=020 ilv=01  sas=08 wpc=00 ofs=0000 rwc=
>
> NEW s0_tc3.dd   ................untouched from nitros9 build
> nam=s0 mgr=RBF ddr=rbsuper
> hpn=07 hpa=FF74 drv=00  stp=00 typ=81 dns=00 cyl=007F sid=40
> vfy=01  sct=020    t0s=020 ilv=01  sas=10 wpc=00 ofs=0000 rwc=
>
> descriptor for the first partition I am using old version that works
> with the version I purchased version 2.1 in June 2008 so some time
> between then and now is when it went south :-) Some where along years
> ago, the line the tc3/superdriver broke.  I just now decided to try
> and get the new stuff working again.
>
> actual info for my first partition of the name p0, and DD
> s0p0dd.dd
> nam=DD mgr=RBF ddr=rbsuper
> hpn=07 hpa=FF74  drv=00     stp=00 typ=83 dns=10  cyl=012C sid=24
> vfy=01  sct=0060    t0s=0060 ilv=01  sas=02 wpc=00 ofs=0000 rwc=
>
> I also have 3 more partitions on the drive of different sizes.
> their actual names are p0, p1, p2, and p3
>
> Thanks all for the input.  If worse comes to worse I will just keep
> the old versions and not update any more.  It would be nice to get it
> figured out though. :-)
>
Look at the diffs between your "type" bytes, and the "dns" byte, then see 
if you can sort out what those diffs mean.

So thats bit D4 in the 'type' location that is changed between old & new, 
and then just to confuse me even worse, On the disk, dns is also changed 
in that same bit, bit D4.  Somewhere in there is the key.  Or maybe two 
keys. superdesc.asm should be the reference doc.  But its complex 
because of a lack of bits just to say true/false for a given option, the 
meaning of 3 or 4 bits is dependent on the setting of at least 2 other 
bits. But its there, just too darned 'concise' to suit me.
> -- <-
configure your email agent to add a single space after the double dash, 
and your sigs won't get copied into the replies. Not that your sig is 
bad, but its just noise in the reply. 

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>

More information about the Coco mailing list