[comp.sys.dec] RQDX[123] differences

deraadt@cpsc.ucalgary.ca (Theo de Raadt) (06/24/91)

Ok, so I see from some old postings that you can hook MFM disks up to
RQDX3 controllers. What are the differences between these controllers
(I mean, are they all MFM?).

What about's can I expect for a used price on one?
 <tdr.
--

SunOS 4.0.3: /usr/include/vm/as.h, Line 44      | Theo de Raadt
SunOS 4.1.1: /usr/include/vm/as.h, Line 49      | deraadt@cpsc.ucalgary.ca
Is it a typo? Should the '_'  be an 's'?? :-)   | deraadt@cpsc.ucalgary.ca

deraadt@cpsc.ucalgary.ca (Theo de Raadt) (06/24/91)

Ok, so I see from some old postings that you can hook MFM disks up to
RQDX3 controllers. What are the differences between these controllers
(I mean, are they all MFM?).

What about's can I expect for a used price on one?
 <tdr.
--

SunOS 4.0.3: /usr/include/vm/as.h, Line 44      | Theo de Raadt
SunOS 4.1.1: /usr/include/vm/as.h, Line 49      | deraadt@cpsc.ucalgary.ca
Is it a typo? Should the '_'  be an 's'?? :-)   | deraadt@cpsc.ucalgary.ca
#! 

slsw2@cc.usu.edu (06/26/91)

In article <DERAADT.91Jun23205834@fsa.cpsc.ucalgary.ca>, deraadt@cpsc.ucalgary.ca (Theo de Raadt) writes:
> Ok, so I see from some old postings that you can hook MFM disks up to
> RQDX3 controllers. What are the differences between these controllers
> (I mean, are they all MFM?).

RQDX1 and RQDX2 are almost identical. RQDX2 fixed some of the more obnoxious
bugs in RQDX1 (which was not originally intended to be a product, if the
rumors are correct) and allowed the controller to address disks larger than 32
MB. RQDX3 integrated the hard disk and floppy controllers using the SMC 9224
controller chip; the RQDX1 & 2 use a discrete hard disk controller.

Roger Ivie
slsw2@cc.usu.edu

terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) (06/26/91)

In article <DERAADT.91Jun23205834@fsa.cpsc.ucalgary.ca>, deraadt@cpsc.ucalgary.ca (Theo de Raadt) writes:
> Ok, so I see from some old postings that you can hook MFM disks up to
> RQDX3 controllers. What are the differences between these controllers
> (I mean, are they all MFM?).

  Yes, they're all MFM. Assuming you have the latest ROMs in each, the
RQDX1 supports RD51, RD52, RX50. The RQDX2 adds RD53. The RQDX3 adds
RD54, RX33, RD31, RD32, RD33 (which I believe was not marketed).

  The RQDX1 and 2 are essentially the same board - the RQDX1 is an
M8639-YA and the RQDX2 is an M8639-YB (I guess the -00 was a total
loss 8-). The 2 is just a newer circuit layout to attempt to correct
the bus problems in the 1. You can put RQDX2 ROMs in the 1 and run
RD53's. The 1 and the 2 are both 3/1 interleave.

  The RQDX3 is a dual-wide board (M7555) which was done with purchased
technology to fix the performance issues and the high manufacturing
cost of the 1 and 2. It's more intelligent, does 1/1 interleave, and
can (if you whisper the right sweet nothings in its ear 8-) be convinced
to handle non-DEC disks.

  For reference:

  RX33 - Teac FD-55GFR
  RX50 - A DEC-built oddity
  RD31 - Seagate ST225
  RD32 - Seagate ST241-1
  RD51 - Seagate ST-412
  RD52 - Quantum Q540 / Atasi 3046 / [almost] Evotek ET-5540
  RD53 - Micropolis 1325 with jumper R7 inserted (1335 also works)
  RD54 - Maxtor XT-2190

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, US
	terry@spcvxa.spc.edu	(201) 915-9381

kalisiak@acsu.buffalo.edu (christophe m kalisiak) (06/26/91)

In article <1073@mixcom.COM> xxwwxx@mixcom.COM (Tim and Tim Company) writes:
>In article <DERAADT.91Jun23205834@fsa.cpsc.ucalgary.ca> deraadt@cpsc.ucalgary.ca (Theo de Raadt) writes:
>
>I don't beleive there are any differences between the
>RQDX1 and the RQDX2, except for the module number, and
>the ROMS installed on-board.  If you put the two ROMS from
>and RQDX2 onto an RQDX1, it should function identically.

