Conference hydra::amiga_v1

> I would like to connect a rz23 disk to an A2092 controller.

I think you mean A2090 - The Commodore board?

The RZ23 should work fine with the A2090, however you'll need to be able to set
it to spin up on power up. This can only be done via a SCSI command.

Look for other notes in this conference on how to do this. If you have a
VS3100 system nearby there is a program in here to do this for you.

John

re :.1


Isn't Commodore coming out with a new controller wich name should be A2092 ?
I already know the A2090 and A2090a but I think there is a new one already.

>If you have a VS3100 system nearby there is a program 
>in here to do this for you.

What is the name of this program and where is it located ?
Thanks for your prompt response
Phil

    The new Commodore controller is the A2091.  It is a SCSI-only
    controller: no ST506 ports.
        John Sauter

             <<< BOMBE::DISK_NOTES$LIBRARY:[000000]AMIGA.NOTE;1 >>>
                                -< AMIGA NOTES >-
================================================================================
Note 2877.21                   RZ22/23 WITH G.V.P.                      21 of 35
RLAV::LITTLE "Todd Little, NYA SWS, 323-4475"       266 lines  16-SEP-1989 21:42
                                  -< SPE.MAR >-
--------------------------------------------------------------------------------
	.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
    

re :.3, .4

Merci

Phil

What are the characteristics of the rz23 drive ?
Number of heads, cyl, etc....

Phil

    It shouldn't matter as long as you get the proper number of blocks, but
    I think 4 heads, 26 sectors, and 1968 cylinders sounds about right.
    
    -tl

>    I think 4 heads, 26 sectors, and 1968 cylinders sounds about right.

8 heads, 33 sectors, 776 cylinders (= 204864 blocks)

John (on vacation this week)

    That's what I get for making an assumption that it was like Conner's
    other drives that the Cltd software already knew about.  I'm sure
    John's answer is the final word!
    
    -tl

If CLTD uses that geometry for *any* conner drive, I'm sure it's wrong (well, 
not wrong, just not exactly correct. As long as  H*C*S <= Blocks you're ok). I
don't know of ANY 3.5" drive with 1600+ cylinders! Only the latest 600MB and
1.2GB+ 5.25" drives have that many cylinders. Most 3.5's are under 1100 or
1200.

It's a direct result of a physical technology limitation called Tracks Per Inch
(TPI). With a 3.5" platter (of which only about 3/4" of the outer radius are 
actually used for data) you just can't get that many cylinders!

John

    I extrapolated the numbers from other conners drives and assumed you
    couldn't get that many heads in such a small package so I just
    increased the number of cylinders to match the capacity.  And we all
    know what happens when you assume.
    
    -tl

    I only could read questions about the problems connecting a RZ23 to the
    Amiga. Does anybody have now any experience with this configuration?
    Does it work without problems?
    What would be the best controller to connect a RZ23 to an Amiga 500 ?
    
    Thanx in advance, Stefan��

    Worked fine for me with a C-Ltd. SCSI-500 controller.  I would assume
    that the KRONOS-500 would also handle it.  But with C-Ltd.'s future in
    question, you might want to consider another controller if someone else
    has gotten it to work.
    
    -tl
    

    Hi Todd,
    
    I'm not very familiar with SCSI drives and controllers for the Amiga
    and therefore I will by what works. And what I can get for a reasonable
    price ;-)
    What are the differences between the two you described?
    And what do you mean with "But with C-Ltd.'s future in question...."?
    
    Stefan��

    Hi Stefan,
    
    Cltd. is out of business, not an unfamiliar state for this company.
    
    You should have no problems connecting it to an A590 controller
    from Commodore.
    
    Call me at 069-66721029 on Monday afternoon, if you have more
    questions...
    
    Regards,
    
    <CB>

Re: .15

>    Cltd. is out of business, not an unfamiliar state for this company.

Shouldn't that be C Ltd might be out of business.  It's not official
yet, is it?

    Re: .16
    
    Well, tell that to my distributor. While it's not official and a
    follow-up company or a pontential buyer are pretty probable, I'd
    say that you can kiss CLtd. as a company good bye.
    
    Regards,                                
    
    <CB>

Well problems are coming.

