[Coco] BUG with rbsuper and tc3 drivers

[Tim Fadden]

On 2/12/2017 2:12 PM, Tormod Volden wrote:
> 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
>
Thanks Tormod for looking at this issue.

I did the following, which may help narrow down where things are getting 
munged up.

So now I did this.
makdir distro
used dmode to copy the /d0/nitros9/6809l2 contents to distro (disk I got 
from cloud9 that works)
then went to /sd0/nitros9/6809l2 and used dmode to copy the new stuff to 
distro (copy I downloaded from nightlies)
  I then used  distro contents to create an new floppy disk.

This works properly!

Then I went back into distro replacing the stuff from cloud9 with the 
nightlies ONE module at a time and making a boot to test. Here are the 
results.

1. I put the latest rbsuper.dr back in.   SCSI ID's work properly

2. I put the lltc3.dr back in.  SCSI ID's work properly

3. I put the new s0_tc3.dd's. SCSI ID's no longer work I see only target 0

Secondary issue.  accessing multiple custom partitions with custom 
device drivers.

This only works with the original distribution drivers and custom device 
descriptors I created with the proper sector sizes, offsets, etc .

I believe I read some where that rbsuper.dr query's the disk for size?  
If this is the case, partitioning will not work unless it this feature 
can be turned off.  There probably is, but I have not been able to find 
mention of how.

So, from the way I take it: The scsi ID issue has to do with the 
descriptors, and the partition issue has to do with the drivers.

If it would be helpful for you to have the actual driver and descriptor 
files I am using, let me know and I will try to get them on to my pc, 
and get them to you.

Again, I really appreciate your assistance. I have never set up my pc to 
do the compiling etc of the coco stuff, but I will try to get the 
repository and stuff set up. At the least perhaps I might see something 
that rings a bell It has been several years since I set the descriptors, 
etc. all up. I Backed up all the data from my drives/partitions onto SDC 
images, so can mess with the drives in case you want me to do some testing.


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