Conference hydra::amiga_v1

    I know some one wilt a similar problem but with a Maxtor drive built
    for DEC 3100 SCSI system's.
    
    The problem was resolved with a new eprom from Maxtor .
    
    The drive might have a spinup disable jumper (I don't know the drive
    well).
    
    	I hope this help a bit
    
    		Steve G

All DEC RZ drives have a special MODE_SENSE page (25h) which currently has
1 bit of 1 byte defined:  SPD (for Spin Up Disable).

If set to 1, the drive will not spin up on power up, if set to 0 it will. 
Issueing a START_STOP_UNIT command will spin it up.

This takes the place of the jumper. There is no jumper on RZ22/23/55.

The reason a new eprom helped is that since this info must be both
changeable and available on power up (and before spin up)  it has to be
in EEPROM (electrically erasable PROM). Maxtor just gave you one with
this bit set to 0.

John

re .1:

By the way, what do you mean by:

>    I know some one wilt a similar problem but with a Maxtor drive built
>    for DEC 3100 SCSI system's.
    

"... built for DEC 3100 ..."

There is (should be) no such thing!

John

    The only diff I believe between the normal Maxdor SCSI and the one used
    on the 3100 is the eprom.
    
    The drive does not spin up if connected to a different SCSI
    controller...(ie non DEC)
    

the reason I asked is that the only qualified 5.25 drive for PMAX (DS3100)and 
PVAX (VS3100) is a real RZ55 (micropolis) and soon the RZ56.

John

    
    
    	The the problem can be fixed by a single scsi command this can
    be fixed. GVP supports a direct SCSI command interface. If someone
    will post the command packet you can write your own program to send
    the command.
    
    		Steve Peters
    

It's a SCSI MODE_SELECT command for PAGE 25h. Change the first byte
in the actual page data (byte 2 in the page) to = 0. Then issue a 
MODE_SELECT with the SP bit = 1 (save parameters).

John

    re: .7
    
    Can you translate that into a byte string for those of us without the
    SCSI specs?  I have a C-Ltd. controller that I'm trying to use with an
    RZ23 to test the controller.
    
    -tl

MODE_SELECT looks like this:

byte	value	description

0	15h	opcode
1	1	SP (Save Parameters) (there are other fields here, but =0)
2	0	reserved
3	0	reserved (ANSI likes these :-)
4	x	parameter list length
5	0	control byte

For any MODE_SELECT operation, you need to send data. Page 25h will fix your
spin-up problem like this:


byte	value	description

0	0	reserved
1	0	meduim type (direct access)
2	0	reserved (see, I told you!)
3	8	block descriptor length.

		those 4 bytes were the "Mode Sense/select header"
		the next 8 are the "Block Descriptor"

0	0	density code
1	3	number of blocks(MSB)
2	20h	""
3	40h	number of blocks (LSB)
4	0	reserved
5	0	block length(MSB)
6	2	""
7	0	block length

		now for the actual page (only 25h here)
0	25h	page code
1	17h	length
2	0	bit 0 means SPIN-UP DISABLE, so =0 means spin-up on power up
3	0
..	..	fill remaining bytes of page 25 with 0. You guessed it,
24	0	  reserved!


The header, block descriptor and page descriptor all go in memory one
after the other. The command gets sent first, then the data. So for a byte
stream (after you send the command) you have:


0,0,0,8,0,3,20h,40h,0,0,2,0,25h,17h,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

Send these as data and your drive should now spin up on power up.

John

Disclaimer:  Look at the time of this note!

> MODE_SELECT looks like this:

> byte	value	description

> 0	15h	opcode
> 1	1	SP (Save Parameters) (there are other fields here, but =0)
> 2	0	reserved
> 3	0	reserved (ANSI likes these :-)
> 4	x	parameter list length
> 5	0	control byte


The "x" for parameter list length should be 4+8+25 = 37.

BTW this is called the CDB for Command Descriptor Block.

SCSI Trivia!

John

John, I have an RZ22 which I am also trying to get working. Same problem, does
not spin up. If the spin-up on power-up bit is changed, does it stay changed,
or does it reset when the drive power is cycled? If it stays changed, is there
any utility or diagnostic that runs on the VAX that one can use to flip this
bit? I have an A2090 on my Amiga, and I know of know way of sending direct
SCSI commands to the drive.

Thanks for any help.

Frank

RZ22 and RZ23 are virtually identical. The 22 is a depopulated 23.

This change (clearing the bit) will only be permanant if the SP bit
in the second byte of the MODE_SELECT command is set (SP = Save Parameters)


I imagine there is a way to get the command via a 2090. CB?