the drive seems not to be seen from the controller and I have questions:

1.- some replies before, you draw the jumpers for the scsi number
	what are the other jumpers for ?

2.- In the scsi 50 pin connector, where is pin 1 ?

3.- I was not able to load the generic scsi driver from VMS V5.3 and I had to
	run the programm on the online device seen by VMS.Now the disk spins up
	at power up ok. Can this have an importance ?

Any good answers welcomed .
Phil

    re -.1
    
    (2.)  Pin 1 of the SCSI connector is on the side of the connector
    closest to the power connector.
    
    
    John G. was kind enough to set (reset?) the power mumble bit on
    my RZ's. After that, I tried to format the drives on a CLTD Kronos
    controller and on a Hardframe.  Neither controller would/could
    format the drive, although the CLtd Inquire command recognized the
    drive and reported it as an RZ23 (DEC) drive.  When put on the
    Hardframe, it locked the bus and wouldn't allow the system to boot.
    
    Just for drill, I put the drive back on the CLtd controller, didn't
    bother to low level format, and proceeded to AmigaDOS format the
    drive.  It worked!  You tell me how!???  I have had the drives on-line
    for test and have been beating them quite heavily... no problems.
    
    It would be nice to hear from people who have sucessfully gotten
    the RZ23 up on the Amiga, Controller used, mountlist, and a detailed
    step by step on how they did it.  I'm confused as to why the Hardframe
    won't talk to the drive, since this was the controller I would have
    preferred to put it on, although I am getting decent performance
    on the Kronos/RZ23 combo (500k+).
    
    
    My Mountlist entries look like  (for CLtd controller)
    
    DH0a:      Device = CLtd.device
               Unit   = 1110  ;  Flags = 0  ;  Surfaces = 8
               BlocksPerTrack = 33
               Reserved = 2   ;  Interleave = 1
               LowCyl = 1     ;  HighCyl = 387
               Buffers = 32   ;  BufMemType = 1
               GlobVec = -1   ;  FileSystem = l:FastFileSystem
               DosType = 0x444F5301
               Stacksize = 4000
               Mount = 1
               #
    DH1a:      Device = CLtd.device
               Unit   = 1110  ;  Flags = 0  ;  Surfaces = 8
               BlocksPerTrack = 33
               Reserved = 2   ;  Interleave = 1
               LowCyl = 388   ;  HighCyl = 775
               Buffers = 32   ;  BufMemType = 1
               GlobVec = -1   ;  FileSystem = l:FastFileSystem
               DosType = 0x444F5301
               Stacksize = 4000
               Mount = 1
               #
    
    
    
    John
    

Usually you don't need to "low level" format a SCSI drive. Unless it gets
messed up, it's already formatted (forget the detailed explination for now)

On drives with embedded servo, (like RZ22/23) format does nothing more
than read/write the pack and twiddle the defect maps.

So skip the low level format if you can.


re. Hardframe.

I haven't seen anyone get the RZ23 working with the hardframe yet (3 people
so far). I suspect it's because the RZ22 and RZ23 (in fact all DEC SCSI
products) return a DEC specific "name" for the product id returned by the
SCSI inquiry command. RZ23 calls itself "RZ23" instead  of "CP3100" which
is Conner Peripherals product name for the RZ23 type drives they sell. DEC
makes the vendors change the product name.

So why the trouble? Because many microcode writers wil actually look for 
one of a specific set of product names (CP3100, Q105S etc). If they don't
find a "name they can trust", they don't work.

I'm not saying this is why hardframe and RZ23 don't work together, but it
might be. Then again it might be some peice of SCSI the hardframe expects
a device to implement that the RZ23 doesn't (I have no idea what that could
be - RZ23 is a pretty complete SCSI-I/CCS implementation)

In addition, Microbotics (hardframe manufacturer) claims that the Conner CP3100
works just fine. This is why I suspect it's the "I'm an RZ23" stuff in inquiry
that's causing trouble.


Now if someone want's to bring in their Amiga and hardframe, I'm sure I can
figure out exactly what the problem is (I need the SCSI analysis system in my
office).

Any takers?

John

