[Coco] BUG with rbsuper and tc3 drivers

[Tormod Volden]

On Tue, Feb 7, 2017 at 12:57 AM, Tim Fadden wrote:
>>> I have two disks attached one set to ID 0, and one set to ID 4
>>> OK so I made a boot floppy with sdc drivers, sdsuper/tc3 drivers, and
>>> floppy controller drivers with floppy as /dd.
>>>
>>> It all boots up fine.
>>>
>>> Now when doing a dir listing on /sd0 through /sd6 the system comes back
>>> with the listing of target 0!
>>> all the descriptors show their respective target  ie drv=0, drv=1, etc.
>>> so either tc3 driver, or sbdriver is not handling the scsi ID at all.

>>> Is any one savvy enough to figure out where the scsi ID is being egnored?

Hi Tim,

Isn't this the same issue that we discussed in the other thread? Based
on my analysis there, and your observations here, I believe the reason
is that the descriptors set different "drv" values, however the tc3
(or low level SCSI) driver takes the SCSI target ID from the 3 lowest
bits of "dns" (and the 3 highest bits can be used to specify SCSI
LUN).

Please try:
dmode /sd4 dns=4
and see if that gives you the target 4 disk on /sd4.

Now why is the dns field and not the drv field used for the SCSI
target ID? I must refer to fellow NitrOS-9 developers. This code and
the meaning of ID, drv, and dns have been changed back and forth in
NitrOS-9 many times, often without any meaningful commit message. What
is the master plan? Is the "drv" field reserved for something else?
SCSI bus/channel? Or something else in the driver stack? I see mention
of PD.DRV in rbsuper.asm as index for Disk Drive Tables.

According to the original SuperDriver documentation from Cloud9 the
different stock descriptors should refer to different SCSI target IDs,
so either the descriptors or drivers must be fixed. Just tell me
which, and why!

Regards,
Tormod