Other than that, if your near NKS (Marlboro) Digital I could do it for you
in about 10 seconds. 

John

    Re: .12
    
    I see absolutly no reason why the 2090 shouldn't be able to transmit
    that command, but I also don't see me writing the software that
    would enable you to do so. ;-}
    Until CBM whips up a new 2090 software ala the 2091 stuff, it's
    time to take that HD on a trip...
    
    Regards,
    
    <CB>

So the 2090(a) can accept a user SCSI command?  Do you have any docs on it, CB?

I'd be willing to give it a shot. I have this annoying "pending unit attention"
hassel with my Quantum that requires me to soft boot after the first power up
to clear it...

John

    Re: .14
    
    Well, I only have what you'll get soon, the A500/A2000 Technical
    Reference Manual. The information there _might_ do the trick, but
    if it doesn't, you'll have to crawl to CBM and barf, ehr, request
    a new software revision for the 2090(a) within the next few hours.
    ;-)
    
    Regards,
    
    <CB>

re:12

John, what do you use to make the change? Is there a utility that will run
on a VAXstation 3100 etc, or even (ugh!) a DECstation 320 (Our IBM PC clone
with SCSI interface) that I can snarf and use here? If not, maybe I'll take
you up on your offer to "fix" it for me. I work up in Littleton (LJO) but
live in Framingham so I pass by Marlboro an way to/from work.

Frank

For stuff like this, we use an Adaptec SDS-3 (Wyse 386, Adaptec HW and SW).

VMS just released their SCSI Third Party Support Project with VMS V5.3 FT.
Now, all VMS running machines with a SCSI port (Currently PVAX and FireFox
(er, VS3100 and VS3500)) provide the user with a Generic SCSI class driver
which would make it real simple to do this sort of thing. I have the docs
for this or get a copy of 5.3 FT and you'll get them.

As for DS3100 (DECstation 3100 - PMAX Risc) I'm sure it's possible for a 
Unix expert :-)

I don't know anything about the DEC IBM PC thingies (except that I glad I have
an Amiga :-)

Otherwise your welcome to stop by. I'm out till Monday though...


Let me know.
John

    Well I wrote the program (under V5.3) and still can't get there.  I get
    a success back in everything but the top byte of the IOSB, which
    returns the SCSI STS.  It contained a 2 which if I interpret things
    properly, means a "CHECK CONDITION", in other words I need to request
    sense the error to get more details.  I'm guessing at this point though
    that maybe the problem is that I need to to a START_STOP_UNIT command
    to get the drive into a "ready" state.  Does this sound plausible?  If
    so, can someone please give me the binary data for the command and data
    buffers for a command to get the drive into a ready state?
    
    -tl
    
    PS  Is there any on-line documentation on SCSI commands?

Yes, MODE_SENSE and MODE_SELECT (among others) do not work on RZ22/23 until it's
spun up. The reason is that the RZ22/23 load most of it's code from disk after 
spin-up. The ROM only has power up diags and a few other essential commands.

try this sequence:

TUR			should get check_cond (02) with UNIT_ATTENTION sense
TUR			should get check_cond with NOT_READY sense
START_STOP_UNIT		should spin it up (you'll hear it)
TUR			should work fine
MODE_SELECT		(as in previous note) should work fine.

<power cycle should be fine now>


TEST_UNIT_READY (TUR):

byte	value	desc
0	00	opcode
1	00	LUN and reserved
2	00	res
3	00	res
4	00	res
5	00	control byte

START_STOP_UNIT:

byte	value	desc
0	1Bh	opcode
1	0 or 1	IMMED bit. 0 means return after spun up, 1 = return immediately
			(use 0)
2	0	res
3	0	res
4	0 or 1	START bit. 0 = stop unit, 1 = start unit
5	0	control byte


In these descriptions I've not given all the bit field definitions of each
byte, but have supplied a value to set the proper fields.

There is online docs, but I can't distribute them.  DEC will be providing docs
with VMS V5.3 (or was that 5.4?)



John

    The program posted in the following reply did the trick.  Please, no
    comments on style, choice of language, or anything else.  If you need
    this and don't like it, tough.  I also disavow any knowledge or
    responsibility for this program.  Thanks again to previous replies to
    this note.  I now have a hard disk running and can prove that my C-Ltd
    controller is working and my OMTI-3527 is not.
    
    Anyway, to run this program you must:
    
    1) Be running VMS FT 5.3
    
    2) Have set the bit in VMSD1 to prohibit autoconfiguring your drive. 
    The bits are in order from bit 0 for DKA000 to bit 31 for DKD700.  So
    DKB300 would be disabled from autoconfiguring by making VMSD1
    ^x00000800.  Should be set during an interactive boot or you'll have to
    reboot.  Although the parameter is a dynamic parameter, it is checked
    during boot time.
    
    3) Load the Generic SCSI driver for your drive with sysgen:
    
    	SYSGEN> CONNECT GKB300/NOADAPTER
    
    or whatever the appropriate controller and unit number is.  Same as the
    DK drive only device code GK.
    
    4) Define GKB100 to be whatever your GK device name is, unless it is
    already GKB100, then do nothing.
    
    	$ DEFINE GKB100 GKB300
    
    5) RUN SPE
    
    -tl
    

	.TITLE	spe - Spin up enable for RZ23 disk drives
	.IDENT	/x01.00/
 
