[Coco] rbsuper

Gene Heskett gheskett at shentel.net
Sat Feb 4 06:06:04 EST 2017

On Saturday 04 February 2017 00:10:20 Tim Fadden wrote:

> 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.
Some ancient, like me,  CS-101 here, and working from memory as I've not 
yet cleaned that area in my basement after getting $12k worth of water 
ingress treatment done in it last spring. So, covered in cement dust 
from all the concrete demolition, I haven't fired my system up since, 
and I've been busy with a new (to me) 11x36 Sheldon metal lathe thats 
about 70yo and badly abused, doing restoration and cnc conversion.  
Priorities...  And its being run by a raspberry pi!

Back to the subject.

The descriptors only count after its booted. What I am talking about is 
the boot module on track 34 on a floppy, or on track 34 of the "virtual" 
floppy if you have hdbdos.

The boot sequence is, when booting from a HD, using hdbdos, is that 
hdbdos will access track 34 of whatever you have configured for the first 
boot load, loads track 34 and execs it to move things to all ram mode, 
then puts that at its fixed memory location in high ram, then opens a 
green screen sized to whatever the rel module proclaims, and then executes 
the boot module. The boot module is configured to look at LSN0 of the 
selected device, get the address and size of the os9boot file from LSN0, 
and load and execute that to complete the boot process.  That address
is the raw address of the file on the device and it doesn't actually
care where on the drive it actually is, as long as its there at that
address! The ofs and wp? in the descriptor is not yet in play.

The boot module you put on track 34, in bttemp when you run the mb 
script, is hard coded for the initial boots track 34 location, and 
hdbdos can translate that to be the original floppy, or to a HD.

It gets this track 34 from the device its hard coded for.  Could be the 
original floppy, or one of hdbdos's virtual floppies on the hard drive, 
or I suspect these days, from the sdc kit. I have one, but have not 
succeeded in accessing it yet, an addressing clash I believe. My mpi is, 
shall we say, busy.

This ability to load the os9boot file from any of the 255 virtual 
floppies on the hard drive is the reason I wrote that bootlink utility 
that I've published.  But I probably confusing the real issue here, so
lets go look at the code in the boot module itself.

From the track 34 module boot_scsi.asm code:
* Sooooo, at end of module, the FF64XX, the XX is not a marching bit
* pattern any more.  Cool but a huge gotcha needing makefile changes
* all over.  And theres too many of them.
* define that byte
scsival        FCB       $80+1,$80+2,$80+4,$80+8,$80+16,$80+32,$80+64,$80

* SCSI Wake-Up Routine
* Destroys: X
wakeup         ldx       #0                  load X with 0 (counter)
* Step 1: Wait for BUSY+SEL to be clear
wake           lda       SCSISTAT,y          obtain SCSI status byte
               bita      #BUSY               BUSY clear?
               beq       wake1               branch if so
               leax      -1,x                else count down
               bne       wake                and try again if not timed out
               bra       wake4               else branch to timeout
* Aha!  New code! so ITDRV goes down one count
* Nice we get a notice.  ChangeLog's would be nice
* But are a pain in the ass to maintain.

* Step 2: Put our SCSI ID on the bus
wake1          bsr       wake3               small delay
               lda       WhichDrv,pcr        get SCSI ID
               leax      <scsival,pcr        point to SCSI value table above
               lda       a,x                 get appropriate bitmask
               sta       SCSIDATA,y          put on SCSI bus
               bsr       wake3               small delay
               sta       SCSISEL,y           and select
               ldx       #0                  load X with 0 (counter)
wake2          lda       SCSISTAT,y          obtain SCSI status byte
               bita      #BUSY               BUSY set?
               bne       wake3               if so, exit without error
               leax      -1,x                else count down
               bne       wake2               and try again if not timed out
wake4          comb                          set carry
               ldb       #E$NotRdy           and load error
wake3          rts                           then return

**********skip to end of file here**************

                IFGT      Level-1
* Fillers to get to $1D0
Pad            FILL      $39,$1D0-3-1-2-1-*
* rev1, add selections for MPI slot and bus address of drive
* 2012\11\05 Gene Heskett
* The default SCSI ID is here, but first do MPI slot
               IFEQ      MPI-1
CntlSlot       FCB       SDMPI
CntrSlot       FCB       $FF		no mpi
Address        FDB       SDAddr
* So now, this can be a base zero decimal value!
               IFNDEF    ITDNS
ITDNS          EQU       0
WhichDrv       FCB       ITDNS
eom            EQU       *

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.

Because this separation point exists, you can, from a single track 34
on an otherwise empty floppy, proceed to load the os9boot file from 
any of the 255 virtual disks on the hard drive.  It all depends on 
the boot module merged into bttemp in the mb script.

So you can have os9boots customized to do various things rather than 
having a one size does it all but its too big and you are out of 
system ram way too easily.

The problem is a conceptual one that I had to think about when I wrote 
the bootlink utility you can get from my web page in the sig below.

Or, you can run LINK.BAS from rsbasic. But this is not your immediate 
problem according to my thinking.

I think the value of WhichDrv in the code snippet above, and in the boot 
module you are building track 34 from (bttemp in the mb script) is.

An address of 0x00 there, now translates to an 0x01, the first drive on 
a scsi bus. This is correct for the new code above.

There is not a drive at address 0x00, its an invalid address on the 
scsi bus when the disk to access is being selected as at least one 
and only one drive must be selected. 

So when the old code is executed now, no drive is selected as the older 
boot module expects to find an 0x01 there for drive zero.  Conversely, 
the new code, if it found an 0x01 there, would be trying to access not 
drive 0, but drive 1, the second drive.

So If you've only one drive, pfffft.  No blinking led's,
just a timeout & a not ready error, if its reported, I do not recall.

And I think that is the real problem. Put a zero in that byte with ded, 
and V(erify) and Write and it should then access the correct, 
first drive on the bus which when the descriptor comes into play, is
drive 0.

Confusin' ain't it?  But in the hardware world, thats how scsi works. 

I could be full of it, but thats sure the first thing I'd check. 
> --
> 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>

More information about the Coco mailing list