�    Call me at 069-66721029 on Monday afternoon, if you have more
�    questions...
�    
�    Regards,
�    
�    <CB>
 
    Read it on Wednesday the first time, sorry.
    I'll try it this week.
    
    Thanks, Stefan��

    Re .3/.4?
    
    If you enable the spin up bit, will this survive power downs etc?
    IE, can I enable spin up on a disk by connecting it to a VAX, and
    then remove the drive and attach it to something else?
    
    Jon.
    

Yes - if you set the SP (Save Parameters) bit in the MODE_SELECT command.

john

Just for the record, over the last weekend, I convinced an RZ23 to talk to a
trumpcard, and everything seems to be working just fine.

The notes on spinup were just what the doctor ordered. That was the one thing
that didn't work "out of the box", as it were. Better yet, the trumpcard
uses an ASCII file with drive identifications followed by command names &
strings. We told the trumpcard that the appropriate magic string was the
"park" command, and then parked the drive.

We couldn't convice the drive to work with a hardframe, though. Anyone managed
that?

Along the same lines, it would be nice to have list of DEC drives, and which
controllers they worked with, possibly followed by notes on what has to happen
to make them work.

	<mike

RE:.24

>   We couldn't convice the drive to work with a hardframe, though.

    There  are  four  sets  of jumpers on the drive bottom. Three are
used  for  address  selection,   and   the   last   is   for   parity
enable/disable. If the last jumper is open, the drive expects parity.
It  is  not  clear if the hardframe generates parity by default. I am
pretty sure it is capable of it, though. Anyway, try disabling parity
(jumper installed) and trying it on a hardframe.

	-SES

> pretty sure it is capable of it, though. Anyway, try disabling parity
> (jumper installed) and trying it on a hardframe.

I doubt that will work. On the SCSI bus, noone knows if anyone's checking 
parity (except the one checking it) unless someone complions about
a parity error. 

I suspect the problem is a protocol error of some sort. There are enough
places in SCSI for two parties to disagree.  I would venture to say it's
due to the fact that the RZ23 calles itself an "RZ23" in the INQUIRY command
and the Hardframe checks this field for drives it "knows how to handle" -
and RZ23 is doubtfully in it's list :-)

It's either that or a command the which Hardframe uses is either different
in implementation (and returns an error) or is just not implemented.

john

re:.26

John,

    I  have  followed  your SCSI comments with great interest in this
conference, but I think you may not have read what I meant...

>   I  doubt that will work. On the SCSI bus, noone knows if anyone's
>   checking  parity  (except  the  one  checking  it) unless someone
>   complions about a parity error.

    Exactly! And who would an RZ23 complain to? How would it complain
if  there was a parity error in any message? I could not find that in
any RZ23 specs I've seen. What I am saying is I suspect the  RZ23  is
looking  for  correct  parity and the HardFrame may not be generating
it.

>   I suspect the problem is a protocol error of some sort.

    What I am suggesting above does not rule this out. But the parity
possibility  is  easy  to  check,  and  if  it is not the problem, to
eliminate.

>   I  would venture to say it's due to the fact that the RZ23 calles
>   itself  an "RZ23" in the INQUIRY command and the Hardframe checks
>   this  field  for  drives  it  "knows how to handle" - and RZ23 is
>   doubtfully in it's list :-)

    I really do not think this is true. I have been in touch with the
current  HardFrame  developer  and  have  some small insite to how it
works. It has no table of "known drives" but uses ANSI SCSI  commands
to  figure  out  what  a  drive  is  about. Afterall, it does support
adaptecs and will work with Omti's (though not  supported)  and  they
both are kinda adulterated SCSI implementations.

>   It's  either that or a command the which Hardframe uses is either
>   different in implementation (and returns an error) or is just not
>   implemented.

    I  seem  to  recall there are older versions of the HardFrame ROM
that do not work with older revisions of the Conner  drives...  Maybe
there  is  something  here. It may be worth a call to Microbotics, in
Richardson Texas, with information about  the  drive  (Conner  model,
etc.)  to ask them about this. I think the current release version of
the HardFrame ROM is 1.5C from 072789.
���

	-SES