;++
; FACILITY: [~tbs~]
; 
; FUNCTIONAL DESCRIPTION:
; 
;	 This routine enables spin up on power up for RZ23 drives.  It uses the
;	 GKDRIVER generic SCSI port interface to send the appropriate command
;	 directly to the device.
; 
; ENVIRONMENT: VMS V5.3 with support for generic SCSI devices
; 
; AUTHOR: Todd Little, CREATION-DATE: 11-Sep-1989
; 
; MODIFIED BY: 
; 
;--
;
	.SUBTITLE DECLARATIONS
 
 
; OWN STORAGE:
 
ms_cmd:
	.byte	^x15		; opcode - MODE_SELECT
	.byte	1		; flags - Save Parameters
	.byte	0		; reserved
	.byte	0		; reserved
	.byte	ms_data_len	; parameter list length
	.byte	0		; control byte

ms_cmd_len = .-ms_cmd

;
; parameter list for the MODE_SELECT
;
ms_data:
;
; Mode Sense/Select header
;
	.byte	0		; reserved
	.byte	0		; medium type (direct access)
	.byte	0		; reserved
	.byte	8		; block descriptor length
;
; Block Descriptor
;
	.byte	0		; density code
	.byte	3		; number of blocks (MSB)
	.byte	^x20		;        "
	.byte	^x40		;        "         (LSB)
	.byte	0		; reserved
	.byte	0		; block length (MSB)
	.byte	2		;       "
	.byte	0		;       "      (LSB)

;
; Contents of page 25h
;
	.byte	^x25		; page code
	.byte	^X17		; length
	.byte	0		; bit 0 means spin up disable
	.byte	0[22]		; remaining 22 bytes reserved

ms_data_len = .-ms_data

;
; SCSI descriptors for GKDRIVER IO$_DIAGNOSE functions
;
ms_desc:
	.long		1		; opcode - pass-through
	.long		0		; flags
	.address	ms_cmd		; address of command buffer
	.long		ms_cmd_len	; length of SCSI command
	.address	ms_data		; address of data buffer
	.long		ms_data_len	; length of data buffer
	.long		0		; SCSI pad length
	.long		0		; phase change timeout
	.long		0		; disconnect timeout
	.long		0[6]		; reserved

ms_desc_len = .-ms_desc


tur_cmd:
	.byte	0		; opcode - TEST UNIT READY
	.byte	0		; LUN and reserved
	.byte	0		; reserved
	.byte	0		; reserved
	.byte	0		; reserved
	.byte	0		; control byte

tur_cmd_len = .-tur_cmd

tur_desc:
	.long		1		; opcode - pass-through
	.long		0		; flags
	.address	tur_cmd		; address of command buffer
	.long		tur_cmd_len	; length of SCSI command
	.long		0		; address of data
	.long		0		; length of data buffer
	.long		0		; SCSI pad length
	.long		0		; phase change timeout
	.long		0		; disconnect timeout
	.long		0[6]		; reserved

tur_desc_len = .-tur_desc

ssu_cmd:
	.byte	^x1b		; opcode - START_STOP_UNIT
	.byte	0		; 1 - return immed, 0 return after spin up
	.byte	0		; reserved
	.byte	0		; reserved
	.byte	1		; 0 - stop unit, 1 start unit
	.byte	0		; control byte

ssu_cmd_len = .-ssu_cmd

ssu_desc:
	.long		1		; opcode - pass-through
	.long		0		; flags
	.address	ssu_cmd		; address of command buffer
	.long		ssu_cmd_len	; length of SCSI command
	.long		0		; address of data buffer
	.long		0		; length of data buffer
	.long		0		; SCSI pad length
	.long		0		; phase change timeout
	.long		0		; disconnect timeout
	.long		0[6]		; reserved

ssu_desc_len = .-ssu_desc

devnam:	.ascid	/GKB100/		; SCSI unit 1 on second SCSI bus

