[Coco] rbsuper

[Tim Fadden]

On 2/4/2017 5:28 AM, 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
>
Tormod,

Correct I am booting from floppy and only going to the scsi drive after 
the kernel is loaded, and then reading from /dd.

As a note, scsi disks do not have slave/master. only the ID of 0 to 6, 
and 7 reserved for the controller for a total of 8 devices. unless you 
go to a newer standard that has 16 addresses not for this discussion.

As far as the code goes, it is beyond me.  I will try creating my 
specific descriptors from the latest release instead of using the ones 
that worked from the previous version. Perhaps something in them changed.

Thanks for the help guys.  If worse comes to worse, I will just use the 
older versions. With so many people working on the code, and all the 
differences of hardware people are using, I doubt it will get fixed any 
time soon. he he he I wonder if any one else has even tried to set it up 
with the tc3 controller, and the latest nitros9 version.



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