>     Exactly! And who would an RZ23 complain to? How would it complain
> if  there was a parity error in any message? I could not find that in
> any RZ23 specs I've seen. What I am saying is I suspect the  RZ23  is
> looking  for  correct  parity and the HardFrame may not be generating
> it.

Hmm. Good Point. I didn't think of that and it may very well be the problem
(and if this is the case, it most certainly IS a problem :-) )

Definetly worth checking. (As Steve said) RZ23's come with parity enabled.
Insert the jumper to disable it (or better yet, make the Hardframe generate 
parity!) Now the trick is finding a micro jumper that the RZ23 uses!

john

    
    Has anyone configured a RZ23 to an A2091 yet?
    
    Roger
    

Here is something I pulled out of the MAC notesfile.


Mark
------------------------------------------------------------------------------





         <<< SSAG::DISK$ARCH2:[NOTES$LIBRARY]ASK_SSAG.NOTE;1 >>>
                    -< Ask the Storage Architecture Group >-
================================================================================
Note 429.24              SCSI Reselection phase and RZ23                24 of 24
JACOB::HOUSE "Kenny - MLO5-2/B6 - DTN 223-6720"      39 lines  21-MAR-1990 05:45
             -< PVAX ROMs know about spinning up drives (or not) >-
--------------------------------------------------------------------------------

    RE: setting and clearing the RZ22/23 DSP (disable spinup at power-on)
        bit...
    
    If you've got a PVAX with the SCSI-SCSI storage option, there's a
    sneaky trick in the ROMs that'll let you change the DSP (disable spinup
    at power-on) bit.  You need one of those MMJ loopback connectors that
    look like a red spoon;  that gets you into "field service" mode where
    you get to do dangerous things.
    
    Put the spoon in, and power on the unit.  At the console prompt, type
    "T 73" to start the Tape Key Utility.  Don't worry about the name,
    'cause it's only the magic inside this code we want to get.  Answer the
    questions about which port and which ID the drive is set for.  I can't
    remember whether the code allows you to specify a LUN (logical unit),
    but if the question comes up, answer that one too.  When the "RUsure"
    question comes up, answer "41000001" -- this is part of the strong magic
    I alluded to before.
    
    The code will do a MODE SENSE, then turn around and issue a MODE SELECT
    with the DSP bit clear.  Ultimately, the code will report an error, but
    don't worry:  it's complaining that the device isn't a tape (remember
    this used to be a tape key utility?).
    
    Take out the spoon and cycle power again to get out of field service
    mode.  No sense aggravating the gods by leaving too many privileges on.
    
    That should do it.  The drive should spin up at power on now.
    
    If you want to get things back the way they were, perform all the above
    steps but answer "42000001" to "RUsure."  That'll set the DSP bit.
    
    Having said all that...  The reason we didn't want the RZs spinning up
    at power-on was that the current surge of three drives spinning up
    simultaneously was too much for the PVAX power supply.  Software took
    it upon itself to bring these drives up one-at-a-time.
    
    Hope this helps,
    
    -- Kenny House
    
    re .-1
    
    Finally had a chance to try the above and it worked just fine!
    A couple of things to note. You do need the turn-around plug (H3103)
    and it must be plugged into the communications port when the system
    is powered on. If you don't have the plug in the right port you
    get an "Illegal Command" message when you try to run the required
    test.
    
    I turned on the system, typed "Show Device" and got the SCSI ID
    number for the RZ23 I was interested in; ran the test; inserted
    the SCSI number at the first prompt; typed in the "magic number"
    at the second prompt and was done. 
    
    The drive now spins up when the system is turned on. Every time...
    
    Many thanks to Kenny House for making this hack available.
    