chan:	.blkw	1		; channel number
iosb:	.blkw	4		; I/O status block

 

	.SUBTITLE Main routine
 
;++
; FUNCTIONAL DESCRIPTION:
; 
;	 [~tbs~]
; 
; CALLING SEQUENCE:
; 
;	 [~tbs~]
; 
; INPUT PARAMETERS:
; 
;	 [~tbs~]
; 
; IMPLICIT INPUTS:
; 
;	 [~tbs~]
; 
; OUTPUT PARAMETERS:
; 
;	 [~tbs~]
; 
; IMPLICIT OUTPUTS:
; 
;	 [~tbs~]
; 
; COMPLETION CODES:
; 
;	 [~tbs~]
; 
; SIDE EFFECTS:
; 
;	 [~tbs~]
; 
;--
;
	.ENTRY	spe,0
	$assign_s -
		devnam = devnam, -
		chan   = chan
	blbs	r0,1$				; go on if no error
	pushl	r0
	calls	#1,g^lib$signal			; otherwise, signal the error

1$:
	$qiow_s -				; issue the SCSI command
		chan   = chan, -
		efn    = #1, -
		func   = #IO$_DIAGNOSE, -
		iosb   = iosb, -
		p1     = tur_desc, -
		p2     = #tur_desc_len
	blbs	r0,2$				; go on if no error
	pushl	r0
	calls	#1,g^lib$signal			; otherwise, signal error
2$:	blbs	iosb,3$				; check the IOSB
	movzwl	iosb,-(sp)
	calls	#1,g^lib$signal			; signal any IOSB errors
3$:

	$qiow_s -				; issue the SCSI command
		chan   = chan, -
		efn    = #1, -
		func   = #IO$_DIAGNOSE, -
		iosb   = iosb, -
		p1     = tur_desc, -
		p2     = #tur_desc_len
	blbs	r0,4$				; go on if no error
	pushl	r0
	calls	#1,g^lib$signal			; otherwise, signal error
4$:	blbs	iosb,5$				; check the IOSB
	movzwl	iosb,-(sp)
	calls	#1,g^lib$signal			; signal any IOSB errors
5$:
	$qiow_s -				; issue the SCSI command
		chan   = chan, -
		efn    = #1, -
		func   = #IO$_DIAGNOSE, -
		iosb   = iosb, -
		p1     = ssu_desc, -
		p2     = #ssu_desc_len
	blbs	r0,6$				; go on if no error
	pushl	r0
	calls	#1,g^lib$signal			; otherwise, signal error
6$:	blbs	iosb,7$				; check the IOSB
	movzwl	iosb,-(sp)
	calls	#1,g^lib$signal			; signal any IOSB errors
7$:

	$qiow_s -				; issue the SCSI command
		chan   = chan, -
		efn    = #1, -
		func   = #IO$_DIAGNOSE, -
		iosb   = iosb, -
		p1     = tur_desc, -
		p2     = #tur_desc_len
	blbs	r0,8$				; go on if no error
	pushl	r0
	calls	#1,g^lib$signal			; otherwise, signal error
8$:	blbs	iosb,9$				; check the IOSB
	movzwl	iosb,-(sp)
	calls	#1,g^lib$signal			; signal any IOSB errors
9$:

	$qiow_s -				; issue the SCSI command
		chan   = chan, -
		efn    = #1, -
		func   = #IO$_DIAGNOSE, -
		iosb   = iosb, -
		p1     = ms_desc, -
		p2     = #ms_desc_len
	blbs	r0,10$				; go on if no error
	pushl	r0
	calls	#1,g^lib$signal			; otherwise, signal error
10$:	blbs	iosb,11$			; check the IOSB
	movzwl	iosb,-(sp)
	calls	#1,g^lib$signal			; signal any IOSB errors
11$:

	movzbl	iosb+7,r0
	$exit_s -
		code   = r0
	.END	spe
    

Todd, thanks for posting your program. It worked for me like a charm. yeh!

Anyone know if there is a provision for a drive active LED on the RZ22?

Also, anyone know what the configuration is for the drive select jumpers?

Inquiring mind wants to know.

Frank

    I assume you mean the SCSI bus address jumpers?  For the RZ23 its:
    
    +-------------------------------------------------+
    | | 50 pin SCSI connector  |     | power |        |
    | +------------------------+     +-------+        |
    |                                                 |
    |                                                 |
    |                                                 |
    |                                                 |
    |                                                 |
    |   E E E    <- These are the jumbers             |
    |   1 2 3                                         |
    |                                                 |
    |                                                 |
    
    
    E E E   | SCSI Bus
    3 2 1   | Address
    ------------------
    O O O	0		O = Open
    O O S	1		S = Shorted
    O S O	2
    O S S	3
    S O O	4
    S O S	5
    S S O	6
    S S S	7
    
    -tl
    
    PS  This is by experimentation.  So I may have made a mistake.  Also,
    	if you used the previous program on the RZ22, you probably should
    	have changed the Number of Blocks field to the appropriate number
    	for the RZ22.

    