Well, sorta. From about 10' the boards look identical, but there
are hardware modifications made to the RQDX1 which makes it an RQDX2.
DEC made it such that the RQDX2 does _not_ have to be the last
board on the bus, increased the number of hard drives usable
on the board, and a couple other things which I can't remember
offhand. Minor things though.

>The RQXD3, however, is another story.  Here's the poop:
>
>The RQDX3 is a Dual card.  The RQDX1/2 are Quad cards.
>
>The RQDX3 uses a better interleave factor.
>(Either 1 or 2, compared to 3 with the RQDX1/2)

It's a 1:1. That's the only redeeming quality of any of the RQDX modules.

>Any of the controllers will support two hard drives, and
>1 RX50 drive.  (The RX50 counts as two drives.)

From what I understand (I don't have my handbook with me), 
the RQDX1 is limited to two hard drives, whereas the RQDX2 & 3
support four hard drives (with no floppy drives).

>BA11 installations of these MSCP controllers is not supported,
>unless you use some grossly over-priced external unit.

Or if you wire wrap your own distribution panel...
I have made up two of them so far.

>Some versions of some operating systems (obviously) do
>not support the RQDX3, so even if yours supports MSCP,
>you should check to see if it supports the RQDX3 *FIRST*.

Actually, it's not that obvious. Which os's that support MSCP
devices do not support the RQDX3? They must be some real oddballs...


Chris Kalisiak

fisher@edwards-vax.af.mil (06/26/91)

In article <1073@mixcom.COM>, xxwwxx@mixcom.COM (Tim and Tim Company) writes:

> The QD01D is MSCP, will support *ANY* two MFM drives
> you hang on it, up to 16 heads (each?).  Drive
> sizes, etc. vary.  If you get a newer one, it
> will have a bootable routine for formatting,
> testing, configuration, etc.  The interleave
> factor is 1:1.
> 
> The nice part about it is the emulation.  It appears
> to the system as 1 or 2 RA81's, which I would imagine
> is supported by all the operating systems that support MSCP.
> 

WARNING !! The very fact that these drives are identified to the operating
system as RA81s *WILL CAUSE PROBLEMS*!!  VMS is smart about it, as are most of
the PDP-11 operating systems, but certain operating systems including most
flavors of UN*X and at least two MUMPS based operating systems I have worked on
in the past have fixed tables describing disk geometry.  In the case of MSCP
disks it uses the drive name (i.e. RA81) to determine this information.

One of the nice things about MSCP controllers is they give the operating system
the size of a disk volume in blocks.  Unfortunately, certain operating systems
that are not limited to Digital Equipment cannot bank on this capability, and
therefore have "hard wired" tables.

Usually these tables can be modified, but it still leaves you with a catch-22
if it is the disk you plan to be installing software on. 

Also, if you have two drives calling themselves "RA81" and having different
sizes, it will vastly confuse these operating systems.

This is not based on assumptions, I have personally fought through these
problems.
-- 
---------------------------------------------------------------------------
  Lawrence Fisher                Internet: fisher@edwards-vax.af.mil
  Digital Equipment Corporation                         ^
  Principal Software Specialist  Currently working here | (Edwards AFB, CA)
  Specializing in Realtime       
  Disclaimer:  I don't speak for Digital or the U. S. Air Force
    "Bomb Number 20, you're out of the bomb bay again"
---------------------------------------------------------------------------

terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) (06/26/91)

In article <81276@eerie.acsu.Buffalo.EDU>, kalisiak@acsu.buffalo.edu (christophe m kalisiak) writes:
> Actually, it's not that obvious. Which os's that support MSCP
> devices do not support the RQDX3? They must be some real oddballs...

  RT-11 V5.1B, at least. That one zinged me just last week...

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, US
	terry@spcvxa.spc.edu	(201) 915-9381

terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) (06/26/91)

In article <1991Jun26.071148.23148@edwards-vax.af.mil>, fisher@edwards-vax.af.mil writes:
> One of the nice things about MSCP controllers is they give the operating system
> the size of a disk volume in blocks.  Unfortunately, certain operating systems
> that are not limited to Digital Equipment cannot bank on this capability, and
> therefore have "hard wired" tables.

  Somebody should tell them they're violating the MSCP Architecture Standard
by doing that 8-).

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, US
	terry@spcvxa.spc.edu	(201) 915-9381