/* SpinUp.c                                                John D. Bernard

This program will (should?) send the command stream necessary to clear the SPD
(Spinup Disable) bit in DEC RZ-xx drives.  I have been playing with a Hardframe
until I get a GVP or IDC on-line.  It looks like I am getting out to the bus,
since I can send simple commands (PARK/UNPARK  0x1b etc) to an ST225N on the
bus.  The drive led on an RZ23 will flicker when I run the spinup program, so
I'm probably getting to it.  By the way, this program does not work on CLtd
KRONOS controllers (no big surprise).

This utility will probably only work on some specific SCSI controllers like the
HardFrame?, 2090/2090A/2091 and GVP impact which supports the Commodore standard
SCSI-device command 28 that should allow direct access to the connected units.

Not being familiar with the details of programming SCSI, and being a novice at
    C,  could someone take a look at this and see if I'm on the right
    track?  As I said, I get the drive LED to flicker, but not much else.

With all the RZ22/23 drives available, I'm sure this program will be useful.  I
need to be able to enable power-on spin up since I have Amiga's at work, but do
not have access to a DEC workstation with SCSI.


This program is compiled under Lattice V5.05.



USAGE:

SpinUp 000 <Device>
        \\\   \
         \\\   \_ Device Driver  i.e.  HardFrame.device
          \\\                          harddisk.device  etc.
           \\\___ SCSI Unit
            \\
             \\__ LUN on SCSI Unit
              \
               \_ Controller or board #   0 if you only have a single 
                                          controller in your system or the
                                          controllers are of a different type
                                             
*/

#include	"exec/types.h"
#include	"exec/ports.h"
#include	"exec/libraries.h"
#include	"exec/io.h"
#include	"exec/tasks.h"
#include	"exec/memory.h"
#include	"exec/execbase.h"
#include	"devices/trackdisk.h"
#include	"libraries/dos.h"
#include	"libraries/dosextens.h"
#include	"devices/scsidisk.h"
#include	"stdio.h"
#include	"proto/dos.h"
#include	"proto/exec.h"



char DefaultName[] = "HardFrame.device";


char *DeviceName;



struct MsgPort IORP = {
	{0L, 0L, NT_MSGPORT, 0, 0L}, 0, SIGB_SINGLE, 0,
	{0, 0, 0, 0, 0}
};

struct IOStdReq IOR = {
	{ {0L, 0L, NT_MESSAGE, 0, 0L}, /* Message Succ, Pred, Type, Pri, Name */
	&IORP, 0 },			/* Message ReplyPort, Length */
	0, 0, 0, 0, 0,		/* IO Device, Unit, Command, Flags, Error */
	0L, 0L, 0L, 0L		/* IO Actual, Length, Data, Offset */
};


struct SCSICmd SC;

UBYTE SCCmd[50];



extern struct ExecBase *SysBase;


int
PromptedNumber(query, result)
char *query;
int result;
{
	char Data[81];

    printf(query, result);
    gets(Data);
    sscanf(Data, "%d", &result);
    return(result);
}

void
CleanUp(code, format, arg1, arg2)
int code;
char *format, *arg1, *arg2;
{
	printf("Done\n");
	if (code != 0) {
		printf(format, arg1, arg2);
	}
	if (IOR.io_Device != 0) {
		printf("CloseDevice\n");
		CloseDevice((struct IORequest *) &IOR);
	}
	exit(code);
}