re .-1. That looks right.

Now for the LED, look at the other end (front of the drive) 



    +-------------------------------------------------+
    | | 14 pin conn. |  |            | HDA CABLE |    |
    | +--------------+  |            +-----------+    |
    +------------------/
    |
    |




			...PCB...




    |       | power |     |     SCSI connector     |   |
    +--------------------------------------------------+  





That 14 pin looks like this (connector facing you, PCB down):

		top of drive
      +-------------------------------+
      |                               |
      | O             O               |
      | +---------+                   |
      | | .:::: : |                   |
      +-------------------------------+
 	  ^^^^^^^       PCB
          |    ||
single    |    ||
 pin -----+    |+-------- LED connector polarity    -
               |                                    +
No pins -------+


NOTE. The polarity of the LED is (I believe) like shown above. If it doesn't
work that way, flip it around! (Won't  hurt the LED)

NOTE. This is only valid for older RZ22/23 drives. The way you can tell
is that the drive doesn't have a plastic shroud around the 50 pin SCSI 
connector.


John

Thanks for the help guys! Now, is that number of blocks parameter that I didn't
change for the RZ22 going to cause me any grief? Is so, what do I need to change
it too?

Thanks much again for the help. These notes files are priceless!

Frank

Well, I hooked up the RZ22 this past weekend but ran into a problem. Upon
formating, FORMAT got to cylinder 460 then hung. Eventually, the drive even
spun down! Its been my experience that FORMAT (being rather dumb) does not
handle bad blocks well, and if it runs into once hangs. So, I am assuming
that I have a bad block (or more) around cylinder 460. However, I thought
that SCSI was supposed to hide such things from you. Is this a correct
assumption?

Also, does it matter with a scsi drive how many heads you say the drive has?
I didn't know what to specify for the RZ22, so I just said 8 heads, and
after some experimentation, 753 cylinders. Do these numbers make any sense?

Could I have messed something up in not changing the number of blocks
numbers on the spin up program I ran on the drive (see last reply).

Thanks for any help ya'll can give me.
Frank

Well, first SCSI kinda hides bad blocks. It maps them out during format
(Real SCSI format, not AmigaDOS) and some optionally map them 
during run time. But you have to enable this feature (automatic reallocation
on read/write error).

> Also, does it matter with a scsi drive how many heads you say the drive has?
> I didn't know what to specify for the RZ22, so I just said 8 heads, and
> after some experimentation, 753 cylinders. Do these numbers make any sense?

Well, not really - IF! If the number of total blocks on the drive equals
the geometry you give the program:


	total_blocks = heads*cylinders*sectors

RZ22:

	102432 = 4*776*33

I suspect the geometry you gave it (8*753*?sectors?) was too large for the
drive. At cyl 460 (which is really block 460*8*?sectors? was actually at the 
end of the disk).

For the geom you gave it, you would have had to specify:

	102432/(753*8) = 17 = #sectors. 

Any more sectors than that and boom.

John

Thanks for the info John. I did use 17 for the number of sectors. (Forgive
my ignorance when it comes to disk drives) If I started the format at say,
cylender 462, it continued fine up to cylinder 753. This is what makes me
think that the drive has a bad block around 460 and FORMAT is getting hung
when it runs into it. Perhaps I need to do a new low level format?

Frank

John, is there some sort of SCSI command that tells the drive to go format
itself? As I stated in my last reply, it seems that the drive has developed
a bad block that is not marked as bad, and therefore AmigaDOS format hangs
when it encounters it. If there is such a command, then perhaps I can hack
it into the program that toggles the spin up bit.

I'm SO close to getting this thing to work. Notes file don't fail me now.

Thanks in advance,
Frank

Sure is. It's a bit more complicated in it's entirety, but as a first pass,
try this. (I'm leaving out the entire data phase which allows you
to pass a bad block list to the drive. Hopefully a basic format will find the
one your having trouble with (and any others) and map it out...)

SCSI FORMAT:

byte	value	description
----	-----	-----------
0	04	opcode
1	00	bunch of stuff. Most important means NO DEFECT LIST SENT
2	00	rsvd (in the SCSI tradition)
3	00	Interleave MSB
4	00	Interleave LSB
5	00	Control byte


Bytes 3 and 4 determine interleave. Set it to 0 for default 1:1. NOTE
that for SCSI drives, it is BEST to use the drives default. This means
the drive (who knows best) will be most efficient. Changing interleave
on ST-506 drives can provide performance enhancements since your basically
matching controller/system speed to the disk access. SCSI does this itself.


John

Thanks John, I'll see if I can give it a try. If I can just get the bad blocks
all accounted for, I should be able to get this drive up on Amy.

Thanks again,
Frank

    
    	The GVP software includes a program that will format and check
    for bad blocks. I is in the GVPscripts directory and is called
    some like GVPscsiformat. This program formats the disk then does a
    bad block scan and revector. Then GVPprepHD and Amiga format.
    
    		Steve Peters
    

Re: .30

>NOTE
>that for SCSI drives, it is BEST to use the drives default. This means
>the drive (who knows best) will be most efficient. Changing interleave
>on ST-506 drives can provide performance enhancements since your basically
>matching controller/system speed to the disk access. SCSI does this itself.

Interleave can make just as big a difference on SCSI disks as ST-506
disks depending on the disk's smarts, or lack thereof.  I believe
SCSI disks, like QUANTUMS, that have built-in track buffers are
interleave independent (the QUANTUM even ignores attempts to change
interleave).  However, I know from personal experience that SCSI disks
without track buffers are as interleave dependent as any ST-506 disk.

re: .30

John, I tried doing a format with the data you gave back in .30 and it didn't
seem to do much. The drive played with itself for about 10 seconds then the
format function returned. This sounds like some of what was seen in trying
to hard format a drive on the amiga (see note 2218...).

I tried doing an ANALYZE/MEDIA/EXERCISE from VMS on the drive and it ran
for awhile then returned a fatal drive error. I would assume that it ran
into the same bad section that Amiga format did.

Any ideas on how to get the drive to REALLY format itself and find any new
bad blocks?

Frank

Yeh, that's right - RZ22/23 are embedded servo and a strait format just
reshuffles the defect maps without doing a media scan.

What version of microcode is on the board (little square ROM next to the
ID jumpers with a label on it)?  Very early versions of the code would do the
"quick" format. They later changed it for us to do a media certification.

The only way to get bad blocks mapped out is to find them yourself and then
reassign them. Something to the effect of:



	write LBN x
	read  LBN x (and compare if you want to take a long time!)

	Do this for, say, 10 passes over the entire disk sequentially. As you
	get errors (soft or hard - i.e. in SCSI terms a sense key of
	"recovered error" or "medium error") record the LBN. You can skip
	the write part to speed things up.

	Once above media scan is complete, pass the list of LBN's to drive
	with a REASSIGN_BLOCKS command.

These commands (reassign blocks and it's defect list's) are too much for me
to type. Send me mail and I'll get you a spec.

John

    
    The program in .20 and .21 work fine under VMS V5.3-1, except:
    
    	- you do NOT need to set the VMSD1 parameters.
    	- the program generates an error message, like "device not found"
    	- but it works!
    
    Verify in your VAXstation by powering down, disconnecting the sCSI
    cable from the RZ and then repower - and see/hear if the drive
    spins up.
    
    Just did this and it works like a charm.
    
    Thanks to WJG::GUINEAU and to my neighbor Todd Little for their
    help!
    
    Lou
    

    I got the program in .20 and .21 to work under VMS 5.4, but I changed 
    the new parameter SCSI_NOAUTO instead of VMSD1 for step 2. 
    SCSI_NOAUTO replaces the old VMSD1 parameter for VMS 5.4.  I tried to
    skip the VMSD1 step as outlined in .36, but couldn't get the GK device
    to come on line with the generic SCSI driver, since it was already 
    configured with the RZ driver.    

    Jim Maddox

Hi,

I need some help getting an RZ23 to work with a GVP controller.  I've read all
the replies to this note and 3183 but don't see anything related to my problem.

Heres some background:

For starters I have have a stock A2000, 1.3 roms, no other boards installed.

The RZ23 has been modified to spin-up on power-on.  The SCSI ID jumpers have
all been removed so the drive has an ID of zero.  Terminators have been added
to the drive to terminate the SCSI bus.  The drive worked fine here at work.
I'm mounting the drive internally next to my floppy.

The controller has the autoboot roms but no extra memory installed (J1, J2,
J4 connected, J3 empty).

After reading the pertenent portions of the GVP manaul, installing everything,
and powering on, I was very dissappointed that my system wouldn't boot.
The Amiga screen does it's normal color changes and ends up white.  Normally
it's white for a very short period before it asks me for the V1.3 WB disk.
This time it was white for minutes.  I assumed something was wrong.  Tried
re-seating the board, scsi connectors, etc.  Nothing helped.

I think I goofed up and put the scsi connector on upside down once.
(this is supposedly very bad, but it was 1:00 in the morning and I was 
extreemly frustrated).  Red line is pin one, right?  Pin one on a RZ23 is
next to the power connector, right? (he says hopefully).

I'm not sure what I did but after a while it started asking for the WB disk
after about a minute of being powered on.  I gave it the GVP installation disk
and continued following the manual.  The next step was to use GVP's
installation utility.  It asks me a couple easy questions:  GVP controller
installed?  Check.  SCSI drive installed w/ ID 0?  Check.   Installation
will erase the disk, OK?  Check.  After this final question the installation
procedure quickly bombs saying (not verbatim):

*** ERROR: cannot access HDD with SCSI ID=0.  Installation aborted.

Has anyone seen this before?

Anyone see something I've done wrong?

Any help would be greatly appreciated.

Thanks,

..Dan

P.S. As a bonus question: reply 24 to this note explains how to get the hard
disk LED working with a RZ23 but says it only applies to *old* RZ23's (the
note was written in September of 89).  Is the information still valid?  If
not, can it still be done (and how)?

