[Coco] rbsuper

[Gene Heskett]

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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>