[Coco] rbsuper

[Gene Heskett]

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