I was poking around the GVP installation disk and in the gvpscripts directory
there was a program called tstGVPscsi (or something like that).  When I ran
that it simply returned.  No error, no nothing.  Would this be testing the
controller or the drive?

The sformat utility hangs.  I looked at the source (in the same directory) and
it has a while loop that won't exit until the drive responds.  This is why
it hangs.

..Dan

    This may sound simple(stupid) but did you format(Prep) the drive before
    you tried the installation?   I have a GVP controller with the
    Faaastprep software.  When I installed my drive I started the Format
    program which gave me a choice of auto-formatting(I forget what they
    call this, but you just have to choose the size and names of your
    partitions and the software does the rest) or manual installation.  I
    chose manual installation, set my Cyl/Sec/Heads etc, partition
    sizes and names, then formatted the drive.  After formatting I wrote
    the RDB(rigid block structure) and AmigaDOS formatted the drive.(The
    ADOS format allows you to install software on the partition being
    formatted).  After the above I booted from the newly installed drive.
    
    Did you perform the automatic installation?  Are you using FaaastPrep
    or the previous version of GVP software?
    
    m
    

    Is there a jumper on your controller to disable autobooting?  I know
    the instructions for my HardFrame were very clear about disabling the
    autoboot feature until *after* you 'prep' the drive.  The RDB gets read
    *before* booting the floppy, because part of the information stored in
    the RDB (on the hard drive) determines boot priority.  (You could set
    the HD to boot regardless of whether there's a boot floppy in the
    drive.)

     The version of installation software Dan has, is an older version that
    came with the "GVP Impact" series of controllers.
     It did not require disableing the autoboot when formating or
    installing the drive.
     I succesfully used this same controler on a SCSI 80 meg unit.
             
    								Ed
    							

