[Coco] rbsuper

[Tim Fadden]

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. :-)



-- 
Tim Fadden
"Hey Schmidt, don't forget about the six P's.
Proper Preparation Prevents Piss-Poor Performance!"