[Coco] rbsuper

[Tim Fadden]

On 2/3/2017 8:02 PM, Gene Heskett wrote:
> On Friday 03 February 2017 20:39:49 Tim Fadden wrote:
>
>> Oh, something else I did, i made a boot with the floppy as /DD  this
>> came up all the way.  I can still Not access the scsi disk.  not even
>> a light flicker.
>>
>> On 2/3/2017 6:24 PM, Tim Fadden wrote:
>>> Programmers.
>>>
>>> I am using SuperDriver 2.1 for a large scsi drive for nitros9 only.
>>> the floppy I originally bought was ver. 2.1.  I created 4 partitions
>>> on a scsi disk, and this version has been working great for several
>>> years.
>>>
>>> Ok,
>>>
>>> So I have been attempting to upgrade to the nightly download of
>>> nitros9. I copied over the specific descriptors I made originally
>>> from the 2.1 disk, using the latest drivers with the distribution.
>>>
>>> I get a complete boot, but it hangs when accessing /dd, which is my
>>> first partition on the HD.
>>>
>>> So, I made the same  exact kernel using the rbsuper.dr and lltc3.dr
>>> drivers off of the 2.1 release, and it works again.
>>>
>>> I will try using the new rbsuper with the older lltc3, and
>>> visa-versa to see if it can be narrowed down to one or the other.
>>>
>>> Is any one else using the latest nitros9 build with a tc3?
>>>
>>> I pulled the the nitros9 from the nightlies on the 10tn.  But I
>>> think this has been a problem longer than that because I had the
>>> same issue with several earlier versions years ago, not months.
>>>
>>> I have no way to compile anything other than on the coco, so I am
>>> reliant on the downloadables.
>>>
>>> For now I will use the latest build with the two older driver
>>> versions.   All else works great including sdc and drivewire.
>>> although the sdc/nitros9 does wig out at times, that's for another
>>> email! HA HA HA
>>>
>>> Any help is appreciated.
> This rings bells, Tim. The scsi bus address was at one time years ago, a
> marching bit in that byte, see the very end of the driver. This means
> that drive 0 was actually an 0x01 in that byte. Drive 2 was an 0x02,
> drive 3 was an 0x04, 4 was 0x08, 5 was 0x10, 6 was 0x20, and 0x40 for
> drive 7. If drive 0 was intended, and that byte is zeroed, not even an
> access flicker will you get.  Several years ago, that ran me over the
> coals, and there was a few spare bytes left, so I added a small routine
> that instead of marching a set bit across that byte, translated the
> decimal value of that byte into the marching bit the driver wanted to
> put on the cable. So I subbed a patch that fixed both the descriptor and
> the driver. So if you've been used to having that byte set at 0x01 for
> drive zero, and you don't have a drive 1 to give you a clue. So look up
> the srcs, I am pretty sure that byte is the last byte before the crc,
> and if ded shows its a 0x01, change it to 0x00, save & verify. Then make
> another bootfile & test.  But use the new rbsuper and lltc3.
>
>> --
>> Tim Fadden
>> "Hey Schmidt, don't forget about the six P's.
>> Proper Preparation Prevents Piss-Poor Performance!"
>
> Cheers, Gene Heskett
Are you talking about using ded on the descriptor ie s0.dd or one of the 
drivers ie super, or scsi.
I would think if the descriptor says 0, and the disk is set to 0, then 
the problem is in the driver talking to the descriptor. And why do the 
original un-hacked drivers work correctly?
I will try making new descriptors with all the new stuff perhaps that 
will make them talk together correctly.
All I ever did was use dmode to set the descriptors.
If I had a little more specific of what to ded and diddle with I might 
give it a go, but its a bit beyond me.
Will let you know how it goes.



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