Hi,

Thanks for the replies.

RE: .40, M. Davis:

No question is too stupid for this HW neophyte. :-)

I did not run Prep.  I'm not sure I have to if I'm doing an automatic
installation.    I'll check the manual again and look on the disk for Prep.
One of the things I did try is "sformat" but I just seemed to hang there.
I didn't see FaaastPrep anywhere on the disk (as Ed mentioned, this is an
older GVP installation disk).  I'll check again though.

RE: .41, D. Moore:

Yes, One of the things I tried was to disable AutoBoot.  GVP's installation
procedure noted that AutoBoot was disabled and then died exactly the same way
it did with the autoboot jumper in.

This RDB stuff sounds interesting.  I'm assuming the GVP installation procedure
writes this informatin for me. (Ed, do you remember having to do anything
special w/ your 80 meg drive?).

Perhaps the reason it's taking so long to start booting is it's looking for
this RDB stuff on the drive (A wild guess).

Thanks again.  I'll reply with more info after trying your suggestions.

..Dan

    When I had a Supra controller on my A500 it took a loooong time before
    the amiga started the boot.  It would sit at the grey screen.  I never
    took the time to figure out what the hardware was doing but once I
    installed the software(and autoboot stuff) on the drive the wait time
    was shortened considerably.  If you can, try formatting and installing
    your drive on another system then plug it into yours and see if it
    boots.  At least you can isolate whether it is the drive or your
    SCSI/System.
    I've plugged in the 50-pin SCSI cable backwards on numerous occasions with
    no ill effects except dread and visions of wasted $$$$$.  It is
    suggested that you check and double check, and check and double
    check...before powering up the hardware, though.
    
    md
    

    Some SCSI drives have a small fuse that can blow if the SCSI 50 pin
    cable is plugged in backwards.  If this fuse goes you can have problems
    seeing the drives on the BUS.  Other SCSI devices such as the ADAPTEC
    4000A and 4070 do not have the fuse and after correcting the cable
    problem I did not have any lasting ill effects.  The fuse if present
    should be around the connector and will look like a resistor with out
    color bands.
    

