[Coco] rbsuper

[Tormod Volden]

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