int
main(argc, argv)
int argc;
char *argv[];
{
	struct Library *mbhf;
	int  unit, board, scsiID, scsiLUN;
	int result;

	printf( "	     RZ Drive Spin Up Utility\n");
	printf( "	           Version x.1\n\n" );
    
	unit = 0; /* For default. */
	if (( argc == 2 ) && ( argv[1][0] == '?' )) {
		printf( "usage: Spin up UNIT [Device Name]\n" );
		exit ( 0 ); /* No unit number given. */
		}

	if ( argc < 2 ) {
		unit = PromptedNumber("Enter unit to spin up [%ld]: ", unit);
	}
	else {
		result = stcd_i( argv[1], &unit );
	}


    /* Check for other than HardFrame.device specified */
   
	if ( argc > 2 )
		DeviceName = argv[2];
	else
		DeviceName = DefaultName;
        
	
	/* Find the name in the device list if it is there. */
    
	mbhf = (struct Library *)
		FindName(&SysBase->DeviceList, DeviceName);
	if (mbhf == 0) {
		CleanUp(20, "%s not found\n", DeviceName);
	}
	printf("%s release %ld.%ld\n", DeviceName,
		mbhf->lib_Version, mbhf->lib_Revision);


	/* finish IORP initialization */
    
	IORP.mp_SigTask = (struct Task *) FindTask(NULL);
	NewList(&IORP.mp_MsgList);

	board = unit/100;
	scsiLUN = (unit%100)/10;
	scsiID = unit%10;

	result = OpenDevice(DeviceName, unit, (struct IORequest *) &IOR, 0);
	if (result) 
        {
		CleanUp( 20, "%s will not Open. Likely %d is an invalid unit.",
				 DeviceName, unit );
		}

	printf( "Spinning Up   Controller # %d, SCSI UNIT %d, LUN %d.\n", board,
		 scsiID, scsiLUN );
         

    /**************************************************/
    /*  OK...  Here is where I'm lost...   HELP!!!!   */
    /**************************************************/

	SC.scsi_Data = NULL;
	SC.scsi_Length = 0;
    
    
	SC.scsi_Command = SCCmd;
	SC.scsi_CmdLength = 43;

    SC.scsi_Flags = 0;

    /**********  SCSI COMMAND BLOCK  *****************************/
    SCCmd[0]  = 0x15;	                /* MODE_SELECT opcode    */
    SCCmd[1]  = 1;                      /* Save Parameters       */
    SCCmd[2]  = 0;                      /* reserved              */
    SCCmd[3]  = 0;                      /* reserved              */
    SCCmd[4]  = 37;                     /* Parameter list length */
    SCCmd[5]  = 0;                      /* Control byte          */

    /**********  COMMAND DESCRIPTOR BLOCK  ***********************/

    SCCmd[6]  = 0;
    SCCmd[7]  = 0;
    SCCmd[8]  = 0;
    SCCmd[9]  = 8;
    
    SCCmd[10] = 0;
    SCCmd[11] = 3;
    SCCmd[12] = 0x20;
    SCCmd[13] = 0x40;
    SCCmd[14] = 0;
    SCCmd[15] = 0;
    SCCmd[16] = 2;
    SCCmd[17] = 0;
    
    SCCmd[18] = 0x25;                   /* Page code             */
    SCCmd[19] = 0x17;                   /* length                */
    SCCmd[20] = 0;                      /* 0=spin up on power up */
    SCCmd[21] = 0;
    SCCmd[22] = 0;
    SCCmd[23] = 0;
    SCCmd[24] = 0;
    SCCmd[25] = 0;
    SCCmd[26] = 0;
    SCCmd[27] = 0;
    SCCmd[28] = 0;
    SCCmd[29] = 0;
    SCCmd[30] = 0;
    SCCmd[31] = 0;
    SCCmd[32] = 0;
    SCCmd[33] = 0;
    SCCmd[34] = 0;
    SCCmd[35] = 0;
    SCCmd[36] = 0;
    SCCmd[37] = 0;
    SCCmd[38] = 0;
    SCCmd[39] = 0;
    SCCmd[40] = 0;
    SCCmd[41] = 0;
    SCCmd[42] = 0;

	IOR.io_Command = HD_SCSICMD;
	IOR.io_Length = sizeof(SC);
	IOR.io_Data = (APTR) &SC;

    if ((DoIO((struct IORequest *) &IOR) == 0) && (SC.scsi_Actual > 18)) 
        {
	    printf("IOE: %ld, Actual: %ld, %08lx\n",
			  IOR.io_Error, SC.scsi_Actual);
	    }
	CloseDevice((struct IORequest *) &IOR);
	IOR.io_Device = 0;
	CleanUp(0);

return(0);
}
    

The rzdisk command that shows up on DS3100's will let you set the disk
parameters interactively. If you can get an rz23 plugged into such a
system, that should solve the problem. Haven't tried it yet, though.

	<mike

    
I executed the "rzdisk -c ask" command on an RZ55 and saw several fields that
could be modified, but do not know which parameter needs to be tweaked to
enable spin-up on powerup.  The fields were:

	block descriptor
	error recovery parameters
	disconnect/reconnect parameters
	direct-access drive format parameters
	rigid disk geometry parameters

Since I have a PMAX to play with for a couple of days I thought I would
experiment with rzdisk.  Any ideas on what field(s) in what parameter list need
to be modified?

md
    

