[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-*
ENDC
* 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
ELSE
CntrSlot FCB $FF no mpi
ENDC
Address FDB SDAddr
* So now, this can be a base zero decimal value!
IFNDEF ITDNS
ITDNS EQU 0
ENDC
WhichDrv FCB ITDNS
EMOD
eom EQU *
END
================
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