� P.S. As a bonus question: reply 24 to this note explains how to get the hard
� disk LED working with a RZ23 but says it only applies to *old* RZ23's (the
� note was written in September of 89).  Is the information still valid?

    That info is still correct. The newer drives (with the shroud around
    the 50 pin header) still have the LED pins the same as the old ones.

    BTW, if memory serves, the RZ23 does have a fuse (little green pico
    fuse as -.1 mentions).

    Pete

Thanks for the info.

Will it be visably apparent that the fuse has blown?

I hooked up the LED and I found that it comes on when I boot in a flashing
manor; one flash per second for about 30 seconds until the floppy kicks in.

I took a look at the script that does the installation and found that it 
runs the tstGVPscsi program mentioned earlier.  It runs it twice in fact
and each time it runs it the HD LED comes on breifly.
After the first run there's a IF FAIL statement.  When this branch is taken
it reports that the AUTOBOOT eproms are not installed and continues.  This
branch is not taken unless I remove the autoboot jumper.

It then runs it again and follows it up with a IF ERROR statement.  This
branch is taken and this is where it ECHOs "---ERROR: cannot access HDD
with SCSI ID=0.  Installation aborted."

When I run tstGVPscsi interactively and follow it with the "WHY" command I
get: "Last command failed because of: Error -1".

I hope to try replacing the SCSI cable today (I'm on vacation after that
so I won't be able to try anything else for a while after that).

Thanks again,

..Dan

    Some of the earlier replies in this Subject, say that some of the RZ's
     don't spin up on powerup. There is a jumper on my drive to enable or
  disable ( it's enabled on mine)  this, this might be a problem on your's.
     Might be worth checking out...
    							Ed
    

    The fuse can only be checked with a Multimeter.  There is no visible
    change on the outside. 
    

    I have a second Conner drive. It is NOT a DEC drive but it is identical
    in every way except for one thing.  The LED won't work.  I've even used
    the LED from my other drive (RZ23) where it works quite well.
    
    This drive (which works fine BTW), has labels slightly different from
    the RZ23.  On the front a label reads "Config NCB-01" where the RZ23
    reads "Config DEC-21".   On the side a label reads "CP-3100" where the
    DEC drive says "3100D"  Of course some of the jumpers (other than the
    unit select) are configured differently but the drive works great.
    
    Anyone have any ideas?   For me it's a bit uncomfortable not having any
    sort of drive activity indicator.
    
    Thanks 
    		-Bruce

>      <<< Note 2877.50 by RLAV::WEGER "NJCD SWS, Piscataway NJ. 323-4468" >>>
>                               -< My LED is DED. >-
> 
>     I have a second Conner drive. It is NOT a DEC drive but it is identical
>     in every way except for one thing.  The LED won't work.  I've even used
>     the LED from my other drive (RZ23) where it works quite well.
>     
>     unit select) are configured differently but the drive works great.
>     
>     Anyone have any ideas?   For me it's a bit uncomfortable not having any
>     sort of drive activity indicator.
>     
>     Thanks 
>     		-Bruce
> 

One of the released versions of the RZ22/23 microcode only lit the LED while 
it was disconnected from the SCSI bus.

john

RE: .40 - .49

Well the problem seems to be solved and it appears there really was no problem
except for my lack of patience.

When I installed the controller/drive for the first time I had no idea I it
would take 40 seconds for it to start booting and never gave it enough time
before shutting it off and trying to tweek something.  In my frustration I
took the drive to work and put it in a DS3100 and ran some diagnostics on it
(which all went fine).  I decided to make sure the spin up on power-on was set
and apparently reset it (my system manager had set it correctly for me but I
was willing to try anything).

Naturally it didn't work at all after this.  In an attempt to localize the
problem I first replaced the SCSI cable and then I bought a new controller!
With the new GVP series II HC in I heard the drive spin up after the machine
booted and I said "Oh shit!".

The new GVP FaaastPrep SW is excelent.  The drive was partitioned, formatted,
and ready to go in just a few minutes.

Wanting to verify that it was in fact my lack of patience I borrowed a 20 meg
miniscribe drive, pulled my new controller out, put the old one in, hooked up
the minescribe, and low and behold the darn thing worked like a charm.

Well now I have an extra controller that will soon be showing up in note 8
real soon. :-)

..Dan