I've just been through a lot of this. Turns out there's a diode on the
termination power line that tends to die. Once dead, you get erratice
behavior (drive is sometimes not found, or doesn't terminate). This info is
from our local SCSI guru, who tests/designs SCSI hardware for DECStations,
and isn't contradicted by our experiences.

Because of these problems, we went through  our entire stock of rz23s, enabling
spinup on poweron, testing them, and tagging them. Those that didn't work
standalone in a Mac were had the bit turned back off, as they will still
function properly in a DECStation.

Run /etc/rzdisk -c ask /dev/rrz?c. Answer "yes" to the "ARE YOU SURE?" prompt.
You don't want to change anything but the last page, which is listed as
"Page 37 - DEC unique parameters:". For all pages before that, just hit
"n". For that one, hit "y". It then asks "Have drive spinup on power on (y/n)?".
You obviously answer "y" to that one. It finally asks "SAVE THE CHANGED VALUES
ON DISK (y/n)?" Another "y" to that one. It tells you it's changing the
parameters, and exits.

At this point, shut down the 3100, discconnect the SCSI cable (but not
power), and power the 3100 back up. You should be able to hear/feel the
rz23 spin up.

Note that if that diode is dead, the rz23 almost certainly won't work as a
single drive, can't terminate the bus, and may cause anything after it on the
bus to not be visible. The only way I've been able to get them to work
is with a good drive first on the bus with terminators, and the rz23 second
on the bus without. That's not supposed to work, and it doesn't work very
well. Slightly more reliable is to use a DEC internal SCSI cable, and terminate
that with the resistor pack you normally plug into the back of the pmax. But
it's still not recommended.

> I've just been through a lot of this. Turns out there's a diode on the
> termination power line that tends to die. Once dead, you get erratice

That's not a diode, it's a fuse (1 amp microfuse).

> You don't want to change anything but the last page, which is listed as
> "Page 37 - DEC unique parameters:". For all pages before that, just hit

That *should* be page 25h!

john

Could you give me enough data to _replace_ that fuse should I need to? It'd
sure be nice. Thanx for the correction.

BTW, on the off chance you didn't notice, 25h is 37. I don't know why they're
reporting it in decimal, but that's not the least painful part of that program
(or of Ultrix, for that matter).

	<mike

I am having a few problems with an RZ23 connected to an Amiga 2090a (Autobooting)

The main problem is that the first partition automounts on DH2 thru DH8.  That
is it is accesable through DH2, DH3, DH4, DH5, DH6, DH7, DH8.  This always 
happens when I have the SCSI unit set to 0.  When I have the SCSI unit
set higher it sometimes creates fewer devices

		SCSI #	Starting DH
		======	============
		  0	  DH2-> DH8
		  1	  DH2-> DH8
		  6	  DH7,DH8
		  7	  DH8 (Only)

Note that SCSI address 7 is supposed to be the A2090a controller.

Another problem is: Do I need to terminate the SCSI bus if the RZ23 is the
only SCSI device.  Does the RZ23 have internal termination? How do I select
for it?

Does anybody know what the jumbers on the circuit board for the RZ23 do?
These are labeled:
	E1, E2, E3	All of these have the jumper on them.
	E4		This is a three prong jumper set - no jumper attached
	E5,E6		The two selections of a three prong selector. -
			E6 is selected....

Thanks in advance for any help....

-----Robert

    I don't have a solution for your troubles, but can possibly answer some
    questions;

> Another problem is: Do I need to terminate the SCSI bus if the RZ23 is the
> only SCSI device.  Does the RZ23 have internal termination? How do I select
> for it?

    The SCSI bus needs to be terminated at both ends; assuming the A2090a
    is terminating its "end", then the last device at the other end needs
    the terminators (even if there's only one device). Of course, I don't
    have the terminator packs installed on the RZ23 hanging off of my
    C-Ltd. SCSI and haven't had a lick of trouble...yet ;^)
    As far as whether the terminators are installed or not, check for three
    SIP-style resistor packs near the 50 pin SCSI connector (RP1, RP2, and
    RP3).

>Does anybody know what the jumbers on the circuit board for the RZ23 do?
>These are labeled:
>	E1, E2, E3	All of these have the jumper on them.
>	E4		This is a three prong jumper set - no jumper attached
>	E5,E6		The two selections of a three prong selector. -
>			E6 is selected....

    From the specs;

       There are six jumpers available for configuration: three of these
       jumpers (E1, E2, and E3) are used to select the SCSI ID, while E4
       (installed) disables parity. Jumpers E5 and E6 are used to enable
       either the spindle synchronization signal or the LED (at J4, pins
       1 and 2). The drive shall be shipped from the factory with the
       following jumper configuration: E1, E2, E3, and E6 installed.

       The SCSI ID jumper configurations are defined as follows:

        E1      E2      E3      DEVICE

        OUT     OUT     OUT     0
        IN      OUT     OUT     1
        OUT     IN      OUT     2
        IN      IN      OUT     3
        OUT     OUT     IN      4
        IN      OUT     IN      5
        OUT     IN      IN      6
        IN      IN      IN      7

       If E1, E2, and E3 are installed (SCSI node 7) and the A2090a is at
       the same address, that would explain the strange behaviour as each
       device (including the adapter) must have a unique address.

       Hope this helps,

       Pete

Re: .38 CRISTA::CAPRICCIO

Pete,

	Thanks for the info...
	I thought the jumpers near J4 were the drive sunit select... So, if
E1,E2,E3 are the drive select, what are the jumpers near J4....

	Also, if I have problems...where do I get the terminato packs for
RP1,RP2,RP3....

	Thanks,
	Robert

I recently (yesterday) had the occasion to try to set the DSP bit on two rz23s
and one rz24 using the 'strong magic' refered to in .30 - first time round it 
didn't work !!
After much head scratching and cursing the answer was - perform a set first then
a re-set...

i.e. First time through the process answer the rusure? question with 42000001 
and then run 't 73' again, this time answering rusure? with 41000001
This process was successful with all three drives.

					Alan T

re -> < Note 3183.4 by WJG::GUINEAU "Quantum Reality" >
>; ENVIRONMENT: VMS V5.3 with support for generic SCSI devices
>
>devnam:	.ascid	/GKB100/		; SCSI unit 1 on second SCSI bus
>	.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

	When I tried this "out of the box" it failed with ...
	mumble 'Illegal I/O channel' mumble
	mumble '..in routine SPE...mumble

	I changed the following line ,

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

	to...

>devnam:	.ascid	/DKB100/		; SCSI unit 1 on second SCSI bus
			 ^
			 ^

	and it worked fine. The disk did spinup on power up!

	Thanks to the author for this program. It has been VERY helpful.
	I don't understand why I needed this 'modification' and the
	author apparently did not.

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


GK and DK are the generic class and real class drivers for SCSI under VMS.

To use the GK interface (build a scsi command and send it) you need to
connect a GKAx device to your scsi device. This is outlined in the 
VMS SCSI Support Manual.  The failure was probably because you had not
set up the GK device properly.

It just so happens the the GK interface is also present in the DK driver
code. It is undocumented since there are obvious potential difficulties 
with issuing direct scsi commands to mounted devices.

john

    OK, I'm trying to add an RZ55 drive onto my HardFrame.  I've got John's
    RZUtil, and the drive faithfully "Parks" and "UnParks" without a hitch,
    but everything locks up if I try to enable or disable automatic
    spin-up.  RDPrep (and other HardFrame utilities) also freeze when they
    scan for drives.  I tried the "Seagate" workaround (specifying drive #
    on command line) but it still hangs while looking for the drive.
    
    Suggestions...?

    Do you have V1.5 or V1.9 of the Hardframe ROM ?  I had some problems
    while using 1.5, it got better with 1.9, although I never got the 
    Hardframe to recognize an RZ23.  I could send it commands, but couldn't
    mount it???  I finally gave up and got ICD and GVP controllers for the
    systems.  (ICD is about 100-200 K faster than Series II GVP, and costs
    $139... your mileage may vary...)
    
    John
    

    Yup, I installed the V1.9 update a few weeks ago.

This seems like as good a place as any....

I recall having seen a nice V2.0 style utility to perform setting and
clearing of SCSI reselect bits on SCSI drive. I recall using it, but
can not find it anywhere! Can I get a point to this? It also did
some other things like control spinup.

	Thanks,
		-SES