==================================================================

               MicroVAX/VAXstation Systems Text FAQ

         Based upon the hypertext version of the FAQ which is
         maintained by Jim Agnew, Jimanacinnscvcuedu

         This text version is maintained by R. D. Davis,
         rdddigexnet, ...!uunet!mystica!rdd.
   
   ==================================================================

Dear Inquirer after Mvaxen,

This is a form letter basically saying that I have no idea about the
question you asked me.  This is *NOT* an attempt to be nasty, I just
am doing this on my work account, and can't really do justice to the
MicroVAX FAQ.

If you have a news feed availiable to read the Internet newsgroups,
then I'd suggest lurking and asking questions in:

COMP.OS.VMS,
COMP.SYS.DEC,
COMP.SYS.DEC.MICRO.

Also, I'd suggest querying the DEC search engine at:

http://www.altavista.digital.com

Good luck.. Wish I could have helped you more!!1

Jim

     This FAQ was previously maintained by Edward Austin, Computer
     Science, Uni of Liverpool; the hypertext version is now
     maintained by Jim Agnew, Neurosurgery, Medical College of Virginia,
     Richmond, VA, USA.  ("Yes, this FAQ done jumped the pond, thanks to 
     Dave Shield of Uni of Liverpool who resurrected this for us all. 
     Thanks, Dave!")
   
     This version of the FAQ was converted from many html files to a
     single text file; various tables were fixed to fit onto an 
     80-column page, and some minor editing here and there, etc. was 
     done by R. D. Davis, rddaccess.digex.net, September 11, 1996.
     A few comments and other items here and there were added as 
     well, marked by "[R.D.D.]".

     Various other questions, preferably with answers, are most
     welcome!  


   C O N T E N T S
   ---------------

   (1) General information about this FAQ

   (2) MicroVAX/VAXstation General Info   
      (2a) Relative Performance of VAX/MicroVAX/VAXstation Systems 1977-1994
      (2b) What would be a decent home starter system?
      (2c) Approximate Values of some Systems and Options
      (2d) Moving cards around QBUS systems (MicroVAX-II -> 3400)...
      (2e)...and our experiences of moving cards around QBus systems
      (2f) MicroVAX/VAXstation Memory options
      (2g) SCSI Interface for QBUS Product details

   (3) MicroVAX/VAXstation-2000 specifics
      (3a) MicroVAX-2000/VS-2000 Technical Specs and Misc stuff
      (3b) More detailed specs on the 2000 from CrazyCam, DECUS Australia.
      (3c) Peter Coghlans RX23 driver for a MV/VS-2000
      (3d) SCSI disks via the 2000 SCSI tape expansion box?
      (3e) MicroVAX-2000 asynchronous multiplexer spec sheet
      (3f) MicroVAX 2000/VAXstation 2000 "dd2000.html" Diagnostic Package 
      (3g) Blurb about Interfacing a 2000 with a 3400
      (3h) How do I boot a VAXstation 2000 running Ultrix? [R.D.D.] 

   (4) MicroVAX-II/VAXstation-II specifics
      (4a) Adding additional drives to a MicroVAX-II
      (4b) A problem I had with a dead MicroVAX-II she don't boot!! :-(
      (4c) THE GPIB Interface for MicroVAX-II details (external link) 
      (4d) I've just acquired a MicroVAX II.  What should I do before
           turning the power on for the first time? [R.D.D.]
      (4e) Answers to "What's a VAX Console?" and   
           "I found an M7553 in my system - what is it?" [R.D.D.]
      (4f) What's what on the back panel, or buklhead, of a MicroVAX II? 
           [R.D.D.]

   (5) MicroVAX-3100/VAXstation-3100 specifics
      (5a) MicroVAX 3100 40/85 infosheet from Digital Apr 95
      (5b) MicroVAX 3100 30/40/80/90 [23]Systems And Options Catalog Feb 94
      (5c) Interfacing a[24] third party SCSI drive to your 3100 Q/A
      (5d) Design of the MicroVAX-3100/90 from the Digital Technical 
           Jnl 4/3 1992
   (6) MicroVAX-3xxx/VAXstation-3xxx specifics (other than 3100..)
      (6a) What is a VAXstation 3520 exactly?

   (7) VAXstation serial pinouts

   (8) I've forgotten the SYSTEM password - what can I do? [R.D.D.]

   (9) How can I modify my copy of VMS for more users? [R.D.D.]

*============================================================================*

   (1) General information about this FAQ
   --------------------------------------
   
   This FAQ intends to cover the Digital MicroVAX/VAXstation range of
   systems produced by Digital from 1984 onwards - if any of you have any
   information to add, please mail me and I'll put it in. Thanks. My aim
   is to develop this into the primary source of info for all uVAX/VS
   lovers worldwide. My motivation to develop this FAQ was the fact that
   I found it virtually impossible to find information about my old
   machines (MicroVAX-II, VS-2000) and my current (3100/38) on the Web...
   I'd be immensely grateful if you have anything to contribute, lets
   help each other and make this worthwhile :-)
   
   Please also feel free to mail us with comments/corrections on the page
   that sent you here:
   
   JIMANACIN.NSC.VCU.EDU (hypertext)

   rdddigex.net, ...!uunet!mystica!rdd (text)
   
   At the moment this FAQ will attempt to cover the following
   processors/options:


   The first generation 1984/85
   ----------------------------

   MicroVAX-I               VAXstation-I   (1984)

   MicroVAX-II              VAXstation-II
                            VAXstation-II/GPX (1985)
                            VAXstation-II/QVSS (1985?)
                            VAXstation-II/QDSS (1985?)
                            VAXstation-II/RC   (1985?)

   MicroVAX-3               VAXstation-3 (?) (1985?)

   MicroVAX-3+  (1985??)


   MicroVAX-2000            VAXstation-2000
                            VAXstation-2000/GPX (1985)
                            VAXstation-2000/MFB ('85?)



   The second generation (3x00 series) 1986-1991
   ---------------------------------------------

   (Including VS SPX/GPX options etc)

   MicroVAX-3100            VAXstation-3100            VAXserver-3100 (1987)
   MicroVAX-3100/10         VAXstation-3100/10  (1987)
   MicroVAX-3100/10e        VAXstation-3100/10e (1987)
   MicroVAX-3100/20         VAXstation-3100/20  (1987)
   MicroVAX-3100/20e        VAXstation-3100/20e (1987)
   MicroVAX-3100/30         VAXstation-3100/30  (1987)
                            VAXstation-3100/38  (1987)
   MicroVAX-3100/40         VAXstation-3100/40  (1987)
                            VAXstation-3100/48  (1987)
   MicroVAX-3100/76         VAXstation-3100/76  (1990)
   MicroVAX-3100/80 (1991)
   MicroVAX-3100/85 (1991)
   MicroVAX-3100/90 (1991)
   MicroVAX-3100/95 (1991)
   MicroVAX-3100/96 (1991)
 
   MicroVAX-3200 (1987)     VAXserver-3200 (1987)       VAXstation-3200 (1987)
   MicroVAX-3300 (1987)     VAXserver-3300 (1987)
   MicroVAX-3400            VAXserver-3400 (1986)
   MicroVAX-3500            VAXserver-3500 (1987)       VAXstation-3500 (1987)
                                                        VAXstation-3520 (1987)
                                                        VAXstation-3540 (1987)
   MicroVAX-3600            VAXserver-3600 (1987)
                            VAXserver-3602 (1987??)
   MicroVAX-3800            VAXserver-3800 (1987)
   MicroVAX-3900            VAXserver-3900 (1987)


   The third generation (4x00 series) 1991-
   ----------------------------------------

   VAXstation-4000 VLC (Model 30) (1991)
   VAXstation-4000/60  (1991) (Current Model)
   VAXstation-4000/90  (1991)
   VAXstation-4000/90a (1991)
   VAXstation-4000/96         (Current Model)

   MicroVAX-4200

     _________________________________________________________________
                                      
   Note there is a *lot* of relevent information in the [2]info-vax
   archives however as yet I can't find any way of searching the massive
   amounts of stuff there - But I'll keep looking... it looks promising.
     _________________________________________________________________
                                      
*============================================================================*

   (2) MicroVAX/VAXstation General Info

------------------------------------------------------------------------------

   (2a) Relative Performance of VAX/MicroVAX/VAXstation Systems 1977-1994
   ----------------------------------------------------------------------- 

                VMS CPU Model Summary (23rd June 1995)
                ---------------------------------------

   The following table summarises the whole publicly known VAX and AXP
   model range by CPU type, divided into processor families, and then by
   subtype, giving approximate chronological order. The information given
   is:

   o The top byte of the SID in hex (containing the CPU type),
   o Processor subtype (XCPU or SYSTYPE).
   o Processor ID for VAXes.
   o Clock speed in MHz for AXPs.
   o Approximate speed (relative to a VAX-11/780, in VUPS for most machines,
     SPECmark89 (S) for later VAX workstations,
     SPECint92/SPECfp92 for AXPs).
   o Main I/O bus type (U=UNIBUS, M=MASSBUS, C=CI, Q=QBUS,  B=BI, D=DSSI, 
     X=XMI,T=Turbochannel, F=Futurebus+, S=SCSI, E=EISA, P=PCI).
   o Model names.
   o Nickname.

   Information is from publicly available sources such as DEC brochures
   and press releases, together with the description of SYS$GETSYI in the
   VMS documentation, and from $PRDEF, $VAXDEF, and $ALPHADEF in the
   system macro library. This is supplemented with information from
   USENET group comp.os.vms. Current models are marked by a leading `*'.

   This list is not an official publication of Laser-Scan - ask DEC if
   you want confirmed figures! In the fast changing world of computer
   hardware, its probably out of date when written. However, please let
   me know of any inaccuracies or omissions.

   ---
   Paul Hardy (PGH), Product Manager (former Chief Programmer),
   Laser-Scan Ltd, Science Park, Milton Rd, CAMBRIDGE, CB4 4FY, England.
   Tel: (+44) (0)1223 420414; Fax: 420044, Email: PAULLSL.CO.UK


VAX CPUs
----+---+-----+-------+--------+--------------------------------+--------------
SID | X | Id  | Speed |  Bus   | Model Name                     | Nickname
----+---+-----+-------+--------+--------------------------------+--------------

---- 700 series (1977) +--------+-------------------------------+-------------
 01 | - | 780 | 1.0   | U,M,C  | VAX-11/780                     | Star
 01 | - | 780 | 1.8   | U,M,C  | VAX-11/782                     | Atlas
 01 | - | 780 | 3.5   | U,M,C  | VAX-11/784                     | VAXimus
 01 | - | 780 | 1.5   | U,M,C  | VAX-11/785                     | Superstar
 02 | - | 750 | 0.6   | U,M,C  | VAX-11/750                     | Comet
 03 | - | 730 | 0.3   | U      | VAX-11/730, 725                | Nebula, LCN
 04 | - | 790 | 4.0   | U,M,C  | VAX 8600,                      | Venus
 04 | - | 790 | 7.0   | U,M,C  | VAX 8650                       | Morningstar

---- 8000 series (1986)+--------+-------------------------------+-------------
 05 | - | 8SS | 0.9-2 | B,C    | VAX 8200, 8300, 8250, 8350     | Scorpio
 05 | - | 8SS | 0.9-2 | B,C    | VAXstation 8000                | Lynx
 06 | - | 8NN | 3     | B,C    | VAX 8500                       | Flounder
 06 | - | 8NN | 4/6   | B,C    | VAX 8530, 8550                 | Skipjack
 06 | - | 8NN | 6/12  | B,C    | VAX 8700, 8800                 | Nautilus

---- MicroVAX I (1984) - Decimal SID = 117440512 ---------------+-------------
 07 | - | UV1 | 0.3   | Q      | MicroVAX I, VAXstation I       | Seahorse

--- MicroVAX II series (1985) - Decimal SID = 134217728 --------+-------------
 08 | 1 | UV2 | 0.9   | Q      | MicroVAX II,VAXstation II      | Mayflower
 08 | 1 | UV2 | 0.9   | Q      | VAXstation II/GPX              | Caylith
 08 | 4 | 410 | 0.9   | none   | MicroVAX 2000                  | TeamMate
 08 | 4 | 410 | 0.9   | none   | VAXstation 2000                | VAXstar
----+---+-----+-------+--------+--------------------------------+-------------

--- CVAX chip series (1987) - Decimal SID = 167772160 ----------+------------
 0A | 1 | 650 | 2.8   | Q      | MicroVAX 3500, 3600            | Mayfair
 0A | 1 | 65D | 2.8   | Q      | VAXstation 3200, 3500          | Mayfair/GPX
 0A | 1 | 640 | 2.4   | Q,D    | MicroVAX 3300, 3400            | Mayfair II
 0A | 1 | 655 | 3.8   | Q      | MicroVAX 3800, 3900            | Mayfair III
 0A | 2 | 9CC | 2.8   | X,B,C  | VAX 6000 model 210             | Calypso/XCP
 0A | 2 | 9CC | 3.8   | X,B,C  | VAX 6000 model 310             | Calypso/XCP
 0A | 3 | 60  | 3-10  | Q      | VAXstation 3520, 3540          | Firefox
 0A | 4 | 420 | 2.8   | S      | VAXstation 3100 models 30, 40  | PVAX
 0A | 4 | 420 | 2.4   | S      | MicroVAX 3100 models 10, 20    | Teammate II
 0A | 4 | 420 | 3.5   | S      | MicroVAX 3100 models 10e, 20e  | Teammate II
 0A | 4 | 420 | 3.8   | S      | VAXstation 3100 models 38, 48  | PVAX rev#7
*0A | 7 | 510 | 2.4   | D      | VAXft model 110                | Cirrus
 0A | 7 | 520 | 3.8   | D      | VAXft model 310                | Cirrus

--- Rigel chip series (1990) - Decimal SID = 184549376 ---------+-------------
 0B | 1 | 670 | 8.0   | Q,D    | VAX 4000 model 300             | Pele
 0B | 2 | 9RR | 7-36  | X,B,C  | VAX 6000 model 410-460         | Calypso/XRP
 0B | 4 | 43  | 7.6   | S      | VAXstation 3100 model 76       | RigelMAX

--- Aquarius series (1990) - Decimal SID = 234881024 -----------+-------------
 0E | - | 9AR |40-157 | X,B,C  | VAX 9000 models 210, 410-440   | Aridus
 0E | - | 9AQ |40-157 | X,B    | VAX 9000 models 400-800        | Aquarius

--- Polarstar series (1988) - Decimal SID = 285212672 ----------+-------------
 11 | - | 8PS | 6-22  | B,C    | VAX 8810 to 8840               | Polarstar

--- Mariah chip series (1991) - Decimal SID = 301989888 --------+------------
 12 | 2 | 1202|13-58  | XBCD   | VAX 6000 model 510-560         | Calypso/XMP
 12 | 4 | 46  | 12    | T,S    | VAXstation  4000 model 60      | PMariah
 12 | 4 | 46  | 12    | S      | MicroVAX 3100 model 80         | Waverley/M
*12 | 4 | 46  | 17    | S      | MicroVAX 3100 model 85         | Waverley/M+

--- NVAX chip series (1991) - Decimal SID = 318767104 ----------+-------------
 13 | 1 | 690 | 16    | Q,D    | VAX 4000 model 400             | Omega
 13 | 1 | 69D | 24    | Q,D    | VAX 4000 model 500, 500A       | Omega/N
*13 | 1 | 69D | 32    | Q,D    | VAX 4000 model 505A            | Omega/N+
 13 | 1 |1303 | 24    | Q,D    | VAX 4000 model 100, 100A       | Cheetah-Q
*13 | 1 |1303 | 32    | Q,D    | VAX 4000 model 105A            | Cheetah-Q+
*13 | 1 | 700 | 32    | Q,D    | VAX 4000 model 600, 600A       | Omega/N+
 13 | 1 | 700 | 40    | Q,D    | VAX 4000 model 700A            | Legacy
*13 | 1 | 700 | 45    | Q,D    | VAX 4000 model 705A            | Legacy+
 13 | 2 |1302 |32-150 | XBDC   | VAX 6000 models 610-660        | Neptune
 13 | 4 |  49 |32.8 S | T,S    | VAXstation 4000 model 90       | Cougar
*13 | 4 |  49 |38.5 S | T,S    | VAXstation 4000 model 90A      | Cougar+
*13 | 4 |  49 | 24    | S      | MicroVAX 3100 model 90         | Cheetah
 13 | 4 |  49 | 32    | S      | MicroVAX 3100 model 95         | Cheetah+
*13 | 4 |  49 | 38    | S      | MicroVAX 3100 model 96         | Cheetah++
*13 | 7 | 600 | 30    | D      | VAXft model 810                | Jetstream

--- SOC chip series (1991) - Decimal SID = 335544320 -----------+-------------
 14 | 1 | 660 | 5.0   | Q,D    | VAX 4000 model 200             | Spitfire
 14 | 4 | 440 | 6.2 S | S      | VAXstation 4000 VLC (model 30) | PVAX2/VLC
 14 | 4 | 440 | 5.0   | S      | MicroVAX 3100 models 30, 40    | Waverley/S
 14 | 7 | 550 | 6.0   | D      | VAXft model 410, 610           | Cirrus II

--- NVAX+ chip series (1991) - Decimal SID = 385875968 ---------+-------------
 17 | 3 | 1701|35-120 | X,C,D  | VAX 7000 models 610-640        | Laser/Neon
 17 | 3 | 1701|35-120 | X,C,D  | VAX 10000 models 610-640       | Blazer

--- NVAX5 chip series (1994) - Decimal SID = ????????? ---------+-------------
*17 | 3 | 1701|50-250 | X,C,D  | VAX 7000 models 710-760        |Laser/Krypton

----+---+-----+-------+--------+--------------------------------+-------------
Alpha AXP CPUs
----+---+-----+-------+--------+--------------------------------+-------------
SID | S |Clock| SPEC92|  Bus   | Model Name                     | Nickname
----+---+-----+-------+--------+--------------------------------+-------------

--- EV4 AXP chip series (1992) - Decimal SID = -2147483648 -----+-------------
 80 | 2 | 160 | 95/138| F,D,S  | DEC 4000 model 610             | Cobra
*80 | 2 | 190 |122/185| F,D,S  | DEC 4000 model 710             | Fang
 80 | 3 | 180 |103/176| X,C,D  | DEC 7000 model 610             | Laser/Ruby
 80 | 3 | 200 |133/200| X,C,D  | DEC 7000 model 610             | Laser/Ruby+
 80 | 3 | 200 |107/200| X,C,D  | DEC 10000 model 610            | Blazer/Ruby
 80 | 4 | 150 | 84/128| T,S    | DEC 3000 model 500W or S       | Flamingo
 80 | 4 | 200 |130/184| T,S    | DEC 3000 model 800W or S       | Flamingo II
 80 | 4 | 133 | 75/112| T,S    | DEC 3000 model 400W or S       | Sandpiper
 80 | 4 | 175 |114/162| T,S    | DEC 3000 model 600W or S       | Sandpiper+
 80 | 4 | 200 |111/164| T,S    | DEC 3000 model 500X            | Hot Pink
 80 | 4 | 150 | 81/110| T,S    | DEC 3000 model 300             | Pelican
 80 | 4 | 100 | 46/63 | S      | DEC 3000 model 300L            | Pelica
 80 | 4 | 125 | 68/77 | S      | DEC 3000 model 300LX           | Pelica+
 80 | 4 | 175 | 90/102| T,S    | DEC 3000 model 300X            | Pelican+
 80 | 6 | 150 | 81/110| S,E    | DEC 2000 model 300 (pc AXP/150)| Jensen
 80 | 9 | 200 |124/160| P,S,E  | DEC 2100 model A500MP          | Sable
 80 | 9 | 200 |127/161| P,S,E  | AlphaServer 2000 4/200         | Sable
 80 | ? | 200 |136/177| P,S,E  | AlphaServer 1000 4/200         | Demi Sable
*80 | ? | 166 |107/135| P,S,E  | AlphaStation 200 4/166         | Mustang
*80 | ? | 100 | 74/92 | P,S,E  | AlphaStation 200 4/100         | ???
*80 | ? | 166 |117/140| P,S,E  | AlphaServer 400 4/166          | Mustang S

-- EV45 AXP chip series (1994) - Decimal SID = -2147483648 -----+-------------
 80 | 4 | 225 |163/231| T,S    | DEC 3000 model 700W            | Sandpiper45
 80 | 4 | 275 |189/264| T,S    | DEC 3000 model 900W or S       | Flamingo 45
 80 | 3 | 275 |201/293| X,C,D  | DEC 7000 model 710             | Laser/Ruby45
*80 | ? | 233 |158/184| P,S,E  | AlphaStation 200 4/233         | Mustang
*80 | ? | 233 |158/184| P,S,E  | AlphaStation 400 4/233         | Mikasa
*80 | ? | 275 |181/260| P,S,E  | AlphaServer 2000 4/275         | Sable45
*80 | ? | 275 |158/184| P,S,E  | AlphaServer 2100 4/233         | ??
*80 | ? | 275 |200/292| P,S,E  | AlphaServer 2100 4/275         | ??
*80 | ? | 233 |165/223| P,S,E  | AlphaServer 1000 4/233         | ??
*80 | ? | 266 |199/263| P,S,E  | AlphaStation 250 4/266         | ??

-- EV5 AXP chip series (1995)  - Decimal SID = -2147483648 -----+-------------
*80 | 3 | 300 |336/507| XPFCSE | AlphaServer 8400 5/300         | ??
*80 | 3 | 300 |336/507| P,S,E  | AlphaServer 8200 5/300         | ??
*80 | 3 | 250 |277/410| P,S,E  | AlphaServer 2100 5/250         | ??
----+---+-----+-------+--------+--------------------------------+-------------


------------------------------------------------------------------------------
   
   (2b) What would be a decent home starter system?

        NOTE: Please take note the year in which this FAQ was originaly
              written (does anyone know when that was?) and adjust the 
              following prices, downward, accordingly. :-)  [R.D.D.]
        
   * MicroVAX/VAXstation Starter Systems
   -------------------------------------
                                      
   Absolute Budget Minimum/Often Free Systems

   This system, which you may be able to get for free if you look around
   would consist of a MicroVAX-I System with a KA630-AA(?) CPU with 1mb
   onboard memory, an RQDX2 controller and an RD31 disk, it will run VMS
   4.7 be *very* slow and noisy and would need a VT-220 console or
   equivalent.  Invariably systems that are given away tend to have a
   higher spec than this, often a MicroVAX-II CPU with RD54, RQDX3, DEQNA
   and at least 9mb RAM.


   Systems that may cost you $100-$200 (US)

   For this price you should be able to pick up a VAXstation-2000 with at
   least 6mb RAM and an internal RD54 running VMS 5.x, maybe a console
   thrown in, or if lucky a VR260. Nice machines, but *VERY* slow, the RD
   series drives are noisy, slow and unreliable. A typical use would be
   as an X terminal over thinwire, as a standalone system OK but fairly
   obsolete.

                                      
   Systems that may cost you $200-$500 (US)

   For this price, maybe a high end MicroVAX-II system with 16mb and
   DELQA, RQDX3 and a couple of RD54's, maybe a TK50 thrown in. But you
   really should be looking for a low end VAXstation-3100 for this price.
   Around three times the speed (VUPS) and very expandable, quiet and
   reliable.  Maybe a 3100 base with 8mb and a VR260 and a small SCSI
   drive with VMS for $500...

                                      
   Systems that may cost you $500-$1000 (US)

   At this level *FORGET* the MicroVAX-II's, the VS-2000's and go for a
   low end VS-3100, something basic with DECwindows should be available,
   maybe if you are lucky a VS-3100/38 (3.8 VUPS) makes a very nice
   standalone X box...

                                      
   Systems around $1000 (US)

   As a minimum I would suggest a VS-3100/38 with a VR290 or VR299, 16mb
   RAM and a decent size SCSI drive for around $1000, maybe better
   configured than this even...

                                      
   Systems $1000 - 3000 (US)

   Go buy a new VAXstation :-) seriously though I would suggest a
   decently configured 3100/76 with a VRT19 or a 4000 VLC with a VR299.

                                      
   PRICES ARE FOR GUIDANCE ONLY - IF YOU ARE SERIOUS ABOUT BUYING SUCH
   A SYSTEM SPEAK TO SOMEBODY WHO KNOWS BETTER THAN I !!! 

         
------------------------------------------------------------------------------
   
   (2c) Approximate Values of some Systems and Options

                              ---*---

        PLEASE NOTE: reseller prices are generally much higher than the
        prices paid for most used systems when the systems are purchased
        directly from the previous user/owner.  Also note that one can 
        often haggle with resellers and get a much lower price than the 
        price which has been quoted.  Do not pay the first quoted price 
        unless you desparately need the equipment, and need it quickly.

        Also note when this list was created and factor in the suitable
        depriciation rates if you're reading this in a somewhat later
        year.
                                                     [R.D.D.]

                              ---*---

    Reseller Prices of Used Serviced Equipment [source?  year?]
    _________________________________________________________________
                                     
    Used CPU prices (UK sterling)


    KA630             "MicroVAX-II"      25-50
    KA640/M7624       "MicroVAX 3300"    300
    KA650             "MicroVAX 3400"?   100
    KA655/M7625       "MicroVAX 3900"    250-750
    KA42              "VS3100/38"        100


    Used CD ROM Drive prices (UK sterling)

    RRD40      100
    RRD42      150


    Used System Prices (US Dollars)
 
    MicroVAX

    DV31AT1AA     Model 10, 8Mb, 5 User                  1,395
    DV31ETAAA     Model 20E, 8Mb, 5 User                 1,795
    DV31GTAB9     Model 40, 8Mb, 2 User                  4,995
    DV31HTAB9     Model 80, 8 Mb, 2 User                 7,895
    DV31PTAC9     Model 90, 16Mb, 2 User                11,900
    DV31RAAE9     Model 95, 64Mb, Open VMS              14,950
    DV350T1AA     TK70, 16Mb, RA70, 20 User              1,995
    DV380T1AA     TK70, 16Mb, RF71, 20 User              2,900


    KA640-AA      MicroVax 3300/3400 CPU                   595
    KA650-AA      MicroVax 3500/3600 CPU                   595
    KA660-AA      MicroVax 4200 CPU                      1,950

    VAXstation

    PV01ABJ       3100 Model 30, 8Mb, 1 User                    425
    PV11ABS       3100 Model 38, 8Mb, 1 User                    595
    PV31AAD       4000 Model VLC, 8Mb, VRM17,VMS, 1 User      1,495
    PV41ABA       3100 Model 76, 8Mb, 1 User                    795
    PV61ADA       4000 Model 60, 8Mb, 1 User                  3,895
    PV71AAA(90)   3100 Model 90A, 16Mb, 1 User                7,995
    PV71AAA(90A)  3100 Model 91A, 16Mb, 1 User                8,495


    Typical configurations and Prices (UK Sterling)


    MicroVAX    3100/95 16mb 1GB OpenVMS       11 970
    MicroVAX    3100/85 16mb 1GB OpenVMS        5 540

    VAXstation  3100/76 16mb RZ25  VR299 VMS    1 700
    VAXstation  4000VLC 16mb RZ23L VRT19 VMS    1 600
  
    MicroVAX    3900, 2 RF31, 16mb              1 250

    VAXstation  3100/38, 16mb, RZ23, VR299      1 200
    VAXstation  3100/76                         1 000
    VAXstation  3100/30 SPX, 16mb, RZ23, VR299    995

    VAXserver   3100/10, 3 RZ23, 8mb              995

    VAXstation  3100/30 16mb RZ24 VR299 No Lic.   800

    MicroVAX    3400 base                         700
    MicroVAX    3300 base                         600
    MicroVAX    3500 base                         500

    VAXserver   3100 base                         500

    VAXstation  3100/38 base                      450
    VAXstation  3100/30 base                      175-250

    MicroVAX    II                                50-250
    MicroVAX    2000                              100-250

    VAXstation  II                                150
    VAXstation  2000                              50-100



    3100 SCSI Disks

    RZ22    10   (52mb)
    RZ23    25   (109mb?)
    RZ24   125   (245mb)
    RZ24L  150   (245mb)
    RZ25   275   (426mb)
    RZ26   350   (1.05GB)
    RZ28   850


------------------------------------------------------------------------------
   
   (2d) Moving cards around [6]QBUS systems (MicroVAX-II -> 3400)...
   

   From:   SMTP%"leichterlrw.com" 21-MAR-1995 03:51:28.33
   Subj:   RE: Sticking MV II cards into a MV3400

      I've got a couple of disk controllers (Emulex QD21 and Dilog DQ686) in
      a couple of MVII's that I want to junk.  I've got access to a MV3400
      and was wondering if the Q-bus backplanes are different on these
      systems.  I realize that the mounting equipment is different (MVII's
      in BA23 vs the MV3400 with a BA213), but I can tolerate some
      jury-rigging in this application.


   The Q-bus is pretty standard; your boards should work.  The only Q-bus
   systems that get a bit odd are on things like the whatever-4000-it-is
   that provides a Q-bus interface.  It has some restrictions - but the
   problems are in the interface to the rest of the system, not in the
   Q-bus itself.  Other than that, unless you have some *really* old Q-18
   stuff - well, DEC is pretty good at designing and specifying buses and
   the Q-bus was at least their 3rd generation (after the Unibus and the
   Omnibus).

                                                           -- Jerry 

     _________________________________________________________________
                                      

   From:   SMTP%"SMSprovis.com" 21-MAR-1995 04:59:18.20
   Subj:   Sticking MV II cards into a MV3400


          One more caution.  While the boards are almost certain to work,
      half-size (dual-height) boards must go into the top half of the BA213
      backplane (rows A-B).  In the BA123, slots 5 and up have bus
      continuity through both halves (rows A-B and C-D), so putting two
      small boards into one slot can work.  In a BA23, my old books are not
      so clear, but the same may be true for slots 4 and up.  In a BA213,
      it's one board only per slot.  Otherwise, it can't miss.  We have
      mu-VAX IIs (BA123) and a 4200 (BA215 and BA213), and have run several
      boards in both.  (Moving a board from a BA[1]23 to a BA21x is easier
      than going the other way, mechanically.)

          Getting rid of any 8MB memory boards from your junk mu-VAX IIs?  I
      could help.

      Steven M. Schweda                    (+1) 612-636-8950  (voice)
      Provis Corporation                   (+1) 612-636-8951  (facsimile)
      2685 Long Lake Road                  smsprovis.com  (e-mail)
      Roseville, MN  55113-2537

     _________________________________________________________________
                                      

   From:   SMTP%"hoffmanxdelta.enet.dec.com (Stephen Hoffman)" 21-MAR-1995 \
        16:13:02.90
   Subj:   Re: Sticking MV II cards into a MV3400


   In article , ronpisces.fusion.ucla.edu () writes:

   :I've got a couple of disk controllers (Emulex QD21 and Dilog DQ686) in
   :a couple of MVII's that I want to junk.  I've got access to a MV3400
   :and was wondering if the Q-bus backplanes are different on these
   :systems.  I realize that the mounting equipment is different (MVII's
   :in BA23 vs the MV3400 with a BA213), but I can tolerate some
   :jury-rigging in this application.

   ATTEMPT ANY AND ALL Q-BUS MODIFICATIONS AT YOUR OWN RISK -- CONTACT
   YOUR HARDWARE SERVICE ORGANIZATION FOR FURTHER ASSISTANCE.

     You may (will?) end up with RF emissions and/or RFI problems if the
     enclosure is not properly RF-sealed.

     First, if you are not familiar with working inside the Q-bus
     enclosure, or if you are unfamiliar with the DMA grant continuity, or
     if you are unwilling to make potentially permanent modifications to
     the card, or if you are unwilling to place other cards at risk due to
     an incorrect installation, or if you are unfamiliar with working with
     static-sensitive electronic components, DO NOT ATTEMPT THIS.

     Dual-width cards should install and operate in the upper half of the
     slot in the BA2xx and BA4xx system.

     If it is a quad-width card, what you are considering likely involves
     the electrical modification of a Q22/Q22 card to operate in a Q22/CD
     slot.  (In the BA23 and BA123, these Q22/CD slots are restricted to
     "memory" and processor" modules, and Quad-width boards can *not* be
     installed in these slots.  The KA640 MicroVAX 3400 processor shipped
     in a BA2xx enclosure.)

     Quad-width cards may/will cause you problems in the BA2xx or BA4xx
     series Q22/CD enclosures -- you should be aware that a DMA grant
     continuity etch on the lower half of the card is *not* permissible in
     a CD slot.  (All BA2xx and BA4xx series enclosures are Q22/CD in all
     slots -- most (all?)  Q-bus cards not intended for use in the BA2xx or
     BA4xx series will have this etch, and it will cause problems.)  If the
     DMA or Q-bus circuitry is connected off the lower etch fingers, you
     will have real trouble here.  If it is "just" the DMA grant continuity
     circuitry, some surgery on the card etch may allow the card to operate
     in a Q22/CD slot.

     I DO  RECOMMEND MAKING THESE MODIFICATIONS, NOR DO I RECOMMEND
     INSTALLING MODULES IN AN ENCLOSURE THEY WERE NOT INTENDED TO RESIDE IN.
     CONTACT YOUR HARDWARE SERVICE ORGANIZATION FOR FURTHER ASSISTANCE.

     --------------------------- Opinionative ------------------------------
    Stephen Hoffman, NR EMT-I, WEMT, N1THN        hoffmanxdelta.enet.dec.com
         OpenVMS Engineering, Digital Equipment Corporation, Nashua NH

     _________________________________________________________________
                                      

   From:   SMTP%"newsspcuna.spc.edu (Network News)" 21-MAR-1995 21:40:15.23
   Subj:   Re: Sticking MV II cards into a MV3400


In article , ronpisces.fusion.ucla.edu () writes:
   > I've got a couple of disk controllers (Emulex QD21 and Dilog DQ686) in
   > a couple of MVII's that I want to junk.  I've got access to a MV3400
   > and was wondering if the Q-bus backplanes are different on these
   > systems.  I realize that the mounting equipment is different (MVII's
   > in BA23 vs the MV3400 with a BA213), but I can tolerate some
   > jury-rigging in this applicatio n.

     Almost all MVII systems (MVII, VSII, VSII/GPX) were delivered in BA23
   or BA123 cabinets. The BA23 is 3 C-D slots followed by Q22 slots, the
   BA123 is 4 C-D slots followed by Q22 slots. The BA2xx/4xx cabinets
   used for the later MicroVAX/VAX systems are only C-D slots. This means
   that any dual-height card *must* go in the A-B (usually top) positions
   in those cabinets. Depend- ing on the weight of the card and the
   stiffness of the backplane connectors, the card may tilt out of its
   socket. There's a plastic baffle which looks like a dual-height card
   that is used to support these cards as well as make sure the airflow
   works properly. If you're only moving one dual card it shouldn't
   matter.

     You've already observed that the mounting is different (the new systems
   are S-box). DEC retrofitted some cards (the KLESI-SA is a regular KLESI
   with a S-handle riveted on), redesigned some cards (the CXY08/CXA16/CXB16
   are re-layouts of the DHV11/DHQ11 family), and left some cards alone (the
   TQK70 is the same board in both cabinets). DEC sells blank S-box fillers
   as well as some with cutouts, so you could probably do something that both
   looked Ok and maintained the airflow and FCC compliance if you wanted.

     Some boards won't work in the newer CPU's. An obvious example is
   Micro- VAX II memory. There are some more subtle issues, though. For
   example, many older boards (like the TSV05 controller) and 3rd-party
   boards didn't work in KA650/KA655-based systems (3500/3600/3800/3900)
   due to an error in the Q-bus interface IC on those processor boards
   which DEC was very reluctant to fix. Eventually DEC fixed it - if your
   system is on DEC hardware support you should be able to get a new CPU
   (for the KA650 it's Rev. K1, I think).  If you're not on DEC hardware
   support, it's probably cheaper to buy a used CPU on the surplus market
   (making sure it's up to rev) than to get DEC to swap it on the
   time+materials plan. I don't think this affected the KA640 (3300/3400)
   but I'm not certain.

        Terry Kennedy             Operations Manager, Academic Computing
        terryspcvxa.spc.edu      St. Peter's College, Jersey City, NJ USA
        +1 201 915 9381 (voice)   +1 201 435-3662 (FAX)

     _________________________________________________________________
                                      

   From:   SMTP%"Info-VAX-RequestMvb.Saic.Com" 22-MAR-1995 16:20:55.54
   Subj:   Re: Sticking MV II cards into a MV3400

   Stephen Hoffman, NR EMT-I, WEMT, N1THN        hoffmanxdelta.enet.dec.com:
   In article , ronpisces.fusion.ucla.edu () writes:
   >:I've got a couple of disk controllers (Emulex QD21 and Dilog DQ686) in
   [...]
   >:jury-rigging in this applicatio n.

   >  First, if you are not familiar with working inside the Q-bus enclosure,
   [...] 
   >  CONTACT YOUR HARDWARE SERVICE ORGANIZATION FOR FURTHER ASSISTANCE.

   I'm certainly not going to disagree with the sentiments, but FWIW I
   believe it should be possible to use a quad height card in a Q22/CD
   backplane, provided some care is taken.

   Because of the way that the CD connections work, I believe that the effect
   of the DMA (and BR) grant continuity etches will depend entirely on the
   adjacent cards. Putting a double height Q-bus grant card (or double height
   module) in the AB slots either side of the quad height card should mean
   that these grant etches are not connected to anything.

   I think. I may be wrong.

   Mark Iline      systemmeng.ucl.ac.uk
   Dept Mech Eng, University College, London. UK

     _________________________________________________________________
                                      

   From:   SMTP%"hoffmanxdelta.enet.dec.com" 22-MAR-1995 17:40:04.66
   Subj:   Re: Sticking MV II cards into a MV3400


       Hello Mark Iline,

      >Because of the way that the CD connections work, I believe that the
      [...]

      >I think. I may be wrong.

      Ignoring mounting and EMI/RFI, "dual" modules placed in the AB slots
      will work correctly in either BA23/BA123 or BA2xx/BA4xx.  The "quad"
      Q22-bus modules are the problematic ones.

      The CD (lower) section of the BA2xx and BA4xx is not a Q22-bus, it's
      part of the PMI CPU-memory interconnect bus.  Shorting the CD-PMI
      pins in the position that matches the CD-Q22-bus DMA grant continuity
      pins is not something I'd care to try.

      The last time I was swapping Q22-bus boards between the BA23/BA123 and
      the BA2xx/BA4xx series, I had to cut the DMA grant continuity etch on
      the BA23/BA123 "quad" modules to get them to work in the BA2xx/BA4xx.
      (The fellow that designed the particular module I was working with had
      specifically placed a zero-ohm resistor -- a jumper -- across these
      two pins to make cutting this easy.)

      I don't have the KA630/KA640/KA65x module pinouts handy to check what's
      in that pin position in tbe backplane.  If I can dig up a copy, I'll
      check to see what might happen when those two PMI pins are shorted.

      Steve

  ------------------------------ Opinionative -------------------------------
   Stephen Hoffman, NR EMT-I, WEMT, N1THN        hoffmanxdelta.enet.dec.com
        OpenVMS Engineering, Digital Equipment Corporation, Nashua NH

     _________________________________________________________________


   From:   DRKCLU::IVAX         "Mark Iline - Info-VAX account" 23-MAR-1995 \
           12:42:36.99
   Subj:   Re: Sticking MV II cards into a MV3400

   Hi Steve.

   >   Ignoring mounting and EMI/RFI, "dual" modules placed in the AB slots
   [...]
   >   check to see what might happen when those two PMI pins are shorted.

   I've got a fair understanding of the problem. I'm not 100% sure, but my
   understanding is that the pins on the CD side of the backplane are simply
   connected such that the top contacts connect to the bottom contacts on the
   slot above, and so forth.

   I think this originally came about for dual card controllers like the RLV11
   (the RLV211 was a single card, supporting 22 bits) (I think), so that the
   two cards didn't need an 'over the top' connector. The same mechanism
   allows LMI (uVAX II memory) to have its private memory bus (although it
   still needs a ribbon cable), and PMI (11/83 ?), in which the memory cards
   sit above the CPU card, whereas the Q-bus cards are below.

   If I'm right about the CD wiring, as long as the CD slots either side of
   the non-skunked quad height card are free, you should be ok, since the
   grant tracks aren't connected to anything.

   Mark

   Mark Iline      systemmeng.ucl.ac.uk
   Dept Mech Eng, University College, London. UK

     _________________________________________________________________


   From:   SMTP%"leichterlrw.com" 23-MAR-1995 14:08:03.12
   To:     Info-VAXMvb.Saic.Com
   CC:
   Subj:   Re: 100% CPU usage slows down other processes

        > [I wrote:]
        > Short of giving the real CPU hogs lower priorities, there isn't much
        > you can do on a V5.5-2 system.  V6.0 adds support for a class
        > scheduler, which allows you to assign processes to different
        > classes, each of which can only get some pre-defined fraction of the
        > available CPU time.  For example, you could assign processes that
        > are using a great deal of CPU time to class B, and all others to
        > class A, and the specify that class B is to be allows at most 70% of
        > the CPU.  All the CPU-bound processes together will share the 70%
        > give to class B, while 30% will remain available for everyone
        > else.  Again, however, this is new to V6.0.  (Actually, the
        > mechanism has been there for quite some time, but support and
        > documentation are new to V6.0.  I don't know if the newly-documented
        > $SCHED system call actually works the same way in V5.5.)

        I'm suprised this thread didn't continue with more discussion on the
        above statement. Can you tell me where this class scheduler is
        maintained from? What documentation should I be looking at to utilise
        this V6.0 feature?

   The System Services manual, what else?  The basic operational model is
   that a privileged process first uses $SCHED (CSH$_SET_QUANT function)
   to establish a group of classes and assign class quanta to them.  As
   processes in different classes run, VMS will deduct the time they use
   from their class's quantum.  When a class's quantum reaches 0, no
   processes in that class will be scheduled until $SCHED is used to
   assign more time.

   Then the privileged process asks VMS to tell it about all processes
   (CSH$_READ_ALL) or only about processes that have not been assigned a
   scheduler class (CSH$_READ_NEW), and if it wishes it assigns them
   (CSH$_SET_CLASS).  Once it's done, the process can request that an AST
   be delivered when new processes enter the system (CSH$_SET_ATTN_AST).
   (It must also arrange to use CSH$_SET_QUANT periodically to refresh
   the times allocated to the various processes.  As a safety "dead-man"
   switch, VMS will disable class scheduling if too long a time -
   normally 30 seconds, but this is settable - goes by without the use of
   the CSH$_SET_QUANT function.)

   I've seen an example of a simple class scheduler, but I'm not sure
   where.  It may even be in the VMS V6.0 SYS$EXAMPLES; more likely, it
   appeared in a Digital Systems Journal article within the last 6 months
   or so.  The code examples from those articles are available on line
   somewhere, perhaps from Hunter Goatley's site, but I'm not sure.

   By the way, someone pointed out to me that the code for the scheduling
   facility was not shipped before V6.0.  (I seem to recall that it was
   being used experimentally within DEC several versions earlier, but
   probably only on specially-built development versions of VMS.)

                                                           -- Jerry

     _________________________________________________________________
                                      

   From:   SMTP%"hoffmanxdelta.enet.dec.com" 23-MAR-1995 14:59:50.98
   Subj:   Re: Sticking MV II cards into a MV3400

    Hello Mark Iline,

   >>   The CD (lower) section of the BA2xx and BA4xx is not a Q22-bus, it's
   [...]
   >>   check to see what might happen when those two PMI pins are shorted.

   >I've got a fair understanding of the problem. I'm not 100% sure, but my
   [...]
   >sit above the CPU card, whereas the Q-bus cards are below.


    Dual cards are, as I've mentioned, not a problem -- assuming they
    are installed in the AB portion of the BA2xx or BA4xx bus, and
    assuming EMI/RFI is handled.

  >If I'm right about the CD wiring, as long as the CD slots either side of
  >the non-skunked quad height card are free, you should be ok, since the
  >grant tracks aren't connected to anything.

    Various members of the MicroVAX family used *both* the over-the-top
    ribbon cable *and* the CD portion of the backplane to communicate
    with the memory modules.  I *know* the KA650 puts out the main memory
    address on the CD pins on the backplane, and reads/writes the data via
    the over-the-top ribbon cable interconnect.  The memory control lines
    are also present on the CD pins.

    If you're right and the pin on the bottom of one card in the CD fingers
    is daisy-chained -- connected to the pin on the top of the next card
    in the bus, etc., then (with a gap between the modules) you're right,
    the configuration may work as long as no adjacent card(s) also use the
    CD.  I would not want to bet on this, and I would not want to leave
    this system for the next fellow to maintain -- it's too likely that
    a simple subsequent module addition or removal will have rather
    unforseen and puzzling consequences.  And if the card accesses the
    Q-signals bus via the CD pins as I could envision some (mis)designed
    modules doing, all bets are (obviously) off.

    In the particular configuration I were working with, one of the
    requirements was stuffing as many modules as we could into the box,
    and cutting the grant was thus necessary -- since the modules were
    backed up against the memory modules.

    Steve

  ------------------------------ Opinionative -------------------------------
   Stephen Hoffman, NR EMT-I, WEMT, N1THN        hoffmanxdelta.enet.dec.com
        OpenVMS Engineering, Digital Equipment Corporation, Nashua NH

     _________________________________________________________________
                                      

   From:   DRKCLU::IVAX         "Mark Iline - Info-VAX account" 23-MAR-1995 \
           15:38:42.63
   Subj:   Re: Sticking MV II cards into a MV3400

   >>I think this originally came about for dual card controllers like the 
   [...]
   >>sit above the CPU card, whereas the Q-bus cards are below.

   >    Dual cards are, as I've mentioned, not a problem -- assuming they
   >    are installed in the AB portion of the BA2xx or BA4xx bus, and
   >    assuming EMI/RFI is handled.

   Ah, but I wasn't referring to dual *height* cards. The 'dual card' RLV11
   controller was composed of 2 quad height cards that communicated over the
   CD interconnect.

   >    If you're right and the pin on the bottom of one card in the CD fingers
   [...]
   >    modules doing, all bets are (obviously) off.

   Fair point about maintainability.

   I must admit, I'd doubt that any quad height cards that are at all
   recent would access Q-bus lines via the CD slots. There's no point,
   and Q/CD backplanes were common around the time of the (pre-BA23)
   11/23 (in fact probably with DEC supplied 11/03s, precisely because of
   the RLV11. As you've observed, modules were designed to work either in
   the 'serpentine' Q/Q backplanes, or the 'straight down' Q/CD
   backplanes by having only grants on the CD slots, and jumpers to
   disconnect these.

   >    In the particular configuration I were working with, one of the
   [...]
   >    backed up against the memory modules.

   Surely not moving the graphics card on a VSII/RC (5 slot VSII) into a Q/CD
   slot to free up another double height Q-bus slot ;-) ? Naughty people like
   us took the araldite/epoxy out of the other 3 slots.

   Mark

------------------------------------------------------------------------------

   (2e)...and our experiences of moving cards around QBus systems


   Sunday 28th Jan 1996.

   Regarding the problem of fitting cards from a
   MicroVAX-II/VAXstation-II series system into a 3400 we successfully
   managed the following last night.

   Placing a DELQA card into the Q22 (ie A/B) slots of a 3400, a QBUS
   scan from the chevron recognised this card without any problem as did
   VMS 5.5-2.

   More significantly...

   Fitting two Quad height Video Boards (QDSS Base/4 Plane adaptor), ie.
   VCB02, from a VAXstation-II into the Q22-C/D backplane of a VAXserver
   3400.

   Initially on boot without the VR260 (but a VT220) connected we got an
   error ?62 before the KA640 disagnostics completed, we then got a
   "Normal operation not possible" message and then chevron. However we
   managed to do a console boot no problem...and the DECwindows video
   drivers loaded ok.
   
   This problem cleared up when we connected the VR260 though. And it
   booted without bailing out on DIA0: and up she booted... perfectly..

   Ever heard of a VAXstation 3400 ?? Well, she is one now!!

   Note I have read about Q22-C/D problems, esp the unavoidable ones with
   quad height -II cards. However no mods needed to be made to these to
   work. I should note that we fitted the DELQA into the A/B slots
   *before* we fitted the VCB02 if that makes any difference.

   Pity can't fit the old MS630's into the 3400... :-( no that would be
   pushing luck...!!

------------------------------------------------------------------------------
  
   (2f) MicroVAX/VAXstation Memory options


                                 Memory Option Chart
                                       
   
   System              Memory on CPU       No. of Memory Slots Options

   MicroVAX I,         4 MB                4                   2 MB
     MicroPDP 11/73
   MicroVAX I,         4 MB                4                   4 MB
     MicroPDP 11/73
   MicroVAX II (!)     1 MB                2                   4 MB
   MicroVAX II (!)     1 MB                2                   8 MB
   MicroVAX 3100 ()   4 MB                1                   4 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100 ()   4 MB                1                   8 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100 ()   4 MB                1                   12 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100 ()   4 MB                1                   16 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100       8                   3 Pairs             8 MB (2 x 4 MB
     Models 30/40                                               modules)
   MicroVAX 3100 Model 0                   3 Pairs             8 MB (2 x 4 MB
     8085                                                       modules)
   MicroVAX 3100 Model 0                   3 Pairs             32 MB (2 x 16 MB
     80/85                                                      modules)
   MicroVAX/VAXstation 0                   2 Quads             16 MB (4 x 4 MB
     3100 Model 90/95                                           modules)
   MicroVAX/VAXstation 0                   2 Quads             64 MB (4 x 16 MB
     3100 Model 90/95                                           modules)
   MicroVAX/VAXserver  4 MB                3                   8 MB
     3300/3400
   MicroVAX/VAXserver  4 MB                3                   16 MB
     3300/3400
   MicroVAX/VAXserver  4 MB                3                   32 MB
     3300/3400
   MicroVAX/VAXserver  0                   4                   8 MB
     3500/3600/3800/
     3900
   MicroVAX/VAXserver  0                   4                   16 MB
     3500/3600/3800/
     3900
   MicroVAX/VAXserver  0                   4                   32 MB
     3500/3600/3800/
     3900
   VAXstation 3100 () 4 MB                1                   4 MB
     Models 30/38/40/
     48
   VAXstation 3100 () 4 MB                1                   8 MB
     Models 30/38/40/
     48
   VAXstation 3100 () 4 MB                1                   12 MB
     Models 30/38/40/
     48
   VAXstation 3100 () 4 MB                1                   16 MB
     Models 30/38/40/
     48
   VAXstation 3100     0                   8                   4 MB
     Model 76
   VAXstation 3200     0                   2                   8 MB
   VAXstation 3200     0                   2                   16 MB
   VAXstation 3500     0                   4                   8 MB
   VAXstation 3500     0                   4                   16 MB
   VAXstation 4000 VLC 0                   3 Pairs             8 MB (2 x 4 MB
                                                                modules)
   VAXstation 4000     8 MB                3 Pairs             8 MB (2 x 4 MB
     Model 60                                                   modules)
   VAXstation 4000     8 MB                3 Pairs             32 MB (2 x 16 MB
     Model 60                                                   modules)
   VAXstation 4000     0                   2 Quads             16 MB (4 x 4 MB
     Model 90 (##)                                              modules)
   VAXstation 4000     0                   2 Quads             64 MB (4 x 16 MB
     Model 90 (##)                                              modules)


   System              Order No.           Maximum System
                                            Capacity
 
   MicroVAX I,         MSV11-QB            4 MB
     MicroPDP 11/73
   MicroVAX I,         MSV11-QC            4 MB
     MicroPDP 11/73
   MicroVAX II (!)     MS630-BB            16 MB
   MicroVAX II (!)     MS630-CA            16 MB
   MicroVAX 3100 ()   MS42-AB             32 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100 ()   MS42-KA             32 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100 ()   MS42-BA             32 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100 ()   MS42-CA             32 MB
     Models 10/10e/20/
     20e
   MicroVAX 3100       MS44L-BA            32 MB
     Models 30/40
   MicroVAX 3100 Model MS44L-BA            72 MB
     8085
   MicroVAX 3100 Model MS44-DA             72 MB
     80/85
   MicroVAX/VAXstation MS44L-BC            128 MB
     3100 Model 90/95
   MicroVAX/VAXstation MS44-DC             128 MB
     3100 Model 90/95
   MicroVAX/VAXserver  MS650-BH            52 MB
     3300/3400
   MicroVAX/VAXserver  MS650-BF            52 MB
     3300/3400
   MicroVAX/VAXserver  MS650-BJ            52 MB
     3300/3400
   MicroVAX/VAXserver  MS650-BH            64 MB
     3500/3600/3800/
     3900
   MicroVAX/VAXserver  MS650-BF            64 MB
     3500/3600/3800/
     3900
   MicroVAX/VAXserver  MS650-BJ            64 MB
     3500/3600/3800/
     3900
   VAXstation 3100 () MS42-AB             32 MB
     Models 30/38/40/48
   VAXstation 3100 () MS42-KA             32 MB
     Models 30/38/40/
     48
   VAXstation 3100 () MS42-BA             32 MB
     Models 30/38/40/
     48
   VAXstation 3100 () MS42-CA             32 MB
     Models 30/38/40/
     48
   VAXstation 3100     MS44-AA             32 MB
     Model 76
   VAXstation 3200     MS650-BH            32 MB
   VAXstation 3200     MS650-BF            32 MB
   VAXstation 3500     MS650-BH            64 MB
   VAXstation 3500     MS650-BF            64 MB
   VAXstation 4000 VLC MS40-BA             24 MB
   VAXstation 4000     MS44L-BA            104 MB
     Model 60
   VAXstation 4000     MS44-DA             104 MB
     Model 60
   VAXstation 4000     MS44L-BC            128 MB
     Model 90 (##)
   VAXstation 4000     MS44-DC             128 MB
     Model 90 (##)

     Notes

   (#) The MS01-AA and MS01L-AB cannot be mixed in the system with the MS01-CA.

   (^)  The MS02L-AB cannot be mixed in the system with the MS02-CA.

   (!)  The 1MB of memory on the CPU is disabled when two 8 MB modules are 
        installed.

   () Maximum system capacity is obtained by piggy-backing MS42-CA and
       MS42_BA t ogether.(#) The MS01-AA and MS01L-AB cannot be mixed in the
       system with the MS0 1-CA.

   (^)  The MS02L-AB cannot be mixed in the system with the MS02-CA.

   (!)  The 1MB of memory on the CPU is disabled when two 8 MB modules
        are install ed.ximum system capacity

   (##) VAXstation 4000 model 90 minimum memory config. is 16MB.

   (^^) 512 maximum memory can only be obtained by starting with 128 MB,
        otherwise , one memory must be removed.(!!) Memory modules should be
        configured in one, t wo or four like-size modules.

   (*) Upgrades from 32 and 64 MB available. Call for details.


   Creation Date: Sat Oct 14,1995


------------------------------------------------------------------------------
   
   (2g) SCSI Interface for QBUS Product details from external link
        to http://mayflower.nav.com/dbius/qbus.html:

   Lengthy information deleted about non-DEC product -- the file
   containing this information, minus the original marketing
   mumbo-jumbo, can be ftp'd from: 

   ftp.digex.net in /pub/access/rdd/vaxen/sbi-scsi.txt

------------------------------------------------------------------------------
 
   (2h) MicroVAX spd28-16-01.html, Diagnostic Monitor SPD 
        ***IS NO LONGER AVAILABLE***
   
        Does anyone know where this is??? [R.D.D.]

------------------------------------------------------------------------------

   (2i) Performance comparisons between MicroVAX-II and 2000


   From:   SMTP%"leichterlrw.com" 15-FEB-1995 15:42:56.28
   Subj:   Re: MicroVAX-II

      [MicroVAX II vs. MicroVAX 2000 comparisons...]
      I remember a DEC engineer saying at DECUS, that the uVAX II had a 10
      Mbyte/s memory bus, the CPU could use about 6.6 Mbyte/s, and the Q-bus
      about 3.3 Mbyte/s, so it was a nicely balanced system.

      The uVAX II is ~90% the speed of a 780,

      Just to emphasize a point you make at the end: "90%" is an overall
      average.  Since the uVAX II emulated some instructions, anything using
      those would be *much* slower.  Many other hardware-implemented
      instructions were indeed about 10% slower on the uVAX - but some were
      faster, sometimes significantly so.  In particular, CALLS/CALLG were
      sped up considerably, however, its memory is faster.  The 780 has a 
      cache to work around this, whereas the uVAX II hasn't got one.

      Yup.  The 780 is *full* of caches to make up for memory access time
      problems.  The uVAX II manages to run at full speed with only an
      8-byte instruction buffer, as I recall.  The analysis, and its rather
      surprising result, appears in a Digital Technical Journal that talks
      about the design of the chip and the systems built around it.

      Consequently for some applications, such as MSCP serving, the uVAX II
      was potentially better.

      Yes, *if* you put "real" disks on it.  A 780 would probably regain the
      lead when you had *many* disks, since it could support multiple
      controllers and memory adapters.

      I believe Jerry is right in saying that the uVAX 2000's disk
      controller is non-DMA, and therefore processor cycles are used up by
      disk transfers. I think you'll find that quite a few of the non-Q-bus
      systems have non-DMA disk and/or network devices, eg VAX 3400, and I
      suspect quite a few of the low-end AXPs. This isn't necessarilly a bad
      thing (the 3400 DSSI interface is faster than a KFQSA), but, as
      stated, can lead to CPU cycles being consumed.

      Before people re-read their Intro to Computer Architecture books,
      analyze the -2000's disk interface, and complain: In the traditional
      view, there are two kinds of I/O, programmed and DMA.  In programmed
      I/O, the unit of transfer between the CPU and the I/O device is at
      most a few bytes at a time, often just one.  Those few bytes cross
      through an interface that looks to the CPU like a register.  The CPU
      has to repeatedly load or read the register to transfer data.

      In traditional DMA, in contrast, the CPU gives the device the address
      of a large buffer, a count, and says "Go".  The device operates on its
      own and only comes back to the CPU when the transfer is done.

      DMA and programmed I/O are nice conceptualizations, but in the real
      world, there is a much broader spectrum of actual design alternatives.
      In the 730, for example, from the point of view of a program running
      on the CPU, the IDC (Integrated Disk Controller) implemented DMA.
      However, to actually manage the transfers to and form memory, the IDC
      would "borrow" some of the CPU's cir- cuitry (probably mainly the
      memory mapping apparatus).  The only code the CPU ever ran was that in
      the software - but while the IDC was borrowing part of the CPU, code
      execution might stall.  DMA?  Programmed I/O?

      In the case of the -2000's disk controller, the programming interface
      is, I believe, again DMA-like.  However, the CPU is somehow used by
      the controller as part of the transfer process.  I don't know whether,
      again, it's somehow a matter of borrowing part of the circuitry, or
      whether the CPU actually executes instructions hidden in a ROM
      somewhere.

      Then there are fast frame buffers and network devices.  A common
      design for these today uses a block of fast, perhaps dual-ported,
      memory shared between the CPU and the device.  The device can access
      only this special memory; the CPU copies data between "normal" memory
      and the special memory - which is usually mapped into the CPU's
      overall address space - to do I/O.  DMA to the special memory - and
      what to the main memory?

      Lest anyone think the books just haven't caught up with recent
      inovations: Back in the late 1960's, the IBM 1130 had a printer with
      an unusual interface.  This was an 80-column drum printer: A spinning
      drum contained 80 rings, each containing all printable characters.  To
      print at a given column, you had to wait for the right character to
      appear under the head for that column, then trigger the head.

      The printer was closely coupled to the CPU.  80 bytes of memory at a
      fixed location corresponded to the 80 columns.  As each row of
      characters became aligned with the heads, the printer interrupted the
      CPU.  The CPU had to mark the memory locations in which it wanted the
      head to fire, and tell the printer to proceed.  DMA?  Programmed I/O?

      More reasons to beware of inappropriate benchmarks.

      Even more, reasons to beware of attempts to quantify anything with a
      single number, whether derived from a benchmark, clock speed, or
      whatever!

                                                        -- Jerry
     _________________________________________________________________
                                      

   From:   SMTP%"leichterlrw.com" 15-FEB-1995 17:59:06.30
   Subj:   Re: MicroVAX-II

      [MicroVAX II vs. MicroVAX 2000 comparisons...]
      I remember a DEC engineer saying at DECUS, that the uVAX II had a 10
      Mbyte/s memory bus, the CPU could use about 6.6 Mbyte/s, and the Q-bus
      about 3.3 Mbyte/s, so it was a nicely balanced system.

      The uVAX II is ~90% the speed of a 780,

      Just to emphasize a point you make at the end: "90%" is an overall
      average.  Since the uVAX II emulated some instructions, anything using
      those would be *much* slower.  Many other hardware-implemented
      instructions were indeed about 10% slower on the uVAX - but some were
      faster, sometimes significantly so.  In particular, CALLS/CALLG were
      sped up considerably, however, its memory is faster.  The  780 has a 
      cache to work around this, whereas the uVAX II hasn't got one.

      Yup.  The 780 is *full* of caches to make up for memory access time
      problems.  The uVAX II manages to run at full speed with only an
      8-byte instruction buffer, as I recall.  The analysis, and its rather
      surprising result, appears in a Digital Technical Journal that talks
      about the design of the chip and the systems built around it.

      Consequently for some applications, such as MSCP serving,
      the uVAX II was  potentially better.

      Yes, *if* you put "real" disks on it.  A 780 would probably regain the
      lead when you had *many* disks, since it could support multiple
      controllers and memory adapters.

      I believe Jerry is right in saying that the uVAX 2000's disk
      controller is  non-DMA, and therefore processor cycles are used up by
      disk transfers. I  think you'll find that quite a few of the non-Q-bus
      systems have non-DMA  disk and/or network devices, eg VAX 3400, and I
      suspect quite a few of the  low-end AXPs. This isn't necessarilly a
      bad thing (the 3400 DSSI interface  is faster than a KFQSA), but, as
      stated, can lead to CPU cycles being  consumed.

      Before people re-read their Intro to Computer Architecture books,
      analyze the -2000's disk interface, and complain: In the traditional
      view, there are two kinds of I/O, programmed and DMA.  In programmed
      I/O, the unit of transfer between the CPU and the I/O device is at
      most a few bytes at a time, often just one.  Those few bytes cross
      through an interface that looks to the CPU like a register.  The CPU
      has to repeatedly load or read the register to transfer data.

      In traditional DMA, in contrast, the CPU gives the device the address
      of a large buffer, a count, and says "Go".  The device operates on its
      own and only comes back to the CPU when the transfer is done.

      DMA and programmed I/O are nice conceptualizations, but in the real
      world, there is a much broader spectrum of actual design alternatives.
      In the 730, for example, from the point of view of a program running
      on the CPU, the IDC (Integrated Disk Controller) implemented DMA.
      However, to actually manage the transfers to and form memory, the IDC
      would "borrow" some of the CPU's cir- cuitry (probably mainly the
      memory mapping apparatus).  The only code the CPU ever ran was that in
      the software - but while the IDC was borrowing part of the CPU, code
      execution might stall.  DMA?  Programmed I/O?

      In the case of the -2000's disk controller, the programming interface
      is, I believe, again DMA-like.  However, the CPU is somehow used by
      the controller as part of the transfer process.  I don't know whether,
      again, it's somehow a matter of borrowing part of the circuitry, or
      whether the CPU actually executes instructions hidden in a ROM
      somewhere.

      Then there are fast frame buffers and network devices.  A common
      design for these today uses a block of fast, perhaps dual-ported,
      memory shared between the CPU and the device.  The device can access
      only this special memory; the CPU copies data between "normal" memory
      and the special memory - which is usually mapped into the CPU's
      overall address space - to do I/O.  DMA to the special memory - and
      what to the main memory?

      Lest anyone think the books just haven't caught up with recent
      inovations: Back in the late 1960's, the IBM 1130 had a printer with
      an unusual interface.  This was an 80-column drum printer: A spinning
      drum contained 80 rings, each containing all printable characters.  To
      print at a given column, you had to wait for the right character to
      appear under the head for that column, then trigger the head.

      The printer was closely coupled to the CPU.  80 bytes of memory at a
      fixed location corresponded to the 80 columns.  As each row of
      characters became aligned with the heads, the printer interrupted the
      CPU.  The CPU had to mark the memory locations in which it wanted the
      head to fire, and tell the printer to proceed.  DMA?  Programmed I/O?

      More reasons to beware of inappropriate benchmarks.

      Even more, reasons to beware of attempts to quantify anything with a
      single number, whether derived from a benchmark, clock speed, or
      whatever!
                                                        -- Jerry
     _________________________________________________________________
                                      

   From:   SMTP%"Info-VAX-RequestMvb.Saic.Com" 15-FEB-1995 18:26:38.56
   Subj:   Re: MicroVAX-II

      >>I'd always heard it was the other way: the VAXstation/MicroVAX-2000
      >>was slightly faster than the -II.  Both machines use the same CPU, but
      >>the lack of the QBUS overhead in the 2000 gave it a slight advantage.
      >>The difference was quite small - only a few percent.

      >It's a non-trivial comparison.  Both systems used the same CPU chip,
      >and both systems used private paths to memory (PMI on the -II, don't
      >know what, if anything, it was called on a 2000).  The memory paths in
      >both cases should have had no trouble keeping up with the CPU demand,
      >so memory should not be the bottleneck.  On CPU-bound operations,
      >there should be no difference at all.

      I remember a DEC engineer saying at DECUS, that the uVAX II had a 10
      Mbyte/s memory bus, the CPU could use about 6.6 Mbyte/s, and the Q-bus
      about 3.3 Mbyte/s, so it was a nicely balanced system.

      The uVAX II is ~90% the speed of a 780, however, its memory is faster.
      The 780 has a cache to work around this, whereas the uVAX II hasn't
      got one.  Consequently for some applications, such as MSCP serving,
      the uVAX II was potentially better.

      I believe Jerry is right in saying that the uVAX 2000's disk controller
      is non-DMA, and therefore processor cycles are used up by disk 
      transfers. I think you'll find that quite a few of the non-Q-bus 
      systems have non-DMA disk and/or network devices, eg VAX 3400, and I 
      suspect quite a few of the low-end AXPs. This isn't necessarilly a bad 
      thing (the 3400 DSSI interface is faster than a KFQSA), but, as stated,
      can lead to CPU cycles being consumed.

      More reasons to beware of inappropriate benchmarks.

   Mark Iline      systemmeng.ucl.ac.uk
   Dept Mech Eng, University College, London. UK

     _________________________________________________________________
                                      

   From:   SMTP%"seanobanioaol.com (SeanOBanio)" 15-FEB-1995 20:38:49.50
   Subj:   Re: MicroVAX-II

      Jerry Leichter  said, in part, about I/O

      >As I recall - and this is from a *long* time ago - one way the price on
      >the 2000's was kept down was to "borrow" the CPU to do some of the work

      You are correct about the 730, but not the MV2000.  The real problem,
      as I see it, is that the 2000 has no scatter/gather map for DMA.  The
      only DMA device is the LANCE-based Ethernet adapter (DESVA?): all
      other I/O requires a MOVCx instruction to get the data into memory.
      After that, the II and the 2000 should be the same, since they both
      use 50-ns micro-cycle timing (the same as the CPU) and require 4
      cycles to complete a transfere between the CPU and memory.

      About the 14MB memory limit, Clearpoint (remeber them?) had a 16MB card
      that had a PAL chip to disable the 2MB memory on the mother board.

      To bad Digital doesn't support the NCR SCSI chip as a SCSI port: this
      would be a cheap way to get around the RD54 two disk limit on the MFM
      control chip.  I use Priam 519 disks, which are plug compatable with
      the Maxtor disks that the RD54 was based on.  The onboard formater had
      no problem.  But you can only connect two MFM drives, no mater what
      you do.

      Sean O'Banion

      Professional OpenVMS System Manager, Pleasanton, CA
      Actualy, I do know everything...I'm just not paid enough to reveal all!

     _________________________________________________________________
                                      

   From:   SMTP%"Info-VAX-RequestMvb.Saic.Com" 16-FEB-1995 07:32:52.50
   Subj:   Re: MicroVAX-II



   In article , Jerry Leichter  writes:

   >In the case of the -2000's disk controller, the programming interface
   >is, I believe, again DMA-like.  However, the CPU is somehow used by
   >the controller as part of the transfer process.  I don't know whether,
   >again, it's somehow a matter of borrowing part of the circuitry, or
   >whether the CPU actually executes instructions hidden in a ROM
   >somewhere.

   The -2000's disk controller can DMA into a small static RAM buffer.
   The CPU has to move the data between that buffer and main memory.

   In contrast, the Ethernet interface on the -2000 is quite nice: the
   Lance chip has access to the entire 16MB memory space of the machine.

--
----------------+------------------------------------------------------
Roger Ivie      | Never underestimate the bandwidth of a
iviecc.usu.edu |     truckload of tapes


------------------------------------------------------------------------------
 
   (2j) MicroVAX-2000/3100 Communication Controllers details


   Summary of MicroVAX Communications Controllers


   The following table summarizes the features of Digital's MicroVAX 2000 and
   MicroVAX 3100 communications controllers.

   MicroVAX 2000 and MicroVAX 3100 Communications Controllers


                      DHT32           DST32           DSH32(6)        DSH32
   Type            Asynchronous    Synchronous     Asynchronous    Synchronous

   Number of Lines 8               1               8               1
   Direct Memory   No              No              No              No
   Access (DMA)(1)
   Maximum Speed   38.4 Kb/s       19.2 Kb/s       38.4 Kb/s       19.2 Kb/s
   (consult SPD)(2)
   Software        DECnet-VAX(5),  DECnet-VAX(5),  DECnet-ULTRIX,  VAX P.S.I.,
   Support         DECnet-ULTRIX   VAX P.S.I.,     DECnet-VAX      VMS/SNA,
                                   VMS/SNA,                        DECnet-VAX,
                                   DECnet ULTRIX,                DECnet ULTRIX,
                                   ULTRIX WAN                      ULTRIX WAN
                                   Device Drivers                Device Drivers


Operating       VMS, ULTRIX     VMS, ULTRIX     VMS, ULTRIX     VMS, ULTRIX
System Support
MultiCPU        No              No              No              Yes
Access(3)
Modem           No              Full            No              Full
Control(4)
Primary Buying  EIA-423-A       Low-cost        Adds 8 lines
Reason          asynchronous    connection      and a low-cost
                communications; to wide area    connection to
                adds 8 more     network         wide area network
                lines to
                MicroVAX 2000
                system's standard
                four lines

   1. DMA is the ability to move multicharacter messages between a
      communication line and CPU memory without interrupting the CPU. This
      capability yields higher performance.

   2. Actual device speed and throughput depend on current Digital operating
      system, system configuration, and applications.

   3. MultiCPU Access is the ability to send a message directly to two or more
      CPUs without routing the message through another CPU.

   4. Modem control refers to the number of signals available to control
      modem functions on U.S. and European modems. Full modem control
      includes nine to eleven signals. Limited modem control is five
      signals. No modem control means only send and receive signals are
      present for each line.

   5. DECnet-VAX currently supports these devices with certain line and
      speed configuration restrictions. Refer to SPD 25.03 for more
      information.

   6. DEC Multicontroller 581.

------------------------------------------------------------------------------

   (2k) Misc popular questions/answers from Prof. Dave Miller of Bemidji
        State Uni.


   From systemBEAVER.Bemidji.MSUS.edu Sun Jan 28 00:11:08 GMT 1996
   Received: from BADGER.BEMIDJI.MSUS.EDU (BADGER.BEMIDJI.MSUS.EDU \ 
             [199.17.178.141]) by ribble.csc.liv.ac.uk
             (8.7.3/LUCS-DTS-2.1R) with SMTP id AAA11218; Sun, 28 Jan 1996 \
             00:11:05 GMT
   Received: by BEAVER.Bemidji.MSUS.edu (MX V4.1 VAX) id 3; Sat, 27 Jan 1996
             18:10:56 CST
   Date: Sat, 27 Jan 1996 18:10:55 CST
   From: Dave Miller BEAVER.Bemidji.MSUS.edu>
   To: edwardcsc.liv.ac.uk
   Message-ID: <0099D06B.43A8483A.3BEAVER.Bemidji.MSUS.edu>
   Subject: mVAX FAQ
   Status: RO

   Super idea!

   And since I'm still in the dark ages -- a mVAX cluster is our primary
   computing resource -- I can add some info to this.

   1. FAQ. How do I set up a system console on a mVAX 3100?
      Ans: There is a little switch on the back - you must reach it with
      a screwdriver. Push it UP then connect a VT to the printer port.

   2. FAQ. How do I set up a system console on a VS 2000?
      Ans. You have to make a special cable. (I've got the pinouts here
      someplace ... )

   3. FAQ. What is a VR 290?
      Ans. A 21" low resolution color monitor that can be used as an
      8-plane Motif display. $85 (as of 1/96) You will also need a graphics
      card (for a mVAX 3100)

   4. FAQ. What are the diagnostic displays F..E..D..C.. etc. all about.
      Ans. (is this the kinda stuff you want to post??)

   5. FAQ. What rev level os required to put 14megs in VS 2000.
      Ans. 1.3 (I think .. gotta boot one to know for sure!)
   
   6. FAQ. What should the VS 2000 proms say on them for rev 1.3?
      Ans. (I've got that in a book at work.)

   7. FAQ. Does a VS 2000 have a SCSI bus?
      Ans. No, but a mVAX 3100 does.

   8. FAQ. What is the largest disk I can put on a mVAX.
      Ans. The system disk is limited to 1 gig (there is a addressing
      limitation in the boot prom.) Non-system disks are limited to 8 gigs.

   9. FAQ. What brand disks can I use on a mVAX.
      Ans. Besides Digital, I've used Seagate. (I think others will work,
      too.) However, depending on OVMS version, you may need a patch. (I
      think this is the rule ...) Prior to 6.0, no problem. 6.0, 6.1 need a
      patch.

   Furthermore ...

   I have manuals for VS 2000, VAXstation 3100, and mVAX 3100.

   I have shiny "configuration" manuals for mVAX 3100/10/20/40/?

   //----------\|/------\\    Dave Miller.
   ||      /\  -X-      ||    Professor, Computer Science.
   ||     /  \ /|/\     ||
   ||    /    \ /  \    ||    SYSTEMBEAVER.Bemidji.MSUS.EDU
   ||   /      \    \   ||
   ||  /________\____\  ||    1500 Birchmont Dr. NE
   ||      ||    ||     ||    Bemidji State University
   \\------||    -------//    Bemidji MN, 56601

------------------------------------------------------------------------------ 
   
   (3l) Musings on the early -II development by Ed Bailey as well as some
        VS2000 stuff


   From edpigdog.niehs.nih.gov Tue Jan 30 17:10:09 GMT 1996
   Received: from pigdog.niehs.nih.gov (pigdog.niehs.nih.gov [157.98.9.236])
             by ribble.csc.liv.ac.uk
             (8.7.3/LUCS-DTS-2.1R) with ESMTP id RAA03918; Tue, 30 Jan 1996 \
             17:09 :53 GMT
   Received: from pigdog.niehs.nih.gov (localhost [127.0.0.1]) by \
             pigdog.niehs.nih.gov (8.7.1/8.7.1) with SMTP id MAA20717 for \
             csc.liv.ac.uk>; Tue, 30 Jan 1996 12:08:48 -0500
   Sender: edpigdog.niehs.nih.gov
   Message-ID: <310E50A0.25D94F90pigdog.niehs.nih.gov>
   Date: Tue, 30 Jan 1996 12:08:48 -0500
   From: "Edward C. Bailey" pigdog.niehs.nih.gov>
   X-Mailer: Mozilla 2.0b6a (X11; I; Linux 1.3.32 i586)
   MIME-Version: 1.0
   To: edwardcsc.liv.ac.uk
   Subject: uVAX II stuff...
   X-URL: http://www.csc.liv.ac.uk/users/edward/mvax_faq.html
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   Status: RO

   Hello,

           Nice FAQ!  I noticed you mention the VAXstation II with the QVSS
   graphics board.  This is a monochrome unit, unaccelerated, and all in
   all not much fun.  A much nicer VAXstation II would be one with the QDSS
   (sometimes called "dragon") board.  This was an accelerated color unit.
   My memory is a bit fuzzy, but I think it came in 4-bit and 8-bit color
   depths (not sure if this was an add-on card or different boards).  The
   dragon board was available, if not when the QVSS was, then shortly
   thereafter...

   There was something called a VAXstation II/RC, which was a BA23-based
   VAXstation II with half the backplane slots filled with epoxy.  The idea
   was to sell the 'RC at a steep discount, secure in the knowledge that it
   couldn't be expanded into a system that would eat into normal MicroVAX
   II profits.  Shortly after the 'RC came out, DEC had a run on
   replacement BA23 backplanes; the cost of replacing the backplane was a
   small percentage of the price delta between the 'RC and the regular 'II.
   The 'RC went away shortly thereafter...

   On the VS2000, if you have the color display adapter, it is a seperate
   board.  The mono display adapter is part of the mainboard.  So, when the
   color adapter board is installed, you get color.  Why?  Because you have
   a special cable that sends the color signal to your color monitor.  BUT,
   the pins used by the monochrome card are not used by the color card, so
   it is possible to make a special connector that fits in between the
   color cable plug and VS2000's video connector, and bring the monochrome
   signals out to a VR260 (or other mono monitor).  As I recall, I had to
   manually configure the card via sysgen, and there was a DECwindows
   startup command procedure that needed to be hacked a bit to run the X
   server on *two* screens, but it did work well once set up.  The mouse
   would drop off the right side of the color monitor, and appear on the
   left side of the mono monitor.  I ran text-based stuff on the mono
   monitor, and left the color one for graphics.  Quite nice!

   This trick also worked for a VS3100 I had, but I can't recall the model
   number.  In fact, the cable I made for the VS2000 worked on the '3100,
   too...

   Let's see...  I originally had a BA23-based uVAXII, and wanted to put a
   couple extra RD53s on it (it already had an RD54 system disk).  I got an
   RQDXE card, bulkhead, and external cable, and a surplus dual "floppy"
   box/powersupply from a Univac.  I was able to get the schematics for a
   "Leprechaun" box (the external RD5x), and was able to make the
   appropriate cabling for the drives.  This included a little chunk of
   perfboard with a few resistors and transistors, and some frontpanel
   switches and LEDs to do the ol' online/offline/write protect thing.  As
   I recall, the circuit was a simple transistor with a pull-up resistor on
   the collector.  A friendly Field Service person can get the 'fiche with
   the schematics.  I also recall there was a little (1/4) Q-bus card in
   BA123 cabinets than can be used to control multiple drives in a BA23,
   but it is ugly (ribbon cable hanging out the back, etc.

   I think that's about all I can remember.  Well, best of luck with your
   FAQ!
  
                                   Ed
   --
   Ed Bailey, Information Systems and Networks
   (contracted to: National Institute of Environmental Health Sciences)
   2327 Englert Drive.
   Suite 200
   Durham, NC 27713
 
    Internet: baileyniehs.nih.gov
      BITnet: BAILEYNIEHS.BITNET
       Voice: (919)361-9422, extension 239
        FAX: (919)544-6642

==============================================================================

   (3) MicroVAX/VAXstation-2000 specifics

------------------------------------------------------------------------------
 
   (3a) MicroVAX-2000/VS-2000 [14]Technical Specs and Misc stuff
   
   > I have just been given a VS-2000

      I doubt if many people actually buy them nowadays.  I had to pay the
   shipping on mine ($50), and I invested another $50 in a 4MB memory
   board.  (It came with a 2MB board for a total of 4MB.  I thought that
   the other 2MB would reduce the page faults.  They probably do, but not
   enough.  I'm always on the lookout for a bargain 12MB board.)

   > I think 8mb RAM

      Possible.  The power-on tests should actually tell you, although
   perhaps a little cryptically.  If I weren't using mine at the moment, I
   could tell you where to look.

   > and an RD54

      Good.  This will actually hold VMS V5.5-2 with DECwindows and a
   compiler or two (although just barely).  I have a second RD54 in an
   external box (similar to the one for the TK50Z) which I use for a page
   file and my data.

   > it also has a graphics adaptor

      No monitor?  Mine is a VR260 (monochrome, not even grayscale).

   > and a scsi-tape expansion unit

      Also good.  This gives you a way to load software.  Forget about
   trying a SCSI disk there, unless you enjoy lost causes.

   > I need to get hold of a VT-220 as well.

      That should be relatively easy.  If you want to use the serial port
   as a console (instead of the video port), you may need to use a cable
   equivalent to a DEC model BCC08.  It has a couple of lines tied together
   to tell the system to use that port as the console.  The simpler cable
   (BCC05) lacks the extra wire, and is used for a serial printer (which
   does not act as the console terminal).  Someone else has posted the
   actual 9-pin-to-25-pin connections, so if you ask, you can probably get
   them.  I have the cables, so I did not save the data from the posting.
   
   > Can anybody point me to where I can find more information about this
   > machine?
   
      I collected the following data from the Digital Electronic Store a
   while back while I was trying to figure out why I could not get the
   normal mu-VAX diagnostics to boot on my system.  (Answer: the only
   diagnostics for the VS/mu-VAX2000 are those built-in to the ROMs.)  I
   hope you find this material useful, or at least interesting.

   --
   Steven M. Schweda                  (+1) 612-785-2000 ext. 16  (voice)
   Provis Corporation                 (+1) 612-785-2100  (facsimile)
   5251 Program Avenue  #100          smsprovis.com  (e-mail)
   Mounds View, MN  55112-4975

                                  ---*---

   MICROVAX 2000 SPECIFICATIONS

   PARAMETER                                   VALUE          rev date:7/6/89
   ===========================================================================
   Relative CPU performance (VAX780 = 1.0) > .9
   Technology                              > NMOS
   Number of processors                    > 1
   Maximum memory support                  > 14MB
   Memory type                             > parity

   Mass-storage Capacity
   Max. Local 4-port Disk Controllers      > 2
   Max. local Disk Capacity (formatted)    > 318MB
   VAXcluster I/O Servers (HSCs)           > N/A

   I/O Bus Capacity
   Maximum I/O throughput MB/Sec.          > 3.3 MB/s
   Bus Type                                > Busless
   
   Communications
   LAN Support                             > Optional
   Ethernet Adapters                       > Optional

   Expansion
   CI VAXcluster System Support            > N/A
   Ethernet VAXcluster System Support      > Optional
   CPU Upgrade Kit                         > N/A

   System Software                         > VMS, ULTRIX-32

   Processor Features
   Floating Point accelerator (F,D,G,H)    > standard
   Floating Point & CIS                    > N/A
   Cache size                              > N/A
   Cache Cycle time (ns)                   > N/A


   Space/Power Requirements
   CPU Enclosure/Square feet               > MicroVAX 2000 entry level box=1.0
                  Expansion:                 MicroVAX 2000 expansion box = 1.0
   Power (Watts)                   > 160

   TYPICAL SYSTEM
   Part Number:                 DH-625N1
   Configuration:               MicroVAX 2000 CPU
                                4MB Memory
                                RD32 42MB Disk
                                RX33 Floppy


   Floor Space (sq ft):         1.0
   Power (Watts):               160


                               ---*---

   DESCRIPTION

   The entire set of diagnostic functionality for the MicroVAX 2000 and
   VAXstation 2000 is integrated into the system's ROM based
   functionality. The following is a description of that functionality
   and is described in three parts.

   Part I describes functional diagnostic tests that are automatically
   invoked each time the system is powered on. Part II describes
   additional diagnostic tests and maintenance utilities that can be
   invoked by the customer. Part I and II diagnostic functionality are
   protected by copyright and are not subject to licensing.  Part III
   describes Digital Equipment Corporation, Field Service diagnostic
   tests and maintenance utilities that require a Diagnostic Software
   License and service maintenance package in order to invoke and
   execute.

   Part I - Functionality Executed On Power-Up

   Functional tests are run on each system power-up that check basic
   system hardware operation. The console display terminal will show a
   hexadecimal count down beginning at "F" and counting down to ``1''.
   Tests are performed on power-up in the following sequence:

   ^ Base video subsystem tests (VAXstation 2000 only)
   ^ Time of Year Clock
   ^ Battery/NVR tests
   ^ Serial line controller tests
   ^ Memory tests
   ^ Memory Management Unit test
   ^ Floating Point Unit test
   ^ Interval Timer test
   ^ Disk controller test
   ^ Tape controller test
   ^ Interrupt controller/System I.D. ROM tests
   ^ Daughter module option tests

   NOTE: Daughter modules installed in the system carry their own
         diagnostic code that is loaded, invoked, and executed from 
         the main system ROMs.

   Part II - Extended Diagnostics/Maintenance Utilities Available to 
             the Customer

   After completion of the power on tests described above, the customer
   may elect to invoke one of several additional tests or maintenance
   utilities.  These can be executed from the system monitor prompt (>>>)
   utilizing the following ``TEST'' commands:

   TEST 0 - Invokes the customer runnable system excerciser. This test
   executes a serial string test of all devices in the system.  After
   serial device testing has completed, a concurrent device test is
   executed. The test automatically configures the test based on the
   system's hardware configuration and will test all devices present.
   This test runs for two test passes and concludes with a summary table
   of test results.

   TEST 50 - A utility that displays the hardware configuration of
   the system. It displays a listing of all functionality present
   along with status of each device on the last diagnostic executed.
   Additionally, this display identifies the current revision of
   firmware in the system as well as the system I.D. number (used as
   the system's hardware address when networked).

   TEST 51 - Allows the user to define a default boot device for
   automatic bootstrapping of the system.

   TEST 52 - Allows the user to set default boot flags to be used by the
   operating system during boot operations.

   TEST 53 - Allows the user to set default recovery action flags used by
   the system during power up and also used by the system if an error is
   detected with the operating environment.

   TEST 54 - Displays a language inquiry menu on the console device
   (VAXstation 2000 only) to allow the customer to select the
   appropriate keyboard type based on the country keyboard in use.
   On MicroVAX 2000, this function is accomplished through the
   language set-up utility that is part of the console terminal.

   TEST 61 - Sends a full screen of E's to the console monitor display
   (VAXstation 2000 only) allowing a quick check of the monitor's
   linearity adjustments.

   TEST 62 - Sends a full white screen to the console monitor display
   (VAXstation 2000 only) allowing a quick check of the monitor's
   raster as well as a check of the video controller's display memory.

   TEST 70 - Allows the customer to format hard disk drives and RX33
   floppy diskettes. RX50 diskettes need not use this utility as they
   come preformatted. If formatting a non-Digital Equipment
   Corporation hard disk drive, this utility goes into a query mode
   thus allowing the customer to enter drive parameter data prior to
   actually performing the format operation.
 
   Note:  Formatting destroys all user data on the disk or diskette
          being formatted.

   TEST 71 - A disk verifier utility. This utility does a
   non-destructive test of hard disk formats to search for new bad
   blocks on the media since operating system installation and
   identifies any new bad blocks to the customer. This utility is for
   use with hard disks only.

   TEST 90 - A utility that is used with systems that are connected
   in a network configuration. This utility, when invoked, puts the
   system in a test mode to provide loopback and system I.D. support
   to network level diagnostics run from a host or boot node. Working
   in combination with network level excercisers, this utility assists
   in verifying the system's network hardware/firmware interface is
   correctly functioning.

   TEST 80000050 - A utility that displays all system firmware
   revision levels by function (i.e. self test, bootstrap code,
   console code, etc.).

   Part III - Extended Diagnostics/Maintenance Utilities for Digital Equipment
              Corporation Field Service Personnel and Licensed Customers

   This section describes diagnostic functionality that is proprietary to
   the Digital Equipment Corporation Field Service and Support
   organizations. This series of routines require the use of a special
   hardware key to invoke and execute.

   TEST 60 - A utility that displays a circle/crosshatch pattern on
   the console monitor (VAXstation 2000 only). It is used by service
   personnel to check/adjust monitor linearity and aspect ratio.

   TEST 72 - A utility that writes a special key on scratch floppy
   diskettes. After running a floppy diskette through this utility,
   the diskette can then be used with the Field Service system
   excerciser to do write testing of the floppy diskette subsystem.
   Floppy diskettes used with the system excerciser that do not have
   this special key written on the media will do a read test only.

   TEST 73 - A utility that writes a special key on a scratch TK50
   COMPACTape. After running the COMPACTape through this utility,
   the cartridge can then be used with the Field Service system
   excerciser to do write testing of the TK50 subsystem. Cartridges
   used with the system excerciser that do not have this special key
   written on the media will do a read test only.

   TEST 101 - Executes the Field Service mode system excerciser. This
   test excercises each device once sequentially and then
   excercises all devices concurrently. This sequence is executed
   for two complete passes of all system devices present in the
   configuration. Loopback connectors and test media are required to
   optimize test coverage with this routine. This test automatically
   stops after two complete passes and displays a test summary.

   TEST 102 - Executes the Field Service mode system excerciser. It
   excercises all devices in the system configuration in the same
   sequence as described for Test 101. However, when Test 102 is
   invoked, the sequence is repeated continuously until the user
   types CONTROL/C at the system console. When CONTROL/C is typed,
   the test terminates at the conclusion of the current test
   pass and displays a test summary. Note that the user must allow
   this test to run for at least two complete passes before typing
   CONTROL/C.

   TEST 80000106 - Allows the Field Service Engineer to select
   individual device tests from the total test used in Test 102
   described above. Whichever device tests are enabled and
   executed run in a continuous loop until CONTROL/C is
   typed at the system console. As with Test 102, the user must
   allow this test run for at least two complete passes before
   typing CONTROL/C.


   HARDWARE REQUIREMENTS

   The above described diagnostic functionality runs on a minimum system
   hardware configuration consisting of a valid console device, an H7848
   power supply, and a KA410 system module (includes 2 Mbytes of RAM
   memory).


   OPTIONAL HARDWARE

   Ethernet Controller (comes standard with all VAXstation 2000 systems)

   2 Mbyte Memory Daughter Module
   4 Mbyte Memory Daughter Module
   6 Mbyte Memory Daughter Module
   12 Mbyte Memory Daughter Module


   SOFTWARE REQUIREMENTS
 
   None


   SOFTWARE WARRANTY

   THIS PRODUCT IS PROVIDED ``AS IS'' WITHOUT ANY WARRANTY OF ANY KIND, EITHER
   EXPRESS OR IMPLIED.


   ORDERING INFORMATION

   The Single-use Licensed diagnostic package is furnished under the
   licensing provisions of DIGITAL's Standard Terms and Conditions which
   provide, in part, that the Software and any part thereof may be used
   on only the single CPU on which the software is first installed, and
   may be copied, in whole or in part (with the proper inclusion of
   DIGITAL's copyright notice and any proprietary notices on the
   software) for use on the same CPU.  You will need a separate license
   for each CPU on which you will be using the product (except as
   otherwise specified by DIGITAL).  Then, Materials and Service Options
   are selected to utilize the product effectively.  The License options
   are described below.


   ORDERING INFORMATION

   ZNAGX-UZ  MicroVAX 2000/VAXstation 2000 End-User License Only
   ZNAGX-HW  MicroVAX 2000/VAXstation 2000 Service Maintenance Package


   LICENSE OPTIONS

   For your first installation of this software product you must purchase
   as a minimum:

   ^ Single-Use License Option

   The single-use license gives you the right to use the PART III extended
   diagnostics/maintenance utilities on a single CPU.


   ^ Distribution and Documentation (Service Maintenance Package)

   The Distribution and Documentation Diagnostic Package provides the
   Special Hardware Key (Maintenance Guide, blank media, loopback and
   Ethernet connectors) to operate the Part III Extended diagnostics.
   You must have, or order, a Single-Use License to obtain this option.
   You will need this option to install and use the Part III Extended
   diagnostic software.


   Miscellaneous Options

   Maintenance Documentation Service (MDS) - Microfiche documentation library

   MD-VAX     Maintenance Documentation and Diagnostic Listings for VAX
              Systems (Library Only)
   MD-VAX-R   Subscription Update Service for MD-VAX
   MD-VAX-D   Maintenance Documentation for VAX systems (Library Only)
   MD-VAX-DR  Subscription Update Service for MD-VAX-D
   MD-VAX-L   Diagnostic Listings for VAX Systems (Library Only)
   MD-VAX-LR  Subscription Update Service for MD-VAX-L
   DEC-O-LOG  Microfiche
   MD-MFDOL-00  Field Change Order notification service for all systems
                (initial subscription includes one year of updates).
   MD-MFDOL-R   Subscription Update Service for MD-MFDOL-R (Renewal
                of initial subscription).


   September 1988

------------------------------------------------------------------------------ 

   (3b) More detailed specs on the 2000 from CrazyCam, DECUS Australia.


   From MANSONdecus.org.au Wed Jan 31 20:04:34 1996
   Return-Path: MANSONdecus.org.au
   Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84]) \
             by mailspool.liv.ac.uk (8.6.12/8.6.6-LIV-CSD) with ESMTP id \
             UAA04111 for mspool2.liv.ac.uk>; Wed, 31 Jan 1996 \
             20:04:33 GMT
   From: MANSONdecus.org.au
   Received: from decus.org.au (actually SMIFFY.DECUS.ORG.AU) by mail.liv.ac.uk
             with SMTP (PP); Wed, 31 Jan 1996 19:49:50 +0000
   Received: from decus.org.au by decus.org.au (PMDF V4.3-7 #6878)
             id <01I0OTTZA2288Y50XXdecus.org.au>; Thu, 1 Feb 1996 \
             06:36:26 AEST
   Date: Thu, 01 Feb 1996 06:36:25 +1000 (AEST)
   Subject: Re: FAQ!
   To: edwardliverpool.ac.uk
   Message-id: <01I0OTTZBEAA8Y50XXdecus.org.au>
   X-VMS-To: IN%"edwardliv.ac.uk"
   MIME-version: 1.0
   Content-transfer-encoding: 7BIT
   Status: RO
 
   Eddy,

           hi there.

   >Good to hear from you!!! I'd really appreciate the VS2000 stuff, I'll
   >put it up as soon as I get it. Lets hope we can make this site good, any
   >other contributions welcome :-)

          regards,
                  CrazyCam


                                  ===*===

   The VAX in a wine cask. MicroVAX 2000 / VAXstation 2000

   This model is very nearly a portable VAX and, for a home machine, it's
   extremely nice. The enclosure(s) are neat, inoffensive, and fit on a
   reasonably strong book-shelf.

   Introduced in January 1987, the MicroVAX 2000 was a real scale model
   VAX, naturally, it was/is fully compatible with all the other VAXen,
   but with dimensions, for the main box, of 33cm x 29cm x 14cm, it's
   absolutely perfect for the VAX enthusiast with limited space!  By the
   way, the main box weighs in at a surprising 12.7 kilos, so be careful
   the first time you try to pick one up.

   The 2000 uses the same processor as the MicroVAX II, rating at 0.9 of
   a VUP, and has 2 meg of memory on the system board. The standard box
   has only one device bay, into which you can fit one full-height hard
   disk, typically RD53 or RD54, or, by using a half-height drive such as
   the RD32, or RD33, you can also mount an RX33 floppy drive into the
   bay.  The other thing which can be found, especially in the VAXstation
   2000's, is a "dummy" load card. The power supply is slightly smart,
   and, if it doesn't find a disk or two to play with, won't work unless
   this "dummy" load is connected. The VAX -stations were quite often
   disk-less, booting across ethernet.

   The system board has 2 meg of memory on it, and there is space for one
   extra memory board. Digital produced 4meg,8meg and 12meg boards for
   the 2000 series, and third-party memory people also produced 8meg and
   12 meg boards. The largest capacity memory board for a 2000 is the
   Clearpoint 16 meg board. This board is a trap, since it appears that
   part of the installation kit for the board was an updated ROM for the
   power-up self- testing, to disable the testing of the memory on the
   system board. Thus, if you find a 16 meg board, putting it into a 2000
   without this ROM update will give you a non-working system. (It won't
   get past its memory test!)

   A couple of options were available for ethernet connections, the
   "tail" for thin-wire at the back, does not "prove" ethernet
   capability. The tail is on the systems board, but you have to have the
   seperate ethernet card fitted, before the connection does anything.
   There was also an add-in thick-wire ethernet connection, which fitted
   at the back, above the power socket, near a _very_ small selector
   switch. Many people have wasted many hours trying to get a reluctant
   2000 to talk on the ethernet, only to find the selector set for
   thick-wire, and they're using thin.

   For the big, hairy-chested 2000's with extra disk and/or tape, the
   "pizza- box" was screwed onto the bottom of the systems box, adding
   4cm to the depth of the box, and providing a D 50 pin connector and a
   SCSI looking connector. The 50 pin job, allowed an extra box (BA400, I
   think?) to be added with another hard disk drive, usually an RD53 or
   54, while the SCSI thingy was for the cable to the TK50-Z, also in
   another box. (A good 2000 configuration also acts as book-ends!  :-) )

   Also part of the "pizza-box" allowed a third cable connector. This was
   used for extra communication devices. I have seen, but don't know the
   part number or name of a card which, cabled thru the third connection
   on the "pizza-box" connected to X25 packet-switching network. I
   believe there was also a card which provided support for upto four
   more terminals. Since both these cards live in the same space, you can
   have one or the other but not both.  The space, by the way, is also
   that used for the extra graphics card on the VAXstation, so a
   VAXstation with 8-plane graphics, can't have X25 connection as well.
   (Any details of these options welcomed.)

   Note that the TK50-Z is not the same TK50 as the "normal" one, but a SCSI,
   or _very_ nearly SCSI. Various discussions have taken place about how
   "near" it is. I don't have the technical knowledge to make definate
   statements, but maybe some reader might wish to add to this!  Anyhow, we
   now have the capability of having two hard disks, a floppy drive, and a
   TK50 (95meg of tape!), so, for a home machine, it is not _too_ limited.


   Extracted posting WRT SCSI-ness follows:-
                                  ===*===
   From: seanobanioaol.com (SeanOBanio)

   VAXstation 2000 and MicroVAX 2000 Technical Manual, order number
   EK-VTTAA-TM, $42 from DECdirect about two years ago.

   This tells you everything about the hardware (including connector
   pinouts and bus timing, for example), and a few things about the
   firmware.

   Also, the MVAX 2000 Hardware Info Kit, Model number EK-ZNAAG-GZ, $105,
   gives you the right to use the Field Service firmware diagnotics, and
   has some loop back connectors for the various ports.

   On a related subject, there is an NCR 5380 SCSI sub-system on board,
   but DEC does not support it as a SCSI port.  Only the TK-50Z will
   work.  DEC has said (on this newsgroup and in private conversation at
   DECUS) that an attempt was made at a port driver, but that the system
   was slow.  Also, someone at Trimarchi (remember them?) was working on
   a better version of thier SCSI disk driver for the 2000's, but I can't
   find him.

   If DEC would release the souce for that code, or the souce for related
   port drivers (like the 2000's disk and tape drivers, and the source of
   aa currently supported NCR 5380 system like the MV3100) to someone like
   you and/or I, we could put the result out on a DECUS library.  I, at
   least, would be willing to sign a reasonable non-discolsure, even.

   DEC, are you listening?

   Sean O'Banion

                                  ===*===

   Further to the near-SCSIness, I have heard that, at one point DEC folk
   tried to get a SCSI RRD40 (CD-ROM) to work, but the project was given
   up at the _nearly_ working stage. This was about V4.7.  Also some
   third-party supplier in the States was rumoured to have a way of
   hunging SCSI disks off the 2000's, but I have no details of that. (Any
   offers?)

   To connect other devices, we have to look to the back of the main box,
   where we find three D connectors, a 25 pin, a 15 pin and a 9 pin. This
   is true of both the uVAX and the VAXstation, but the uVAX will/should
   have a strange looking little box screwed into both the 15 and the 9
   pin connection, with, on its lower edge, three MMJ type sockets. They
   are numbered 1, 2 and 3 and are DEC432 connections, complete with the
   little locking trigger off-set from centre. Thus, a uVAX 2000, can
   support up to four terminals directly connected, one using the RS232
   a(25 pin) and the other three thru the wee box, with MMJ connections.
   The full 25 pin arrangement has full modem control, so mine obviously
   has the modem there.  This is the same as for the VAXstation, by the
   way.

   Of the three MMJ's, the first one, number 1, is where you connect the
   console device, and it gets to be OPA0:. Connection number 2, ends up
   being TTA0:, number 3 is know as TTA1:, and the modem-controlled port,
   is TTA2:.  Dunno about you, but I got quite confused by this!


   On the VAXstation, the 25 pin connector is the modem control, the 9
   pin is expected to be the printer, and the 15 pin connection is for
   some horrendous cable, which connects the monitor, keyboard and mouse
   to the main box.  There are actually two possible cables for a
   VAXstation, BC18p-10 is the cable for a mono-chrome monitor, and
   BC18z-10 is the one for colour monitors. With the VAXstations, there
   are several options which you may find. Firstly, a VAXstation with no
   extra graphic card. This will definately work with a mono screen
   (dunno about a colour one). Then there were two optional graphics
   cards, the 4-plane and the 8-plane. They are mutually exclusive, and
   both support color or mono monitors.  Monitor options were the VR260,
   a 19 inch mono-chrome unit, the VR290, a 19-inch colour unit,(Both of
   these 1024 hor. x 864 vert. pixels) the VR150, a 15-inch(?) mono
   screen, and the VR160, a 15-inch colour unit.  The later VR299 also
   works fine with a 2000, as does the VR266.  The mono cable, obviously
   can't work with a colour screen, but the colour cable can work with a
   mono screen, with 75-ohm terminators on the Red, and Blue BNC's.

   Warning: the 19-inch monitors are _very_ heavy!

   The 9 pin printer connection has a neat side use. If you use a printer
   on it, you use the BCC05 cable, but, if you either don't have a
   monitor, or you think your monitor is dead, you can connect a VT220 or
   look-alike, to the printer port, using a BCC08 cable. This allows you
   to fire-up, test the system, and, if you want, run the VAXstation, as
   a uVAX. The difference between the 05 and 08 cable, is that the 08 has
   pins 8 and 9 connected to each other, which is sensed by the system as
   the alternate diagnostic console, just like they did on the PRO's!


   Operating Systems.

   As a VAX, the 2000's will obviously run VMS, from Version 4.6 (might
   be earlier, but I don't know.) upto whatever the current Version is of
   Open VMS. The limiting factor being disk space. I've built V4.6 on an
   RD32 systems disk, and, while I didn't put _everything_ on, I still
   had some space left over to play. For the depraved U**x freaks,
   ULTRIX-32 was also available, when the 2000's were introduced. Current
   state of U**x, I don't know.

   If you're using a VAXstation, and VMS, you will also probably want to
   use Vax Workstation Software, (VMS 4.6->5.5), or DECwindows,(VMS
   5.0->5.5) or DECwindows/Motif (VMS 5.5->?) to actually get to use the
   "big" monitor.

   NOTE:-The above mentioned O.S.'s are the property of Digital and you
   need a license to legally use them.

   There appears to be some work underway to port a free version of Unix
   (NetBSD?) to the 2000. I have no details of the status of this work.

   Best I have at the moment is the following extract:-
                                  ===*===
   Newsgroups: comp.os.vms
   Subject: Re: UNIX on Microvax?
   From: rmsmithcsc.com (Robert Smith)
   Date: 17 Jun 1995 21:23:52 -0400

   Warner Losh (impvillage.org) wrote:
   : NetBSD is being ported to VAXen, but I'm not sure exactly which models.
   : For some odd reason, 11/750 and MicroVAX something (II or III) stick in
   : my head.
   It is being ported to 750, II, and III! - we are hoping for
   smaller ones too - like a 2000!
                                  ===*===

   The power-up testing and "console-mode" utilities for the 2000's.

   KA410-A V1.2
   F_..E...D...C...B...A...9...8...7...6...5...4_..3_..2_..1_..

   *       KA-410-A is a multi-user, uVAX2000 system. -B is the single user
   *       VAXstation 2000. V1.2 is the ROM rev level. NB for VAXstation with
   *       4- or 8-plane graphics board, v2.1 is required.
   *       In the count-down a "_" means the thing wasn't found for test.
    ?  E  0040  0000.0005          < clock battery need charge.
    ?  C  0080  0000.4001          < odd-ball terminal as console(I get it
                   with a Rainbow used as console,but it works just fine!:-))

   If you type T 50 at the >>> prompt should get a display like:

   KA410-A V1.2
   ID 08-00-2B-07-3A-02
   *       the ID above is the ethernet hardware adress.
   ?? MONO     0001.F002
   *       the base (mono) video option. Naturaly not found on a microVAX,
   *       only a VAXstation.

    ? CLK      0000.0005
   *       This is saying that the battery which maintains the clock has run
   *       out of electricity... leaving the Box powered-up for 24 hours
   *       should get a display:
      CLK      0000.0001   which is the healthy sign.
   
      NVR      0000.0001
   *       the Non-Volatile Read-only memory is healthy.
    ? DZ       0000.4001
         00004001 00000001 00000001 00000001 00000000 00000000
   *       the DZ display's six eight digit numbers refer to the 4 serial
   * lines, the keyboard, and the mouse or tablet.
   *       A uVAX2000, should always show 00000000 00000000 as the last two
   *       numbers.
      MEM      0006.0001
         00600000
   *       the .0001 means that the MEMory is healthy, the 0006, and the
   *       00600000 both tell you the box has 6 meg of memory. N.B. this is
   *       hex.  If the first line,second half, is not .0001, there will be
   *       a second eight digit number on the second line telling you the
   *       details of the memory fault.
      MM       0000.0001
   *       Memory management
      FP       0000.0001
   *       Floating Point
      IT       0000.0001
   *       Interval Timer
      HDC      7770.0001
         00000000 00000000 00000000
   *       the Hard Disk Controller is healthy, but it can't see any disks
   *       which is recognizes as ready to use. Where it does see disks,
   *       the second line shows their size (in Hex) inorder DUA0,DUA1,DUA2
   *       RD32's=40Mb or 146B8,RD53's=71Mb or 22000, RD54's=159Mb or 4C437
   *       RX33's are either 1200KB or 960, or, if using RX50's, 400KB or 320
      TPC      0202.0001
        FFFFFF03 01000001 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05
   *       the tape-drive port is healthy and it sees a good TK50-z drive to
   *       talk to.
      SYS      0000.0001
   *       Main system test is OK.
      8PLN     0000.0001  V1.4
   *       the test found a healthy 8-plane graphics card, and Vx.x shows its
   *       version number.   Could alternatively be 4PLN for the 4-plane card.
      NI       0000.0001 V1.3
   *       a healthy ethernet card was found, with its version number.
   *       Note, there must be a terminator, or a terminated ethernet cable
   *       for the card to test healthy.
   
   Test 51 sets the NVR default Boot device.
           Valid choices may be DUA0,DUA1,DUA2 (Disks,where available),
                  MUA0 (Tape) or ESA0 (Ethernet) also .... means no default.
   You type in T 51 and the reply shows the current setting, youi then type in
   what you want it changed to.

   >>>T 52
      .... ? >>> DUA1             This changes No Default, (....) to Disk DUA1

   Should you want to clear the default back to none, enter only one period.

   Test 52 sets the NVR default Boot flags.
   Test 53 sets the NVR default recovery action flags.
   Test 54 sets the keyboard language.
   
   Tests 60,61, and 62 are only used on a VAXstation where no graphics
   card is present.

   T 60    - Displays alignment circle and cross hatch
   T 61    - Displays a screen full of Es
   T 62    - Displays a white screen

  To run the hard disk formatter :
   >>> T 70
 
                    KA410-A RDRXfmt


   VSfmt_QUE_unitno (0-2) ? 0
   
   VSfmt_STS_Siz .??

   VSfmt_RES_ERR #2
    84 FAIL

   Note 1. The T 70 format is not a valid option to format an RX50 floppy,
   but _is_ valid to format an RX33 floppy.

   Note 2. The T 70 format utility will format non-Digital disks, but will
   go into a series of questions for which you need the appropriate answers.

   Sample follows:-
                                  ===*===
   How to Format a Non-Digital Hard Disk

   If the hard disk installed on your system is not a DIGITAL disk, or if
   it is a hard disk that the formatter program doesn't recognize, the
   formatter goes into a query mode.  This query mode allows you to input
   specific data about the drive so that the format program can format
   the drive.

   -----------------------------------------------------------------------
                                IMPORTANT
          THE FORMATTER PROGRAM DESTROYS ALL USER DATA ON THE DISK.
   _______________________________________________________________________

   To run the formatter, type "TEST 70" and "RETURN" at the console prompt
   ">>>".  The following text will be output to the screen:

        KA410-A RDRXfmt

        VSfmt_QUE_unitno (0-2)

   To format the hard disk in the expansion box type "0" and "RETURN",
   to format the hard disk in the expansion box, type "1" and "RETURN".

   *N.B. I have entered numbers which are the published, presumeably correct
   *numbers to format an RD32 (aka Seagate ST251). Some of these numbers are
   *easily obtainable, others.....well, I dunno where they come from.

   If the hard disk is not recognized by the formatter routine, the
   following output will be seen on the screen:


       VSfmt_STS_Siz............. ????             [unknown disk drive]

       VSfmt_STS_EntUIB     [formatter needs disk specific information]

   At this point, the formatter is in the query mode.  It will ask for
   specific information about the disk drive to be formatted.  All the
   requested data can usually be found in the technical manual for the
   drive in question.

   Here is a brief explanation of the data needed to format the drive:

       xbnsiz :=54         [enter the number of transfer blocks]

       dbnsiz :=48         [enter the number of diagnostic blocks]

       lbnsiz :=83236      [enter the number of logical blocks]
  
       rbnsiz :=200        [enter the number of replacement blocks]

       surpun :=6          [enter the number of surfaces per unit]

       cylpun :=820        [enter the number of cylinders per unit]

       wrtprc :=820        [enter the write precompensation cylinder]

       rctsiz :=4          [enter the size of the revectoring control
                            table (RCT)]

       rctnbr :=8          [enter the number of copies of the RCT]
 
       secitl :=1          [enter the sector interleave]

       stsskw :=2          [enter the surface to surface skew]

       ctcskw :=9          [enter the cylinder to cylinder skew]

       mediai :=627327008  [enter the MSCP media ID]

   *       Note this number is not dependant on disk geometry, but is the
   *       magic number for VMS to report on the type of disk.
   *       627327008 = RD32, and 627327010 = RD33 (I think!)

   At this point, the formatter exits the query mode.

   The next output to the screen is:

        VSfmt_QUE_SerNbr (0-999999999)  [enter the serial number for
                                         the drive]
                                        [or enter a unique number
                                         for each unit]

        VSfmt_QUE_RUsure (DUAx 1/0) ?   [where x equals the unit number]
                                        [enter 1 for YES, 0 for NO]

   The formatter is now running, and the output should look like:

       VSfmt_STS_RdMbb.............OK  [manufacturer's bad block located]

       VSfmt_STS_FMTing............OK  [disk formatted OK]

       VSfmt_STS_ChkPss............OK  [check pass completed OK]

       VSfmt_STS_BBRvec := x           [number of bad blocks revectored]

       VSfmt_RES_Succ                  [disk is successfully formatted]

       >>>

   At this point, the disk has been succesfully formatted, and the
   console command prompt is displayed.

                                  ===*===
   Note:- Another way of formatting an unknown disk is by use of either a
   uVAX or PDP-11 with an RQDX-3 disk controller, and maintenance formatting
   software. The resulting format is acceptable to the 2000 box.
  
   Also, RD52 = Quantum Q540,RD53 = Micropolis 1325,RD54 = Maxtor XT2190,
         RD31 = Seagate ST225,RD32 = Seagate ST251, RD33= Miniscribe 3085.
                                  ===*===


   A related utility is T 71, which is the fixed disk verifier. This will
   test (only for reading) a disk.

  The tests of the 8n sequence are only applicable if there is a 4-plane or
   8-plane graphics option board present.

   T 80    - Displays Circle cross-hatch (colour & mon monitors)
   T 81    - Displays Screen full of Es (colour & mon monitors)
   T 82    - Displays White screen (colour & mon monitors)
   T 83    - Displays 4-bar colour bar
   T 84    - Displays Red screen
   T 85    - Displays Green screen
   T 86    - Displays Blue screen
   T 87    - Displays 8-bar clour bar
   T 88    - Displays Gray scale (colour & mono monitors)

   Test T 90 tests the Network (Ethernet).

   X-NEWS: decus comp.sys.dec: 29452
   Relay-Version: VMS News - V6.0-3 14/03/90 VAX/VMS V5.5; site decus.org.au
   Path: decus!metro!news.cs.su.oz.au!harbinger.cc.monash.edu.au\
         !msunews!uwm.edu!chi-news.cic.net!newsfeed.internetmci.com!\
         btnet!dispatch.news.demon.net!demon!yrsk.demon.co.uk!john
   Newsgroups: comp.sys.dec
   Subject: Re: VR290 - VR299
   Message-ID: <1995Nov8.125735.2421yrsk.demon.co.uk>
   From: johnyrsk.demon.co.uk (John Laird)
   Date: 8 Nov 95 12:57:35 +0000
   References: <47pcja$gjclibrary.erc.clarkson.edu>
   Organization: Yezerski Roper Ltd
   X-NNTP-Posting-Host: yrsk.demon.co.uk
   Lines: 10

   In article <47pcja$gjclibrary.erc.clarkson.edu>,\ 
   ayengaskcraft.camp.clarkson.edu (Sridhar K. Ayengar) writes:
   > Hello.  What is the difference between a VR290 19" Monitor and a VR299
   > 19" Monitor?
   >
   >
   Slightly smaller and lighter and better/more reliable (different
   manufacturer I believe). Technical specs are exactly the same.
   --
   ----
   John Laird, Yezerski Roper ( johnyrsk.demon.co.uk ) "Sigs?  Gave them up"

------------------------------------------------------------------------------ 
   
   (3c) Peter Coghlans RX23 driver for a MV/VS-2000

   From PCOGHLANvms.eurokom.ie Thu Jan 11 11:17:46 GMT 1996
   Received: from lune.csc.liv.ac.uk (rootlune.csc.liv.ac.uk\
             [138.253.42.172]) by ribble.csc.liv.ac.uk\
             (8.7.3/LUCS-DTS-2.1R) with ESMTP id LAA01098;\
             Thu, 11 Jan 1996 11:17:45 GMT
   From:
   Received: from mailhub.liverpool.ac.uk by lune.csc.liv.ac.uk with ESMTP
             (8.7.3/LUCS-DTS-2.0D) id KAA00948; Thu, 11 Jan 1996 10:58:16 GMT
   Received: from vms.eurokom.ie by mail.liv.ac.uk with SMTP (PP);
             Thu, 11 Jan 1996 10:04:10 +0000
   Received: from vms.eurokom.ie by vms.eurokom.ie (PMDF V5.0-4 #8109)
             id  for s5eascsc.liv.ac.uk;
             Thu, 11 Jan 1996 11:00:24 +0100 (CET)
   Date: Thu, 11 Jan 1996 11:00:24 +0100 (CET)
   Subject: PATCHDVDRIVER.COM
   To: s5eascsc.liv.ac.uk
   Message-id:
   X-VMS-To: IN%"s5eascsc.liv.ac.uk"
   MIME-version: 1.0
   Content-transfer-encoding: 7BIT
   Status: RO

$!
$! PatchDvDriver.Com  V1.4          By: Peter Coghlan 20-Apr-1995
$!                                      Peter.CoghlanEuroKom.Ie
$!
$! This procedure patches DVDRIVER.EXE to correctly deal with a 3.5in 1.44Mb
$! (RX23) floppy drive connected to a VaxStation 2000 or MicroVax 2000 instead
$! of the designed for 5.25in 1.2Mb drive (RX33). I have used it successfully
$! with a standard off-the-shelf 3.5in high density floppy drive intended for
$! use in a PC connected in place of an RX33.
$!
$! It was designed for use with and has been tested with VMS V5.5-2. It also
$! may work with VMS V6.1. Code has been included to deal with VMS V5.5-1
$! where the offsets of the data to be patched are different. I do not know
$! whether this works or not as I do not have a 5.5-1 system with a floppy.
$! This code might also work with earlier versions of VMS.
$!
$! As with all such procedures, ensure you have a good backup of your system
$! before proceeding. Also ensure you test the patched driver using floppies
$! which do not contain valuable data. As always, everything is at your own
$! risk.
$!
$! After running this procedure, reboot the machine to bring the new driver
$! into use. Note that this procedure only changes the way VMS sees the disk
$! drive. It does not affect the way the console code sees it. This causes the
$! following two limitations :
$!
$!    TEST 70 cannot be used to format 1.44Mb disks. In practice this is not
$!    a serious problem. Preformated (for MSDOS) disks can be used as the basic
$!    sector layout is the same. Alternatively, a VMS machine with a real RX23
$!    or a PC with a 3.5in High Density disk drive can be used for formatting.
$!
$!    1.44Mb 3.5in disks cannot be used to boot from. If it is required to boot
$!    from the floppy drive, then 1.2Mb disks must be written. It does not
$!    matter that these are 3.5in rather than 5.25in. 1.2Mb disks can be built
$!    by bringing the original unmodified DVDRIVER into use. This can be done b
y
$!    renaming the new version of DVDRIVER.EXE created by this procedure and
$!    rebooting the machine.
$!
$! In order to successfully use an RX33 drive again, the patched version of
$! DVDRIVER.EXE should be renamed or otherwise removed and the machine
$! rebooted.
$!
$! Cluster considerations:
$!
$! Only machines which have directly attached floppy drives need to have their
$! DVDRIVER.EXE patched. If the drive is served to other members of the cluster
$! they will see it correctly without needing any patches.
$!
$! If the cluster boots from a common system disk and a mixture of RX23 and
$! RX33 drives are present, the patched DVDRIVER.EXE should be moved from
$! sys$common and placed in the appropriate specific directories for those
$! nodes which have RX23 drives attached. All nodes will then be able to see
$! all served and directly attached RX23 and RX33 drives correctly. Care should
$! be taken at system upgrades to ensure that patched drivers are removed from
$! node specific directories before beginning the upgrade procedure.
$!
$ Set Default Sys$Common:[Sys$Ldr]
$
$ If F$Extract(1, 5, F$GetSyi("Version")) .Ges. "5.5-2"
$ Then
$
$ Write Sys$Output "Using patch offsets for VMS V5.5-2 and later"
$
$ Patch /New_Version DvDriver
! Fix MSCP Media Id
Replace /Hex /Long
013B
25658021
Exit
25658017
Exit
! Fix device type
Replace /Hex /Byte
013F
24
Exit
37
Exit
! Fix device type
Replace /Instruction
0643
"MOVB #24,B^4D(R5)"
Exit
"MOVB #37,B^4D(R5)"
Exit
! Fix device type
Replace /Instruction
18DD
"MOVB #24,B^4D(R5)"
Exit
"MOVB #37,B^4D(R5)"
Exit
! Fix total block count
Replace /Instruction
18F0
"MOVL #00000960,W^00C4(R5)"
Exit
"MOVL #00000B40,W^00C4(R5)"
Exit
! Fix Sectors per track
Replace /Instruction
18F9
"MOVB #0F,B^50(R5)"
Exit
"MOVB #12,B^50(R5)"
Exit
Update
$
$ Else
$
$ Write Sys$Output "Using patch offsets for VMS V5.5-1"
$
$ Patch /New_Version DvDriver
! Fix MSCP Media Id
Replace /Hex /Long
013B
25658021
Exit
25658017
Exit
! Fix device type
Replace /Hex /Byte
013F
24
Exit
37
Exit
! Fix device type
Replace /Instruction
0643
"MOVB #24,B^4D(R5)"
Exit
"MOVB #37,B^4D(R5)"
Exit
! Fix device type
Replace /Instruction
18DC
"MOVB #24,B^4D(R5)"
Exit
"MOVB #37,B^4D(R5)"
Exit
! Fix total block count
Replace /Instruction
18EF
"MOVL #00000960,W^00C4(R5)"
Exit
"MOVL #00000B40,W^00C4(R5)"
Exit
! Fix Sectors per track
Replace /Instruction
18F8
"MOVB #0F,B^50(R5)"
Exit
"MOVB #12,B^50(R5)"
Exit
Update
$
$ Endif

------------------------------------------------------------------------------ 
   
   (3d) SCSI disks via the 2000 SCSI tape expansion box?

   From andyback.demon.co.uk Sun Jan 14 21:37:45 1996
   Return-Path: andyback.demon.co.uk
   Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84])\
             by mailspool.liv.ac.uk (8.6.12/8.6.6-LIV-CSD) with ESMTP id\
             VAA07840 for ; Sun, 14 Jan 1996 21:37:44 GMT
   Received: from relay-4.mail.demon.net by mail.liv.ac.uk with SMTP (PP);
             Sun, 14 Jan 1996 21:37:46 +0000
   Received: from post.demon.co.uk ([158.152.1.72])
             by relay-4.mail.demon.net          id al13157; 14 Jan 96 21:30 GMT
   Received: from back.demon.co.uk ([158.152.141.195])
             by relay-3.mail.demon.net          id aa17273; 14 Jan 96 20:35 GMT
   Date: Tue, 01 Jan 80 01:55:02 0000
   From: Andy Back
   X-Mailer: Mozilla 1.2N (Windows; I; 32bit)
   MIME-Version: 1.0
   To: edwardliverpool.ac.uk
   Subject: SCSI on VS2000
   Content-Transfer-Encoding: 7bit
   Content-Type: text/plain; charset=us-ascii
   Message-ID:
   Status: RO

   Hi

   Dunno if DEC did anything, but I know a guy who had a VS2000 and he
   managed to get a SCSI disk to work on the SCSI port, but I think VMS
   treated it as a tape in certain respects. All I know is it worked but
   it wasn't reliable, maybe there are some new drivers you can get, or
   maybe the disk type functions aren't implemented in the SCSI command
   set on the KA410 (by firmware ?). Let me know if you get any further.

   Andy


   From kozambart.mlksoft.com Sun Jan 14 20:17:03 1996
   Return-Path: kozambart.mlksoft.com
   Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84])\ 
             by mailspool.liv.ac.uk (8.6.12/8.6.6-LIV-CSD) with ESMTP id\
             UAA06251 for ; Sun, 14 Jan 1996 20:17:03 GMT
   From: kozambart.mlksoft.com
   Received: from MLKSOFT.COM by mail.liv.ac.uk with SMTP (PP);
             Sun, 14 Jan 1996 20:17:03 +0000
   Received: by bart.mlksoft.com (MX V4.1 VAX) id 1; Sun, 14 Jan 1996\
             15:16:00 EDT
   Date: Sun, 14 Jan 1996 15:15:59 EDT
   To: edwardliverpool.ac.uk
   Message-ID:
   Subject: Re: SCSI on VS2000
   Status: RO

   Eddy,

   You write:

   > Can a SCSI disk be connected to a VS-2000 SCSI adaptor?

   > I have heard that the SCSI I/F for the VS2000 is "limited" and will only
   > work for the TK50 - is this a h/w or s/w problem? I heard DEC was working
   > on something in the late 80's - anything come of this?

           I have researched this on several occassions.  I believe that the
   problem is both hardware and software.
        
           First off, when the VS2000 was in design, SCSI was still very 
   young so the hardware isn't exactly compliant.  It is REALLY close -
   tantilizingly so (that's why this thread keeps coming up).  Perhaps
   one device would work, but then again, probably not.

           Hardware is yet another issue.  DEC never wrote any support for 
   this kind of use.  Perhaps something internal, but even then, perhaps not.

           All that said, a company called Trimarchi in Pennsylvania U.S.A.  
   had a product that I believe used the VS2000 port to attach some disks.  I
   never used it, saw it, or even knew of anyone who used it.

           After going through the technical manual (which happens to be 
   very detailed - unlike more recent "technical manuals"), I've concluded
   that it would be possible to put SCSI-like disks on the VS2000.  The
   disks would probably need custom firmware.  As always, the deciding
   factor was economics.  By the time SCSI was well accepted, the VS2000
   was already an ageing product.  It didn't make sense to develop SCSI
   capabilities on a machine that was already nearing the door.

           Hope this gives you a useful answer.

   Marc Kozam
   kozammlksoft.com


   In article  Eddy Austin  writes:
   :hi
   :
   :Can a SCSI disk be connected to a VS-2000 SCSI adaptor?
           No.
   :
   :I have heard that the SCSI I/F for the VS2000 is "limited" and will only
   :work for the TK50 - is this a h/w or s/w problem? I heard DEC was working
   :on something in the late 80's - anything come of this?
           The "SCSI I/F" is not SCSI, it is special purpose for the TK50.
   There was a special variant of the TK50 (TKZ50?) which replaced the
   controller board with a SCSI adapter for use on SCSI bus machine like
   the VS/DS 3100.

   Sam

    I'm sure in the Technical manual for the VS/uV2000 the CPU board
   (KA410) is shown as having a SCSI chip (NCR ?) and the I/F marked as
   SCSI. I know it is meant for tape only (TK50), but the matching drive
   (TK50Z-F3) requires only a change of ROM (so I understood) to work
   with a VS/uVAX 3000+ (which makes it a TK50Z-G3).

    Maybe the limitation is in the CPU modules firmware or in VMS drivers,
   or maybe I am just babbling (probably the case).

   Andy

   In article , Andy Back  wrote:

   > Im sure in the Technical manual for the VS/uV2000 the CPU board
   >(KA410) is shown as having a SCSI chip (NCR ?) and the I/F marked as
   >SCSI. I know it is meant for tape only (TK50), but the matching drive
   >(TK50Z-F3) requires only a change of ROM (so I understood) to work
   >with a VS/uVAX 3000+ (which makes it a TK50Z-G3).

   The chip used is the NCR 5380. That's an older chip, so you wouldn't
   be able to do synchronous SCSI with it. I also don't see any reason
   the port can't be used for generic SCSI. Yes, arguing with the disk
   controller over ownership of the DMA buffer might be interesting, but
   it should at least be possible...

   Roger Ivie
   iviecc.usu.edu

   In article ,
      hoffmanxdelta.enet.dec.com (Stephen Hoffman) wrote:
   >
   >In article , Eddy Austin  writes:
   >
   >
   >:I have heard that the SCSI I/F for the VS2000 is "limited" and will
   >:only work for the TK50 - is this a h/w or s/w problem? I heard DEC was
   >:working on something in the late 80's - anything come of this?
   >
   >   If you want a SCSI-based system, I'd strongly recommend acquiring a
   >   new or used member of the MicroVAX or VAXstation 3100 series or of
   >   the VAXstation 4000 series -- the VAXstation and MicroVAX 2000 did
   >   not have a SCSI interface, they had an I/O interface that was similar
   >   to SCSI...  All 3100 and 4000 series VAXstation systems are faster
   >   (many are significantly faster), and all are rather more extensible
   >   than the VAXstation 2000 series.  And all have at least one SCSI...
   >
   >  ---------------------------- Opinionative -----------------------------
   >   Stephen Hoffman     OpenVMS Engineering    hoffmanxdelta.enet.dec.com
   >  -----------------------------------------------------------------------
   >
   Actually, the SCSI port IS SCSI..but limited to SCSI-1 You can use a
   disk on this if you are willing the write your own driver..sorry, I
   don't remember the chip type but think its an NCR general scsi
   interface..I don't have a 2000 board laying around to get the chip no.
   from..I looked at this myself,but decided to look for a 3100
   instead..(Its easier to get a free 3100 then write a driver!)  Have
   fun with it..Its a great toy!

   Andy Back  wrote:
   > Im sure in the Technical manual for the VS/uV2000 the CPU board
   >(KA410) is shown as having a SCSI chip (NCR ?) and the I/F marked as
   >SCSI. I know it is meant for tape only (TK50), but the matching drive
   >(TK50Z-F3) requires only a change of ROM (so I understood) to work with a
   >VS/uVAX 3000+ (which makes it a TK50Z-G3).
   >
   > Maybe the limitation is in the CPU modules firmware or in VMS drivers,
   >or maybe I am just babbling (probably the case).

   If I remember correctly, the interface chip in the VS2000 is an NCR
   5380.  This is the same chip as used in the original Mac Plus and, I
   believe, the VS3100 SCSI interface.  I don't know, however, whether or
   not all of the signals are connected on the VS2000 so that it can be
   used as a full SCSI interface.  They may just be using it as a
   sophisticated parallel interface controller. In any case, the drives
   do NOT support it as a generic SCSI controller, so the point is moot.

   Ages ago, Trimarchi had a hard disk system which could be connected to
   this port, but I believe that they provided their own drivers and that
   it wasn't a true SCSI solution.

   -----------------------------------------------------------------------
   Chris Scheers, Applied Synergy, Inc.

   817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asiairmail.net

   In article , Eddy Austin  writes:
   > hi
   >
   > Can a SCSI disk be connected to a VS-2000 SCSI adaptor?
 
   Yes.... but, while you didn't ask, it won't work.   :-(
   
   > I have heard that the SCSI I/F for the VS2000 is "limited" and will only
   > work for the TK50 - is this a h/w or s/w problem? I heard DEC was working
   > on something in the late 80's - anything come of this?

   The story that I have heard was that DEC tried to add on a CD-ROM in
   place of the TK50.....this was about V4.7 of VMS.... but they didn't
   get it to work very well.

   I _think_ the limitations are software based, althought the hardware
   _was_ early SCSI.  I also believe that some mob in the States marketed
   a SCSI disk upgrade for 2000's......Clearpoint???....anyone remember
   the details?

   > --ed
   >
   >
   > Eddy Austin                                      In a dog eat dog world
   > edwardliverpool.ac.uk                           you gotta eat some dog!

           regards,
                   CrazyCam        Nostalgic and Obsolete Products SIG
                                   DECUS Australia

------------------------------------------------------------------------------
    
   (3e) MicroVAX-2000 [18]asynchronous multiplexer spec sheet

   DHT32

   The DHT32 is an 8-line asynchronous multiplexer for the MicroVAX 2000,
   application compatible with the DHQ11. It provides data-only
   transmission at speeds up to 38.4 Kb/s, and allows eight additional
   terminals or peripheral devices to connect to the MicroVAX 2000
   system. With the three non-modem lines and one modem line available on
   the MicroVAX 2000, a total of 12 asynchronous lines can be connected
   to the MicroVAX 2000 system. (A ``network'' solution, including
   DECserver 200 via 802.3/Ethernet, is appropriate if more asynchronous
   lines are required.)

   The DHT32 supports the EIA-423-A standard. Terminals requiring EIA-232
   connections can use an adapter. Cables that connect directly to
   terminals or printers are not provided as part of this option.

   Note: The DST32 and the DHT32 (8-line asynchronous communications
   option) are mutually exclusive, and only one can be installed in a
   system. If more than four asynchronous lines are required, customers
   can add terminals using Digital terminal servers. For synchronous
   communication to an IBM host, an alternate method is to use a DECnet
   SNA Gateway.

   Features

   o 8-line, asynchronous, terminal-expansion option gives MicroVAX 2000 a
     total capacity of 12 asynchronous lines.

   o Performance approximates the MicroVAX II systems with DHQ11
     asynchronous controller.

   Software Support
 
   VMS and ULTRIX operating systems.

   Specifications

   Mounting Space                          Daughter-boarded to the system 
                                           module; driver/receiver board 
                                           located in the expansion adapter

   Power Requirements

   dc amps drawn at 5 Vdc                  1.5 A
   dc amps drawn at 12 Vdc                 0.70 A
   dc amps drawn at -12 Vdc                0.12 A

   Bus Loads                               Private bus architecture (one 
                                           F-type logic board)

   I/O Connection Panel Inserts            Located in opening C in the 
                                           expansion adapter

   Environmental Class                     B with modified relative humidity
                                           (operating) of 10 to 90% (no 
                                           diskette system), and 20 to 80% 
                                           (diskette in use)

   DHT32 Order Codes

   Option                                                  Order Code

   8-line asynchronous controller includes serial line     DHT32-AA
   logic module, serial line driver/receiver module,
   34-way internal ribbon cable, external 7.5-m (25-ft)
   data cable, and 8-line data cable concentrator (H3104)

------------------------------------------------------------------------------
   
   (3f) MicroVAX 2000/VAXstation 2000 "dd2000.html" Diagnostic Package details
        *** ARE NO LONGER AVAIL ***

        Does anyone have any information about these? [R.D.D.]

------------------------------------------------------------------------------
   
   (3g) Blurb about Interfacing a 2000 with a 3400
   
   First, you SHOULD be able to boot the 3400 from the net (ESA0).
   However, you'd REALLY be MUCH better off booting the 2000 from the
   3400.  You should have an RS-232 connector on the back of the 2000.
   If you can't get a console terminal (LA36 or VT terminal would do,
   unless you're talking about the actual BULKHEAD adapter for the 3400).
   You should be able to attach a MMJ cable from the front of the console
   bulkhead MMJ console connector to a MMJ to RS-232 adapter (an H8571-?
   something or another).  This should let you talk to the console port
   on the system.
  
   If you really want to LAVC the 3400 as a satellite, you'll need to
   cluster configure the 2000 as both a boot node and disk server.  Given
   that the system is slow, this is really not a very good choice.  The
   VS3100 would be a better solution, but still not good either.  The
   3400, given sufficient disk space, would be a fair disk server for
   both the 3100 and the 2000.

   About the 3100.  It's essentially a more robust version of the 2000
   CONCEPT.  It has a faster processor, is capable of using 32MB of
   physical memory, can use much more advanced graphics (but actually,
   some of the color graphics options on the 2000 can be used in the
   3100; I don't think that it works the other way around,
   unfortunately).  It can have either a SCSI/ST506 (RD53/54) controller,
   a single SCSI controller or a dual SCSI controller (where the A SCSIis
   internal and B is external).  The VS3100M38 is something like a 3.8
   VUP system and the 2000 is around a .9 VUPper.  The 2000 has no real
   SCSI on it, even though the connector to the external TK50 looks
   close.  The 3100 uses DEC MS42-?? memory (or equivalent), and the
   memory modules stack in a fashion similar to mother-daughter.  32MB is
   the max.  The 3100 will support up to a 1GB bootable disk (with up to
   8GB on a single spindle for data disks).  The 2000 will only connect
   to RD5X disks, where the max capacity is something like 150MB and
   SLOOOOOW to boot.

  I don't mind helping, if you have further questions.
 
   Bob Blunt


   Define slow....  The 2000 isn't the world's fastest machine, but, at
   least in my case the price was right! ;-)

   The two things which I found to perk-up a 2000 Vaxstation were: add
   memory, I have 14 meg.; and hang it off a server box, with the local
   disk being a swap and pagefile thing.

   >Finally I have a VAXServer 3400 with 16mb, I have connected it via
   >thin-wire t o the 2000, I have no console for the 3400 but I know it
   >will attempt to boot off ESA0.. my problem - can I get the 3400 to be
   >recognised by the 2000??  ?  the 3400 runs 5.5 as well. I *cannot* get
   >hold of a console for the 3400, if I did I'd just do a DIA0 boot to
   >start up VMS on the machine ...

   Wait here.... you don't get a 3400 to boot from a 2000, you want the
   3400 to be the "server" and the 2000 to boot from it.  You need a
   console, anything will do...a terminal, a Rainbow , even a cable from
   TTA2: on the 2000 would do the job. You then establish a bootable
   system on the 3400, so it fires up on it's own.  Then you try and get
   the 2000 to boot over the ethernet from the 3400.

   >How can the 2000 recognise the 3400??? all i have is the 3400 trying
   >to boot off ESA0 and connected via thin-wire to the 2000 which is
   >running VMS 5.5.

   Actually, I _think_ what you are trying to do, might just possibly
   work, but it is such a "wrong-way-round" thing that I certainly ain't
   tried it, and I doubt if anyone else has either.

   >Before I get flamed - I AM NO VMS EXPERT AND I HAVE *NO* MANUALS but I
   >like the machines, it would be good to learn as much as I can :-)

   Hey, relax, the whole world _isn't_ full of Carls, I can understand
   the situation, and, as far as is possible, I'm happy to help.
   Generally, this group does have nice people.  :-)

   Do you know anything about Licences and PAKs and things?

           regards,
                   CrazyCam        Nostalgic and Obsolete Products SIG
                                   DECUS Australia



   >I have just aquired a VAXStation 3100 Model 38. Can anybody tell me
   >anymore information on this system, it has 16mb of RAM and I was told
   >an internal 50mb SCSI disk drive. Are these machines still used????
   i use about 8 of them every day...
     (except the 50mb disk drive... did DEC ever ship one that small inside
        a /38?)


   >Finally I have a VAXServer 3400 with 16mb, I have connected it via
   >thin-wire t o the 2000, I have no console for the 3400 but I know it
   >will attempt to boot off ESA0.. my problem - can I get the 3400 to be
   >recognised by the 2000??  ?  the 3400 runs 5.5 as well. I *cannot* get
   >hold of a console for the 3400, if I did I'd just do a DIA0 boot to
   >start up VMS on the machine ...

   i believe the 3100 is faster than the 3400.  if all the 3400 needs is
   a -serial- console, then why not cable its rs232 port to the 2000's,
   and tell the 2000: SET HOST/DTE TTA0 ?  (i think the 2000's serial
   port is TTa0, it might be TTa1 or TTa2) That turns the 2000 into a
   "terminal" ... the keyboard stroke go out the rs232 port, and anything
   coming in the rs232 port appears on your screen.  You'll need a "null
   modem" (swap pins 2 and 3) cable between the 2000 and the 3400.

   >How can the 2000 recognise the 3400??? all i have is the 3400 trying
   >to boot off ESA0 and connected via thin-wire to the 2000 which is
   >running VMS 5.5.

   what do you mean by "recognize"?
   if you mean "remotely boot the 3400", then do:
      SET DEF SYS$MANAGER
      CLUSTER_CONFIG

   you'll have to know the 3400's hardware ethernet address.

   --dick

------------------------------------------------------------------------------


   (3h) How do I boot a VAXstation 2000 running Ultrix? [R.D.D.] 

   Contributor to this section of the FAQ: 
   James T. Boldway, jboldwaycapecod.net

   For booting with the Unix disk (1/2 of unix, was on two rd54's
   so I had to boot with the generic driver) I typed B/3 a the triple chevron
   prompt. After a bit it asks for driver and I type /genvmunix  If you get a
   copy and load it up the ethernet, that is how you will have to start it up.
   I guess it works with rd53's and rd54's. If I ever figure out how to hook up
   both rd54's to my VS2000, I'll find out how to copy the ultrix 4.4 if you
   want it.

*============================================================================*
                                      
   (4) MicroVAX-II/VAXstation-II specifics

------------------------------------------------------------------------------
   
   (4a) Adding additional drives to a MicroVAX-II


   From:   SMTP%"newsspcuna.spc.edu (Network News)" 28-JUN-1995 02:59:16.36
   Subj:   Re: Add an RD52 to a MVII

   In article , mercerceres (Eric Mercer) writes:

   [First, please get your news posting software fixed. You need to get the
   whole host/domain stuff in there, not just your hostname].

   > I have a MicroVAX II (BA23) with a RQDX3 controller and an RD54 drive.
   > We have an RD52 drive from a VAX 8550 console, and we want to use the
   > RD52 in th e MVII.  We switched the drive select jumper from DS1 to
   > DS3, and we put it in the MicroVax.  When the machine boots, DUA1
   > shows up.  However, SHOW DEV DUA1:/FULL responds with:

   > Disk CVRC$DUA1:, device type RD51, is online, file-oriented device,
   > shareable , served to cluster via MSCP Server, error logging is
   > enabled.


     RQDX3's consider anything that isn't formatted the way they like to be
   an RD51. It's a safe guess - it's the smallest drive. Looks like your
   RD52 came out of a Pro, which has its own format.


   > When I try to mount or init the device, it responds with:
   > %MOUNT-F-FORMAT, invalid media format -or-
   > %INIT-F-FORMAT, invalid media format

   > which seems to imply that the device needs to be formatted.  What do I
   > need t o do in order to format this device?  Please note that there is
   > nothing of valu e on this disk.

     You need to format it with the Field Service version of MDM (not the
   "Customer Diagnostics", which stupidly can only format an
   already-formatted drive).  You could also use a VAXstation 2000's
   built-in formatter (TEST 70? 73? some- thing like that) or a PDP-11
   with an RQDX3 running the ZRQC formatter program from XXDP.

   > Also, The control panel only has Write Protect & Ready switches for
   > fixed disk 0.  I have heard that I must have a RQDXE Expander Module
   > to add another RD5x drive (putting the second RD5x drive in the
   > expansion enclosure).  Is th is true?  If this is required, why are
   > there ports for fixed disk 0 and fixed disk 1 in each box?  It seems
   > like the enclosure supports up to two fixed disks.

     It's an incomplete design. To get proper function from the second set
   of drive connectors in there, you need the BA23-UC six button control
   panel up- grade (at $219), or you need to solder some pullup resistors
   onto the existing control panel. Note that the BA23's power supply
   can't handle 2 full-height disk drives in most configurations. You can
   use long cables to bring the 2nd disk lines out to an external box, or
   you can use the RQDXE and a RD5x-D-series enclosure to mount the
   drive. The RQDXE doesn't get you everything you need - you still need
   the D-series box.

     If you can afford it, I'd toss the RD drives completely and put in
   either a used ESDI system (I have a VS3200 system in a BA123 with a
   Webster ESDI con- troller and 3 760MB drives) or get a SCSI controller
   from CMD and a new SCSI drive. Either of these solutions will be a lot
   faster and far more reliable than the ST506-series drives. Of course,
   this probably isn't reasonable for a hobby system.

        Terry Kennedy             Operations Manager, Academic Computing
        terryspcvxa.spc.edu      St. Peter's College, Jersey City, NJ USA

        +1 201 915 9381 (voice)   +1 201 435-3662 (FAX)

------------------------------------------------------------------------------
   
   (4b) A problem I had with a dead MicroVAX-II she don't boot!! :-(

   MicroVAX-II Console Problem

   During the Autumn of 1994 I was wondering around the University
   CAD/CAM lab and happened to see an old MicroVAX-II sitting in the
   corner, looking solitary and out of place. On further enquiry I was
   told I could have her for *FREE*!!!  (The University had upgraded to
   5000/133 workstations from a Cluster of MicroVAX-II's and some
   VS-2000's, they since have upgraded to Sparc 5's booo!) they were
   gonna throw the -II in a skip!!!

   I couldn't believe my luck... anyhow the configuration was:

   MicroVAX-II QZ-A3, 9mb, RD53, RQDX3, RX50 in a BA23 and a host of
   spare/additional cards including a TQK50 (but no TK50 alas), VMS 4.7
   on 40 floppies... (more stable than Windows 95 anyhow...)  also a
   VT220.

   Taking her home sticking and placing her in bedroom, I plugged her all
   in... an d then finally switched all power on. A massive big Humming
   noise filled the room and pretty lights flashed on the console, I then
   got the countdown on the console ..4..3..2.. and then the chevron
   prompt >>>

   I couldn't boot off DUA0 though, no OS on the RD53... a pity...

   But I had a working MicroVAX-II!!! My first home VAX!!!

   However before I managed to load the OS I had a problem. One time I
   switched her on and whilst the countdown LED went down to zero on the
   back of the system there wasn't any characters on the VT terminal. I
   first (wrongly) suspected the VT220, but tested that (and the cable)
   elsewhere and they worked.

   Finally I found (with the help of comp.os.vms) the problem. The line
   driver/receiver chips on the KA630 were kaput due to a spike occurring
   on the serial line from the VT220. This can occur if you switch the VT
   off at the mains *INSTEAD* of at the back of terminal. Apparently VT's
   spiking this way is not uncommon!!!

   Although the chips blew, still the Diagnostics do not pick it up.
   Apparently this is because it is non fatal as you could still login
   over the ethernet...

   I was a bit annoyed.. it wasn't even the -II's fault!!
 
   Moral: SWITCH YOUR VT220 OFF AT THE CONSOLE!!!!

------------------------------------------------------------------------------
   
   (4c) THE GPIB Interface for MicroVAX-II details (external link) 
        *** IS GONE ***

        Where is it?  Can someone provice this information again for the
        FAQ?  
   
------------------------------------------------------------------------------

   (4d) I've just acquired a MicroVAX II.  What should I do before
        turning the power on for the first time? [R.D.D.]


    Note: these instructions are for a MicroVAX II in a BA23 pedestal
          cabinet.   Good luck!

    0. Get a small zip-lock bag, or other small container, to put
       loose screws in.  It's not good to have a screw loose and
       then not be able to find it.

    1. Remove the front and rear covers.

    2. Remove the two screws holding the retaining plate in place from the 
       top of the back of the cabinet - this is the second pair of screws
       from the top of the cabinet.

    3. Slide the chasis out of back of the pedestal cabinet.

    4. Loosen the two screws which hold the rear cover, or back panel,
       from the system.  These screws don't come all of the way out. 
       Remove this panel and note how the cables are attached to the
       boards.  These cables are keyed, but it never hurts to take
       careful notes anyway.   Now then, disconnect these cables and
       set them aside.  Test the batteries to see what the charge on
       them is.

    5. Note which slots which boards are in.

    6. Note how the cable connecting the CPU to the memory board(s)
       is connected, and then remove it.

    7. Remove the boards; place them in, or on, an anti-static bag.

    8. Remove the two large cover plates on the top of the chasis.

    9. Remove the semi-circular cover which houses the front fan.

   10. Inspect all wiring.  Look for burned, frayed, nicked, broken
       or brittle wires and connectors.  Repair if necessary.

   11. Inspect the chasis carefully for any signs of dust, loose
       bits of metal, screws, spiderwebs, spiders or insects.  
       Clean up any problems.

   12. Note how the data/control cable is connected to the floppy
       drive and disconnect it.  Disconnect the power cable.

   13. Remove the floppy drive.  Remove the bottom skid plate and slide
       the drive out of the thin metal housing.  Carefully remove any
       dust, etc. and clean the heads.  Reassemble the drive.

   14. Note how the data and control cables are connected to the
       hard drive and disconnect them.  Disconnect the power
       connector.

   15. Remove the hard drive and inspect it for dust, spiderwebs,
       etc.  Clean up any problems.

   16. Inspect the fans to see if they turn freely and that they 
       are not dusty.  Fix any problems.

   17. Note how the control panel cable connects to J2 and J4 on
       the chasis.  Note that J2 and J4 go to the same ribbon cable
       and that for this reason there's no red stripe for J2.  
                
   18. Look at the "load points" sticker on the top of the power
       supply.  With one board, the most easily repairable one, or
       least expensive one (NOT THE CPU!) inserted into the bus,
       plug the system into the mains socket and turn the power
       switch on.  Measure the 5V and 12V supplies and observe that
       both fans spin freely.  Optionally, look at the PSU output  
       waveforms with an oscilloscope to verify that there are
       no spikes, ripple, etc.  Turn power off and unplug system from
       the mains.

   19. Reassemble the system, but leave back panel open but connected.

   20. Connect a console terminal to the system, plug the system back in,
       turn the power on and observe the LED display on the back panel
       and the LEDs on the back of the CPU board.  Pay careful attention
       to signs of smoke, sparks, strange smells, etc. and take 
       appropriate action.

   21. Reattach back panel to system.

 
------------------------------------------------------------------------------

   (4e) Answers to "What's a VAX Console?" and   
        "I found an M7553 in my system - what is it?" [R.D.D.]


   The following people contributed to this section of the FAQ:

   Dave Clark,  dscSwindon.gpsemi.com 
   A. R. Duell, ard12eng.cam.ac.uk 
   Michael Engel, engelnumerik.math.uni-siegen.de 
   MARTIN FALVEY, GPWMMSFgp.co.nz 
   Matt Reilly, reillyrock.enet.dec.com


   An M7553 is a Q-Bus console module, or console device board; it has a
   50-pin IDC connector on it.  On a MicroVAX II, labeled as a VAX
   Console, this connector connects to a DD50 connector on the back panel
   of the system.  A VAX Console is basically a system such as a MicroVAX
   II which is used as a console processor for a larger VAX such as a VAX
   8830.  The MicroVAX II systems in a BA23 enclosure were used with the
   VAX 8820, 8830, 8840 and 8842 systems, and the MicroVAX II systems in
   the BA123 enclosures were used with the 8974 and 8978 systems.

   Some PRO380 systems were also labeled as VAX Consoles and contained a
   similar board. 

   Here's a explanation of VAX Consoles and M7553 boards from Matt
   Reilly, reillyrock.enet.dec.com:

              Ok... This is digging back into really old stuff
      in my head, but I'll give this a try:

              Once upon a time, Digital built a 64 processor
      microvax system (code named Andromeda).  It had a separate 
      console, built from a microvax II rackmount box.  The 
      connection between the microVAXII and the Andromeda was
      via a fancy special module in the console (that's how 
      boot code was loaded into memory and how the various
      configuration/maintenance registers got diddled) and via
      a serial line (IIRC) to the power and environmental 
      control hardware.  (The console was really cool -- 
      it had command completion and lots of help and some
      neat displays that showed everything from which processors
      were booted to what the exhaust temperature was over the
      past hour...)

             Andromeda died a horrible death.  We built three
      of them.  Most of the engineers went on to other projects.
      (I stayed on and wrote a book about it...)

             One of the engineers was the guy who wrote the
      console program.  He went to work on the project that
      re-engineered the 8800/8700 (Nautilus) into the 8820/8840 
      (Polarstar) system.  Polarstar needed a new console.  We
      had one that worked already.  

             Now for the conjecture:  I'm pretty certain that
      the module that was used for the hardware interface for
      Polarstar was the same one that was used for Andromeda.
      I've called the responsible engineer to check my memory.
      He is out right now.  

      [Note: a later e-mail message from Mr. Reilly confirmed
       that the above paragraph is correct]

------------------------------------------------------------------------------

   (4f) What's what on the back panel, or buklhead, of a MicroVAX II?

   The following information was provided by:
   VMS-FAQ

   The MicroVAX-series console bulkhead was used with the KA630, KA650,
   KA655 processors.

   There are three controls on the console bulkhead of these systems:

     Triangle-in-circle-paddle: halt enable.
       dot-in-circle: halt () is enabled,
                      and auto-boot is disabled.
       dot-not-in-circle: halt () is disabled,
                      and auto-boot is enabled.

     Three-position-rotary: power-up bootstrap behaviour
       arrow: normal operation.
       face: language inquiry mode.
       t-in-circle: infinite self-test loop.

     Eight-position-rotary: console baud rate selection
       select the required baud rate; read at power-up.

   Those versions of the console bulkhead that do not have an MMJ have a
   9-pin submini connector, and the pinout of this connector predates the
   PC 9-pin pinout -- the console pinout is consistent with the EIA232
   pinout.  For those bulkheads not equipped with an MMJ, use the H8575-B
   adapter to convert the console connector to MMJ.  See MISC1 for
   further details.

   Also present on the bulkhead is a self-test indicator: a single digit.
   This matches the final part of the countdown displayed on the console
   or workstation, and can be used by a service organization to determine
   the nature of a processor problem.  The particular countdown sequence
   varies by processor type, consult the hardware or owner's manual for
   the processor, or contact the local hardware service organization for
   information the self-test sequence for a particular processor module.
   Note that self-tests 2, 1 and 0 are associated with the transfer of
   control from the console program to the booting operating system.

*============================================================================*

   (5) MicroVAX-3100/VAXstation-3100 specifics

------------------------------------------------------------------------------
   
   (5a) MicroVAX 3100 40/85 infosheet from Digital Apr 95

   *** WARNING *** DEC marketing propaganda follows.

   MicroVAX 3100 Systems

   A family of low-cost, high-performance desktop servers

   You've depended on the strength and power of VAX technology,
   affordable SCSI-based storage, simplified desktop integration, and
   easy upgradability.  You've looked to Digital's MicroVAX 3100 family
   as your number one choice.  Well, look again.

   With the addition of the MicroVAX 3100 Model 96, Digital offers a new,
   more powerful line-up of desktop systems designed to address
   client/server and multiuser demands for simplified desktop
   integration.

   Engineered to ensure your data, applications, and business information
   are safe and secure, the newest member of the MicroVAX family puts the
   CPU power of a mid-range system on the desktop -- for the price of a
   multiuser PC.

   And, these systems offer a low-cost entry into the world of VAX
   computing with its open architecture, exceptional features, and wealth
   of OpenVMS applications. Plus, now the entire family is protected by a
   three-year warranty.

   Highlights

   o Twenty-percent CPU performance (10ns) improvement at the high end
 
   o Excellent price/performance, industry-standard SCSI storage, and 
     StorageWorks solutions

   o Shipping with OpenVMS V6.1, the operating system over ten million 
     users rely on

   o Advantage Server packaging with NAS 200, 1 GB disk, CD-ROM

   o Available now, with three-year hardware warranty, new upgrades

   o Upgradable to AlphaServer systems


   Systems that match your business and your budget

   Whether your business is small or large, there's a MicroVAX system for
   you. You can enter the world of VAX computing with the most affordable
   Model 40, offering a low-risk, high-return investment. When your
   business grows, you can upgrade to a higher-performing Model 85 for
   applications that demand higher processing power. And, for maximum
   performance and expandability, where applications require processing
   speeds up to 200 transactions per second, the Model 96 is the right
   choice.

   This flexibility, coupled with a three-year warranty providing
   next-day response, gives businesses the investment protection their
   applications demand.

   Exceptional service and support 
   
   Digital supports the MicroVAX family with a wide range of system and
   network management, training, administration, recovery, and support
   services to meet your specific needs.

   Call us

   To learn more, contact your local Digital sales office or an
   Authorized Digital Business Partner. For information by fax, call:
   800-DIGITAL (via a touch-tone phone in the U.S. and Canada), or
   1-908-885-6426 (outside the U.S. and Canada). For on-line information,
   send mail to infodigital.com.

   MicroVAX 3100 Specifications

   System configuration            Model 40                        Model 85
   Enclosure                       BA42-B                          BA42-B
   Min./max. memory                8/32 MB                         16/128 MB
   Max. no internal drives         5                               5
   Max. total drives               7                               14
   Total disk capacity             14.7 GB                         29.4 GB
   Disks                           Support for leadership SCSI disk (RZx) 
                                   and tape
                                   (TZx) devices (Models 40, 85)
   Load/backup devices             Support for QIC, DAT, and DLT tapes; 
                                   and CD-ROM
   (primary use)                   devices (Models 40, 85)
   I/O support                     SCSI (1)                        SCSI (2),
                                                                   Ethernet
    In-cabinet CPU upgrade**        3140 -> 3196
                                   3185 -> 3196
                                   3195 -> 3196

   Performance
   CPU clock speed                 25 MHz                          62.5 MHz
   TPS -- est.                     39                              110

   Power requirements
   Line voltage                    120/240 Vrms                    120/240 Vrms
   Power sourcing phasing          single                          single
   Nominal frequency               50 - 60 Hz                      50 - 60 Hz
   Voltage range                   88 - 132                        88 - 132
                                   176 - 264                       176 - 264
   Line frequency tolerance        47 - 63 Hz                      47 - 63 Hz
   Typical running current         1.1 A/.60 A                     1.5 A/.75 A
   Typical power consumption       132 W/144 W                     180 W/180 W


   MicroVAX 3100 Specifications

   System configuration            Model 96
   Enclosure                       BA42-B
   Min./max. memory                16/128 MB
   Max. no internal drives         5
   Max. total drives               14
   Total disk capacity             29.4 GB
   Disks                           RZxxx SCSI-based disks*
   Load/backup devices
   (primary use)                   TZK11 (2 GB) QIC (backup)
                                   TLZ07 (4.0 GB) DAT (backup)
                                   TZ85 (2.6 GB) Tape (backup)
                                   RRD43 (600 MB) CD-ROM (load)
   I/O support                     SCSI (2), Ethernet
   In-cabinet CPU upgrade**

   Performance
   CPU clock speed                 100 MHz
   TPS -- est.                     200
 
   Power requirements
   Line voltage                    120/240 Vrms
   Power sourcing phasing          single
   Nominal frequency               50 - 60 Hz
   Voltage range                   88 - 132
                                   176 - 264
   Line frequency tolerance        47 - 63 Hz
   Typical running current         1.5 A/.75 A
   Typical power consumption       180 W/180 W

   Standard communications
   (all models)
   Minimum MMJ lines               3 DEC423
   Modem lines                     1 RS232
   Ethernet                        ThinWire/thick wire supported

   Communications options
   (all models)
   MMJ lines                       8 DEC423
   MMJ lines                       16 DEC423
   Modem lines                     8 RS232
   Synch lines                     2 Synch

   Operating environment
   Temperature                     10°C to 40°C (50°F to 90°F)
   Relative humidity               10% to 80% noncondensing; 20% to 80%
                                   noncondensing (if tape drive present)
   Maximum operating altitude      2.4 km (8,000 ft)

   Physical characteristics
   Height                          14.99 cm (5.90 in)
   Width                           46.38 cm (18.26 in)
   Depth                           40.00 cm (15.75 in)
   Weight                          16.00 kg (36.85 lb)


   * Refer to the most current Systems and Options Catalog for supported 
     devices (i.e., RZ26L 1.05GB, RZ28B 2.1GB)

   ** For a complete listing of CPU upgrades, refer to the most current 
      Systems and Options Catalog.


   Digital believes the information in this publication is accurate as of
   its publication date; such information is subject to change without
   notice.  Digital is not responsible for any advertent errors.

   Digital conducts its business in a manner that conserves the
   environment, and protects the safety and health of its employees,
   customers, and the community.

   The following are trademarks of Digital Equipment Corporation:
   AlphaServer, DECnet, Digital, the DIGITAL logo, MicroVAX, OpenVMS, RZ,
   StorageWorks, ThinWire and VAX.

   PART NUMBER: EC-F4720-93

------------------------------------------------------------------------------
   
   (5b) MicroVAX 3100 30/40/80/90 [23]Systems And Options Catalog Feb 94

   MICROVAX 3100 SYSTEMS AND SERVERS

                                  ---*---

   PRODUCT DESCRIPTION

   MicroVAX 3100 systems are designed to complement today's VAX
   offerings. With enhanced distributed computing capabilities and
   flexibility, they support more than 10,000 commercial and technical
   applications across local or wide area networks.

   MicroVAX 3100 systems offer communications interfaces to support
   distributed applications. Communications options are available as
   add-ons to provide expansion capabilities. MicroVAX 3100 systems
   support synchronous options for wide area communications, and
   asynchronous options, including modem options for terminal and printer
   connections. This large-system networking allows communications in a
   variety of environments, including DECnet, TCP/IP, OSI, SNA ,
   and X.25.

   PC clients based on MS-DOS, OS/2, and Macintosh can be connected to
   the MicroVA X 3100 system, enabling the entire business to share
   information. Digital's advanced client/server computing, based on NAS
   (Network Application Support), delivers a wide range of solutions to
   help integrate different desktop workstations and PCs in an
   organization.

   MicroVAX 3100 systems are designed and engineered to handle demanding
   computing tasks. Factory-loaded operating system software and
   automatic voltage- sensing power capability make them an ideal choice
   for any office. Featuring mid-range system performance while retaining
   compact desktop packaging, MicroVA X 3100 systems require no special
   facility plans, air conditioning, or power requirements.

   MicroVAX 3100 systems support synchronous, asynchronous SCSI
   transmission, providing more balanced and higher performance systems.

   The Model 30 is designed to support a broad range of computing needs
   and a larg e number of users. Its system performance means quick
   access to files and applications and fast wide area networking.

   The Model 40 offers the same fast performance as the Model 30 but in a
   more expandable desktop system. Additional internal SCSI storage,
   asynchronous, synchronous, and modem options can be added to meet
   current and future application needs. The Model 40 is also an
   excellent server for multi-PC environments, offering a single source
   of support for the NAS environment. The Model 40 is board upgradable
   to Models 80 and 90.

   The Model 80 is ideal for organizations that require high performance,
   expandability, and storage capacity in a desktop system. It runs most
   applications twice as fast as the Model 30 and Model 40. The Model 80
   system ca n be expanded to 72 Mbytes of memory to meet increased
   application demands. It is also board upgradable to Model 90.

   The Model 90 has over twice the CPU performance and enhanced Ethernet
   performance compared to the Model 80. Plus an optional SCSI-2 card
   provides support for seven additional external SCSI devices. ECC
   memory can be expanded to 128 Mbytes for additional user and
   application support.

   MicroVAX 3100 systems are designed for sustained reliability and ease
   of serviceability. Their compact size provides mid-range systems
   performance at entry-level system prices.

                                  ---*---

   MICROVAX 3100 COMPARISON CHART

                  MODEL 30        MODEL 40        MODEL 80        MODEL 90
                  --------        --------        --------        -------- 
Performance (TPS)
                     32              32              60              85
Enclosures
                   BA42-A          BA42-B          BA42-B          BA42-B
Memory: Included
                   8 Mbytes       8 Mbytes         8Mbytes     16 or  64 Mbytes
Maximum 
                  32 Mbytes      32 Mbytes         72 Mbytes   80 or 128 Mbytes
Storage Devices (internal maximum) 
                     3               5               5               5
Storage Devices (total internal and external)
                    7(1)            7(1)            7(1)            14(2)
Storage Capacity  
                15.5 Gbytes(3)  17.5 Gbytes(4)  17.5 Gbytes(4)  30.2 Gbytes(5)

                                  ---*---

   (1) Maximum two SZ12 expansion enclosures can be configured with
       MicroVAX 3100 system---each SZ12 can be configured with up to two
       storage devices.

   (2) SCSI card option (KZDDA-xx) supports seven additional external
       SCSI devices .

   (3) With three internal 2.1-Gbyte (RZ28) disks plus one 2.1-Gbyte
       (RZ28) and two 3.57-Gbyte (RZ74) in BA350-SA StorageWorks expansion
       shelf.

   (4) With four internal 2.1-Gbyte (RZ28) disks plus one 2.1-Gbyte
       (RZ28) and two 3.57-Gbyte (RZ74) in BA350-SA StorageWorks expansion 
       shelf.

   (5) Same as Note 4, plus additional SCSI option card (KZDDA)and one
       BA350-SA expansion shelf with six 2.1-Gbyte (RZ28) disks. BA350
       supports one additional half-height tape drive.

                                  ---*---

   STEP 1---SYSTEMS

   Select system. Note that disk and tape are not included with
   traditional and base systems and must be ordered separately. OpenVMS
   user licenses may be ordered as needed.

                                  ---*---

   MICROVAX 3100 MODEL 30, MODEL 40, MODEL 80, AND MODEL 90 SYSTEMS INCLUDE

   o Small enclosure with CPU/FPU (Model 30) or large enclosure with
     CPU/FPU (Model 40, Model 80, and Model 90)

   o 8 Mbytes of parity memory: Models 30, 40, 80; 16 or 64 Mbytes of ECC
     memory: Model 90 (base memory on Models 30 and 40 on CPU; base memory
     on Models 80 and 90 in DSIM slots)

   o 802.3/Ethernet interface (ThinWire/thick wire) with terminators

   o Ethernet kit; includes ThinWire T-connector with BNC terminators and
     15-pin thick wire terminator

   o Synchronous SCSI-2 interface for connecting internal and external
     SCSI devices; external connection via a 50-pin external SCSI-2
     connector

   o Three DEC-423 asynchronous serial lines (MMJ data leads only)

   o EIA-232 asynchronous serial line with modem control (25-pin
     D-subminiature connector)

   o H8575-A 25-pin-to-MMJ DEC-423 to EIA-232 adapter

   o External SCSI terminator
 
   o 7.6-meter (25-foot) console terminal cable

   o 120-V power cord (country-specific power cord required for 240-V use; see
     Step 8)

   o Universal power supply that automatically adjusts to 88--132 Vac or
     176--264 Vac

   o Hardware documentation (Model 30: QZ-K44AA-GZ; Models 40, 80, and
     90: QZ-K44AB-GZ)

   o OpenVMS base license (with POSIX)

   o Factory-installed software*

   o One full-year product warranty (standard warranty recommended)

   *Delivery of the software on a system disk is not warranted. It is
   provided as a convenience to the customer. Customers are encouraged to
   purchase the necessar y media and documentation kits that include
   complete installation instructions.  See Step 7 for details.

                                  ---*---

   ADVANTAGE-SERVER SYSTEMS


    ORDER #     uVAX 3100   MEM.   NAS SW     DISK DRIVE      CD-ROM
    -------     ---------   ----   -------  --------------  -------------
   DV-31GBA-CA   Model 40   6 MB   NAS 200  RZ25L (535 MB)  RRD42 (600 MB)
   DV-31HCB-DA   Model 80  40 MB   NAS 300  RZ26L (1.05 GB) RRD42 (600 MB)
   DV-31PCA-EA   Model 90  64 MB   NAS 300  RZ26 (1.05 GB)  RRD42 (600 MB)

                                  ---*---

   NOTE: NAS 200 software includes DECnet/OSI end-system license, TCP/IP,
   and PATHWORKS; NAS 300 software includes NAS 200 and Rdb runtime
   licenses.


OPENVMS TRADITIONAL SYSTEMS

 o OpenVMS 2-user license
 o Rdb Runtime license
 o DECnet/OSI end-system license

                                  ---*---


   ORDER NUMBER   MICROVAX 3100     MEMORY
   ------------   -------------    --------- 
   DV-31FTA-B9       Model 30      8 Mbytes
   DV-31GTA-B9       Model 40      8 Mbytes
   DV-31HTA-B9       Model 80      8 Mbytes
   DV-31PTA-C9       Model 90      16 Mbytes
   DV-31PTA-E9       Model 90      64 Mbytes


                                  ---*---


   OPENVMS BASE SERVERS

    o OpenVMS base license

   ORDER NUMBER    MICROVAX 3100     MEMORY
   ------------    -------------    --------
   DV-31FAA-B9        Model 30      8 Mbytes
   DV-31GAA-B9        Model 40      8 Mbytes
   DV-31HAA-B9        Model 80      8 Mbytes
   DV-31PAA-C9        Model 90      16 Mbytes
   DV-31PAA-E9        Model 90      64 Mbytes


                                  ---*---


   STEP 2---STORAGE

   Select storage devices as required. See Chapter 9, Storage Devices,
   for further details.

                                  ---*---


   STEP 2A---INTERNAL STORAGE

   CONFIGURATION RULES
 

   o Storage devices are supported in any one of the following
     combinations:

      --Three RZ2x half-height disk drives, or
      --Two RZ2x half-height disk drives and one RX26
        removable media device, or
      --One RZ2x half-height disk drives and one removable
        media device (RRD42, TLZ06, TZ30 or TZK10).

   o Maximum one internal tape device

   o Order a load device if necessary---VMScluster satellite
     members or systems being loaded over the network
     do not require a load device. (One TK50Z or RRD42
     is required as a load device if TZ30 storage is not
     present.)

   o Selection of one factory-installed RZ25L, RZ26L, or
     RZ28 required (for Base Systems) for factory-installed
     software.

   o Field-installed options require Customer Services
     installation.


   MODELS 40, 80, AND 90

   o System supports maximum of five internal drives in any
     one of the following combinations:

     --Five RZ2x half-height disk drives, or
     --Four RZ2x half-height disk drives and one TZ30
       removable media device
     --Three RZ2x half-height disk drives and two removable
       media devices (RX26, RRD42, TLZ06, or TZK10).

   o One factory-installed RZ25L, RZ26L, or RZ28 is required
     for factory-installed software.

   o Order a load device if necessary---VMScluster satellite
     members or systems being loaded over the network
     do not require a load device. (One TK50Z or RRD42
     is required as a load device if TZ30 storage is not
     present.)

   o Field-installed options require Customer Services
     installation.

                                  ---*---


   RZ25L-EN/EK     535-Mbyte 3.5-inch half-height embedded SCSI fixed 
                   disk drive; factory/field installed

   RZ26L-EN/EK     1.05-Gbyte 3.5-inch half-height embedded SCSI fixed 
                   disk drive; factory/field installed

   RZ28-EN/EK      2.1-Gbyte 3.5-inch half-height embedded SCSI fixed 
                   disk drive; factory/field installed



   REMOVABLE MEDIA DEVICES

   RRD42-EN/EK     600-Mbyte CD-ROM drive for Models 40, 80, and 90 
                   systems; factory/field installed

   RX26-EN/EL      2.8-Mbyte diskette drive; factory/field installed

   TLZ06-HF/HG     4.0-Gbyte 4mm 3.5-inch DAT drive

   TZK10-HF/HG     320/525-Mbyte quarter-inch cartridge (QIC) tape drive;
                   factory/field installed

   TZ30-EK/EL      95-Mbyte streaming tape drive; factory/field installed


                                  ---*---

   STEP 2B---EXTERNAL STORAGE

   CONFIGURATION RULES

   o Models 30, 40, 80:
     --Maximum seven SCSI-2 devices
     --Maximum two SZ12-2 dual-drive expansion boxes or one BA350-SA 
       StorageWorks expansion shelf

   o Model 90:
     --Maximum 14 SCSI devices; with additional SCSI card option

   Use the following table to calculate external SCSI bus length. NOTE:
   Devices include necessary cables except TZ85, which requires BC09P
   cable.


MAXIMUM SCSI BUS LENGTH: 

               MODEL 30            MODEL 40/80               MODEL 90
               --------            -----------               --------

Internal       1.4 m (55.1 in.)   2 m (78.7 in.)           2.25 m (88.6 in.)
External       4.6 m (180.6 in.)  4 m (157.4in.)          3.75 m (148.0 in.)
KZDDA internal    N/A                  N/A              .73 m (29.0 in.)
KZDDA external    N/A                  N/A             5.27 m (207.5 in.)



   TABLETOP        INTERNAL             EXTERNAL
   ENCLOSURE     CABLE LENGTH         CABLE LENGTH
   ---------   -----------------     ---------------
     SZ12      0.78 m (31 inches)    0.6 m (24 inches)
     RRD42     0.35 m (14 inches)    0.45 m (18inches)
     TK50Z     0.45 m (18 inches)    0.45 m (18inches)
     TLZ06     0.32 m (12.6 inches)  0.91 m (36inches)
     TSZ07     10 cm (3.9 inches)
     TZ85      0.28 m (11 inches)
     TLZ6L     0.22 m (8.6 inches)   0.91 m (36inches) or 1.82 m (72 inches)
     BA350     0.90 m (34.7 inches)  1.83 m (72inches)


                                  ---*---

   KZDDA-AA/AF     SCSI controller card supports seven additional external 
                   SCSI devices, factory/field installed (Model 90 only)

   SZ12            Refer to page 9.88 for SZ12 dual-drive expansion box 
                   ordering information.

   TK50Z-GA/G3*    95-Mbyte 5.25-inch tabletop streaming cartridge tape
                   drive; 120V/240 V

   RRD42-FA/DG*    600-Mbyte 5.25-inch tabletop CD-ROM drive; 120 V/240V

   TLZ06-FA*       4.0-Gbyte 3.5-inch tabletop DAT drive with universal 
                   power supply; includes 120-V power cord

   TLZ6L-DA        TLZ06 tape drive with integrated magazine autoloading

   TSZ07-CA*       140-Mbyte, 1600/6250-bit-inch SCSI 9-track tape with 
                   universal power supply; requires TSZK7-xx country kit, 
                   see Chapter 9, Storage Devices

   TZ85-TA*        2.6-Gbyte 5.25-inch tabletop tape drive; requires BC06P
                   cable

   BA350-SA**      StorageWorks single-height shelf, configured for seven
                   3.5-inch devices, or four 3.5-inch devices and one 
                   5.25-inch full-height device, or one 3.5-inch device and 
                   two 5.25-inch full-height devices. Supported devices are 
                   RZ25L-VA, RZ26L-VA, RZ28-VA, RZ74-VA, TLZ06-VA, TLZ6L-VA, 
                   TZK10-VA, TZK11-VA. See Chapter 9, Storage Devices.

   BC06P-2F        TZ8x cable, 2.5 ft (0.8 m)

   BC06P-06        TZ8x cable, 6 ft (1.8 m)

   BC06P-09        TZ8x cable, 9 ft (2.7 m)

    * Country-specific power cord required for 240-V use, refer to Chapter 9,
      Storage Devices.

   ** One BA350-SA expansion unit is supported per single ended SCSI bus, 
      no other external device can be connected to system with BA350-SA unit.

                                  ---*---

   STEP 3---MEMORY

   Base systems include 8, 16, or 64 Mbytes of memory---base memory on
   Models 30 and 40 on CPU; base memory on Models 80 and 90 in first DSIM
   slot. Model 30 and 40 systems can be expanded to 32 Mbytes of
   (parity-only) memory, Model 80 systems can be expanded to 72 Mbytes of
   (parity-only) memory, and Model 90 systems can be expanded to 128
   Mbytes of (error correction)memory.

   DIGITAL SINGLE IN-LINE MEMORY (DSIM)

   MS44L-BA         8 Mbytes of DSIM modules for Model 30, 40, and 80 systems
   MS44-DA         32 Mbytes of DSIM modules for Model 80 systems
   MS44L-BC        16 Mbytes of DSIM modules for Model 90 systems
   MS44-DC         64 Mbytes of DSIM modules for Model 90 systems
  

   MICROVAX 3100 MEMORY CONFIGURATION CHART


                               REQUIRED MEMORY
                               =============== 

   MODELS 30 & 40    MODEL 80      MODEL 90     16-MBYTE BASE   64-MBYTE BASE
   --------------  ------------   ------------  -------------   -------------
   16 Mbytes       1 x MS44L-BA   1 x MS44L-BA       N/A             N/A
   24 Mbytes       2 x MS44L-BA   2 x MS44L-BA       N/A             N/A
   32 Mbytes       3 x MS44L-BA        N/A       1 x MS44L-BC        N/A
   40 Mbytes            N/A       1 x MS44-DA         N/A            N/A
   48 Mbytes            N/A       1 x MS44L-BA and    N/A            N/A
                                  1 x MS44-DA
   72 Mbytes            N/A       2 x MS44-DA         N/A            N/A
   80 Mbytes            N/A            N/A       1 x MS44-DC     1 x MS44L-BC
   128 Mbytes           N/A            N/A            N/A        1 x MS44-DC

                                  ---*---
 

   STEP 4---NETWORKS AND COMMUNICATIONS


   Select devices as required. See Chapter 8, Networks, Communications,
   and Cables , and the Networks Buyer's Guide for more information.


   HOST-BASED COMMUNICATIONS CONTROLLERS

   Select host-based communications controllers for standalone systems
   (without LA N connectivity), or for other requirements.

                                  ---*---


   ASYNCHRONOUS MULTIPLEXER OPTIONS
   Select one asynchronous multiplexer for communications expansion.


   DHW41-BA (MODEL 30)
   Provides four EIA-232 lines for a system total of eight asynchronous
   lines (three data only and five with modem control). Includes internal
   logic module with cable, EIA-232 I/O assembly, and external 50-pin to
   4-way 25-pin BC29J-06 1.8-m (6-ft) cable; field installed.


   DHW41-AA (MODEL 30)---DHW42-AA (MODEL 40, MODEL 80, AND MODEL 90)
   Provides eight DEC-423 lines for a system total of 12 asynchronous
   lines (11 data only and one with modem control). Includes internal
   logic module with cable, DEC-423 I/O assembly, external 36-pin
   BC16C-10 3-m (10-ft) cable, and H3104-00 eight-line distribution
   harmonica; factory or field installed.

   DHW42-CA (MODEL 40, MODEL 80, AND MODEL 90)
   Provides eight EIA-232 lines for a system total of 12 asynchronous
   lines (three data only and nine with modem control). Includes internal
   logic module with cable, EIA-232 I/O assembly, and two external 50-pin
   to 4-way 25-pin BC29J-06 1.8-m (6-ft) cables; factory or field
   installed.

   DHW42-BA (MODEL 40, MODEL 80, AND MODEL 90)
   Provides 16 DEC-423 lines for a system total of 20 asynchronous lines
   (19 data only and one with modem control). Included internal logic
   module with cable, DEC-423 I/O assembly, two external 36-pin BC16C-10
   3-m (10-ft) cables, and two H3104-00 eight-line distribution
   harmonica; factory or field installed.


   DHW42-UP (MODEL 40, MODEL 80, AND MODEL 90)
   Upgrades DHW42-AA to DHW42-BA; field installed only.


   NOTE: Addition of DHW4x options increases number of users; a VMS
   license upgrad e may be required.


   SYNCHRONOUS COMMUNICATIONS OPTION CONFIGURATION RULES

   o Select ONE synchronous option.

   o EIA-232/V.24 cable (BC19D-02) is included---select alternate cables for
     EIA-423/V.10 and EIA-422/V.11 connection.

                                  ---*---

   DSW41-AA (MODEL 30)---DSW42-AA (MODEL 40, MODEL 80, AND MODEL 90)
   EIA-232 synchronous controller (DSW41-AA provides one line; DSW42-AA
   provides two lines). Includes synchronous logic module, I/O assembly,
   and external EIA-232 0.6-m (2-ft) adapter cable.

   BC19B-02        EIA-422/V.11 0.6-m (2-ft) adapter cable
   BC19E-02        EIA-423/V.10 0.6-m (2-ft) adapter cable
   QL-VAWA9-AA     One-time single-user VAX WAN Device Driver license 
                   for use of synchronous port
   QA-VAWAA-H5     VAX WAN Device Drivers media (TK50) and documentation

   NOTE: VAX WAN Device Driver included in VMS Consolidated Software Disk 
   CD-ROM media.

   See Step 7 for details. VAX WAN Device Driver V1.2 or higher required.

                                  ---*---

   LAN COMMUNICATIONS CONTROLLER
   802.3/Ethernet Interface (ThinWire/thick wire selectable) included
   with system.  Connection of system to Ethernet requires a ThinWire BNC
   connection (e.g., BC16 M cable) or a thick wire 15-pin AUI transceiver
   cable (e.g., BNE3x).

                                  ---*---


   LOCAL AND WIDE AREA COMMUNICATIONS SERVERS
   Each communications server requires an 802.3/Ethernet connection.
   Depending on the server selected, either a ThinWire BNC connection
   (e.g., BC16M cable)or a thick wire 15-pin AUI transceiver cable is
   required (e.g., BNE3x). Software media and documentation and cables
   are also required. See description in Chapte r 8, Networks,
   Communications, and Cables, for ordering information.

   DECSERVER 90M, 90TL, 900TM, 90L+, 700, 250, AND MUXSERVER 90, 320, 380
   COMMUNICATIONS AND PRINTER SERVERS
   Select a terminal or printer server to provide users with multiple
   session access to systems on a LAN, to minimize on a LAN, to minimize
   cabling complexit y and costs, and to conserve host resources such as
   backplane slots.

   DEC WANROUTER 90, 250, 500; DECBROUTER 90; PROTEON 4100+, CNX 500; AND
   DECNIS 500, 600 MULTIPROTOCOL ROUTERS
   Select a router to cost-effectively link a LAN to a remote system or
   another LA N and to offload routing overhead from the application host
   system.

                                  ---*---

   INFOSERVER 1000 NETWORK STORAGE SERVER
   To provide initial system load (ISL) capabilities order InfoServer
   Local Area Compact disc. Other configurations are offered for
   tape/backup and for serving more CD-ROMs. InfoServer systems support
   CD-ROM, hard drives, magneto-optical and tape drives. InfoServer 1000
   systems can serve up to seven SCSI devices; an InfoServer 150 serves
   up to 14 total. See descriptions in Chapter 9, Storage Devices,for
   ordering information.

                                  ---*---

   NETWORK CONNECTIVITY PRODUCTS
   See Chapter 8, Networks, Communications, and Cables, and the Networks
   Buyer's Guide.

                                  ---*---


   STEP 5---CONSOLE TERMINAL
   A console device is necessary for a system to function. Console cable
   included with system. Order video terminals (e.g., VT420) for each
   system unless otherwise available. If logging is required, a
   combination of video terminal an d LA75 is recommended. See Chapter
   10, Terminals, Scanners, Printers, for orderin g information.

                                  ---*---

   STEP 6---TERMINALS AND PRINTERS
   Select terminals and serial printers as required. Serial printers
   connect to an asynchronous line. A cable (e.g., BC16E-25) must be
   ordered with each unless otherwise provided. See Chapter 10,
   Terminals. Scanners, Printers, for ordering information.

                                  ---*---

   STEP 7---SOFTWARE

   Licenses required to support additional users beyond those included in
   base systems.

   SOFTWARE PROCESSOR CODE               MicroVAX 3100 = P
   CLUSTERWIDE LICENSE RATING            MicroVAX 3100 = 20 (C)

                  OPENVMS USER LICENSES
   --------------------------------------------------------
   QL-XULA9-BB     OpenVMS/VAX interactive 1-user license
   QL-XULA9-BC     OpenVMS/VAX interactive 2-user license
   QL-XULA9-BD     OpenVMS/VAX interactive 4-user license
   QL-XULA9-BE     OpenVMS/VAX interactive 8-user license
   QL-XULA9-BF     OpenVMS/VAX interactive 16-user license
   QL-XULA9-BG     OpenVMS/VAX interactive 32-user license
   QL-XULA9-BH     OpenVMS/VAX interactive 64-user license
   QL-XULAA-BR     OpenVMS/VAX interactive 128-user license
   QL-XULAB-BR     OpenVMS/VAX interactive 256-user license
   QL-VBRAP-AA     VAXcluster license for multiuser systems


   SOFTWARE MEDIA AND DOCUMENTATION 
   Choose operating system media and documentation. One required for
   first system on site. System support for Models 30/40/80 requires V5.5
   or higher; Model 90 requires V5.5-2.

   QA-001AA-HX     OpenVMS media with extended documentation.
   QA-09SAA-HX     OpenVMS media with base documentation.

   NOTE: x denotes the media type: 5 = TK50, 8 = CD-ROM

   OPENVMS CONSOLIDATED SOFTWARE MEDIA AND DOCUMENTATION
   Choose as an alternative to the above OpenVMS kits. Requires RRD42 CD-ROM.

   QA-VWJ8A-A8     OpenVMS and layered product binaries on CD-ROM without 
                   hardcopy documentation.

   QA-VYR8A-G8     OpenVMS extended online documentation and layered 
                   product online documentation on CD-ROM; requires 
                   DECwindows Bookreader.

                                  ---*---

   QA-358AA-HX     Rdb Runtime media and documentation
   QA-GXXAA-HX     POSIX media and documentation (with IEEE documentation)
   QA-GXXAB-HX     POSIX media and documentation (without IEEE documentation)

   Select the appropriate NAS software level. See description of NAS
   packages on page 12.2. NOTE: The NAS packaged products do not include
   hardcopy documentatio n for the components (the documentation is
   CD-ROM only). To order NAS component hardcopy documentation, see page
   12.5 for listing of order numbers.

   QL-MC1AP-AA     NAS 200 (Network Application Support 200)
   QA-MC1AA-HX     NAS 200 media and documentation kit
   QL-MC2AP-AA     NAS 300 (Network Application Support 300)
   QA-MC2AA-HX     NAS 300 media and documentation kit

   Note: x denotes media type: 8 = CD-ROM, 5 = TK50, M = magtape

                                  ---*---

   STEP 8---POWER CORDS

   Select for 220/240-V systems.

   BN19A-2E        U.K./Ireland
   BN19C-2E        Austria, Belgium, France, Germany, Finland, Holland, Norway,
                   Sweden, Portugal, Spain, and Chile
   BN19E-2E        Switzerland
   BN19K-2E        Denmark
   BN19M-2E        Italy
   BN19U-2E        Israel
   BN19H-2E        Australia, New Zealand
   BN19S-2E        India

                                  ---*---


   MICROVAX 3100 SYSTEM DIAGRAMS
   -----------------------------

   MICROVAX 3100 MODEL 30 SYSTEM DIAGRAM
   [Insert illustration nos. BU-3248 and BU-3249]

   MICROVAX 3100 MODELS 40, 80, AND 90 SYSTEM DIAGRAMS
   [Insert illustration nos. BU-3250 and BU-3251]


   MICROVAX 3100 SPECIFICATIONS
   ----------------------------

   PHYSICAL CHARACTERISTICS

                  MODEL 30                MODELS 40, 80, 90
            ---------------------       ----------------------
   Height    9.90 cm ( 3.90 in.)        14.99 cm ( 5.90 in.)
   Width    46.38 cm (18.26 in.)        46.38 cm (18.26 in.)
   Depth    39.42 cm (15.52 in.)        40.00 cm (15.75 in.)
   Weight   11.40 kg (25.00 lb)(2)      18.40 kg (40.00 lb)(3)


                    MODEL 30       MODEL 40       MODEL 80       MODEL 90
                  ------------   ------------   ------------   ------------
POWER REQUIREMENTS 
Nominal voltage:  120/240 Vrms   120/240 Vrms   120/240 Vrms   120/240 Vrms
Pwr src phasing:     Single         Single         Single         Single
Nominal frequency:  50--60 Hz      50--60 Hz      50--60 Hz      50--60 Hz
Voltage range:     88--132 Vrms   88--132 Vrms   88--132 Vrms   88--132 Vrms
                  176--264 Vrms  176--264 Vrms  176--264 Vrms  176--264 Vrms
Line freq tolerance  47--63 Hz     47--63 Hz      47--63 Hz      47--63 Hz
Typ running current  1.0/0.55 A    1.1/0.6 A      1.2/0.65 A     1.5/0.75 A
Typ pwr cons (Watts)  120/132       132/144        144/156         180/40

STANDARD COMMUNICATION
Minimum MMJ lines     3 DEC-423     3 DEC-423      3 DEC-423      3 DEC-423
Modem lines           1 EIA-232     1 EIA-232      1 EIA-232      1 EIA-232
Ethernet                 Thick wire and ThinWire supported on all models

COMMUNICATIONS OPTIONS(1)
MMJ lines              8 DEC-423     8 DEC-423     8 DEC-423      8 DEC-423
MMJ lines                 --        16 DEC-423    16 DEC-423     16 DEC-423
Modem lines            4 EIA-232     8 EIA-232     8 EIA-232      8 EIA-232
Synchronous lines       1 synch.      2 synch,      2 synch.       2 synch.

   OPERATING ENVIRONMENT   
      Temperature (sea level) 10 deg. --40 deg. C (50 deg. --90 deg. F)
      Relative humidity 10%--80% noncondensing; 20% to 80% if tape drive
      is present.  Maximum operating altitude 2.4 km (8,000 ft).


   (1) DEC-423, EIA-232 and synchronous lines can be ordered separately.
       The DEC-4 23 and EIA-232 options cannot be configured together in 
       the same system. An 8- line DEC-423 to 16-line DEC-423 upgrade 
       option is available for the MicroVAX 3100 Model 40 and Model 80 
       systems.

   (2) Approximate weight with one disk.

   (3) Approximate weight with three disks.
 
------------------------------------------------------------------------------
   
   (5c) Interfacing a[24] third party SCSI drive to your 3100 Q/A

   3rd Party Drives in VAXstation 3100's

   Usually the 3100 series will take any SCSI drive... read below for
   discussions on this...

   From mandrewsbob.Wittenberg.EDU Fri Dec 22 13:48:09 1995
   Return-Path: mandrewsbob.Wittenberg.EDU
   Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84])
             by mailspool.liv.ac.uk (8.6.12/8.6.6-LIV-CSD) with ESMTP id 
             NAA03056 for ; Fri, 22 Dec 1995 13:48:02 GMT
   Received: from liverbird.liverpool.ac.uk (actually livbird.liv.ac.uk)
             by mail.liv.ac.uk with SMTP (PP); Fri, 22 Dec 1995 13:47:37 +0000
   Received: from eclipse.Wittenberg.EDU by livbird.liv.ac.uk with SMTP (PP);
             Fri, 22 Dec 1995 13:47:21 +0000
   Received: from bob.Wittenberg.EDU (bob.Wittenberg.EDU [136.227.128.4])
             by eclipse.Wittenberg.EDU (8.6.11/eclipse-950922)
             with ESMTP           id JAA01948 for ;
             Fri, 22 Dec 1995 09:17:06 -0500
   Received: (from mandrewslocalhost)
             by bob.Wittenberg.EDU (8.7.1/8.7.1/bob-950925) id NAA06903;
             Fri, 22 Dec 1995 13:45:50 GMT
   Date: Fri, 22 Dec 1995 13:45:50 GMT
   From: Mike Andrews
   Message-Id:
   To: edwardliverpool.ac.uk
   Subject: Re: SCSI on VS3100
   Newsgroups: comp.sys.dec
   References:
   Organization: Wittenberg University, Springfield OH
   X-Newsreader: NN version 6.5.0 #8 (NOV)
   Status: RO

   In comp.sys.dec you write:

   >Hi there

   >I have a VS-3100/38 with only a 50mb Internal SCSI drive. Can I put
   >any SCSI drive in this machine or does it have to be a DEC RZ series??
   >if it does have to be an RZ drive what models can i put in?? thanks???

   Sure, put anything you want in, as long as your boot disk isn't over
   1.08 gig.  (Secondary disks can be bigger.)

   The 100 meg drive (RZ23??) that came with my VS3100/30 is actually a
   Conner 3100S, not built by DEC.  I've had a number of different drives
   in it, including Maxtor, Quantum, and various Seagates, all of fairly
   recent vintage.  (There's probably not enough cooling inside to
   install a Barracuda, though. :)

   The only glitch is that VMS 6.1 has problems with Seagate disks.  6.0,
   6.2, and 5.x don't have the problem.

  --
  -- Mike Andrews  *  mandrewswittenberg.edu  *  mandrewstermfrost.org (NeXT)
  -- Programmer/Analyst, Wittenberg Univ  *  http://www.termfrost.org/~mandrews

   From leinbergeraxp621.gsi.de Mon Dec 18 20:55:15 1995
   Return-Path: leinbergeraxp621.gsi.de
   Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84]) by
             mailspool.liv.ac.uk (8.6.12/8.6.6-LIV-CSD) with ESMTP id UAA21016
             for ; Mon, 18 Dec 1995 20:55:14 GMT
   Received: from axp621 (actually AXP621.gsi.de) by mail.liv.ac.uk
             with SMTP (PP); Mon, 18 Dec 1995 20:54:53 +0000
   Date: Mon, 18 Dec 1995 21:54:42 +0200
   Message-Id:
   From: leinbergeraxp621.gsi.de (Uwe Leinberger GSI Darmstadt T. 
         06159/71-2148  Fax -2155)
   To: edwardliverpool.ac.uk
   Subject: Re: SCSI on VS3100
   X-VMS-To: smtp%"edwardliv.ac.uk"
   Status: RO

   In article  you write:
   >Hi there
   >
   >
   >I have a VS-3100/38 with only a 50mb Internal SCSI drive. Can I put
   >any SCSI drive in this machine or does it have to be a DEC RZ series??
   >if it does have to be an RZ drive what models can i put in?? thanks???
   >
   >I'm a student and can't afford DEC drives especially when I can get
   >similar SCSI drives with the same capacity for half the price :-)
   >
   >
   >eddy
   >
   >please cc: any replies to:  edwardliv.ac.uk  thanks!!!!!
   >
   >--Eddy Austin                                      In a dog eat dog world
   >edwardliverpool.ac.uk                           you gotta eat some dog!
   >
   >
   You can add any scsi device, of course.
   However, be aware that a BOOT disk (ie the syetm disk) should be 1GB
   max with a VS3100. The console firmware (the equivalent to a bios on a
   PC) does not know how to handle larger disk in these boxes.....

   As pure data disk up to about 8GB are ok with VMS 5.x or lower, and
   starting with 6.x you can use even larger disks (up to I *think* 64 GB
   at least, no good for a student's purse ;-)

   I just bought a VS3100 myself to be able to play a bit at
   home.....here for work I have plenty fast alphas to use (but no real
   privs)

   Uwe

   From asiairmail.net Mon Dec 18 20:28:20 1995
   Return-Path: asiairmail.net
   Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84])
             by mailspool.liv.ac.uk (8.6.12/8.6.6-LIV-CSD) with ESMTP id 
             UAA20319 for ; Mon, 18 Dec 1995 20:28:19 GMT
   Received: from server.iadfw.net by mail.liv.ac.uk with SMTP (PP);
             Mon, 18 Dec 1995 20:28:09 +0000
   Received: from fw03-28.ppp.iadfw.net (fw03-28.ppp.iadfw.net [206.66.15.62])
             by server.iadfw.net (8.7/8.7) with SMTP id OAA12352
             for ; Mon, 18 Dec 1995 14:27:59 -0600 (CST)
   Message-Id:
   Date: Mon, 18 Dec 95 14:26:40 -0800
   From: Chris Scheers
   Organization: Applied Synergy, Inc.
   X-Mailer: Mozilla 1.2N (Windows; I; 16bit)
   MIME-Version: 1.0
   Newsgroups: comp.sys.dec
   To: edwardliverpool.ac.uk
   Subject: Re: SCSI on VS3100
   References:
   Content-Transfer-Encoding: 7bit
   Content-Type: text/plain; charset=us-ascii
   Status: RO
   
   Eddy Austin  wrote:
   >Hi there
   >
   >
   >I have a VS-3100/38 with only a 50mb Internal SCSI drive. Can I put any
   [...]
   >SCSI drives with the same capacity for half the price :-)

   I also have a VS3100/38 and have found it to be pretty tolerant of
   foreign SCSI drives.  In fact, it has worked with every SCSI drive I
   have put on it!  (Of course, I've probably just been lucky so far!)

   There are a few gotchas to look out for:
 
   1)  The system (i.e., boot) disk can not be larger than about 1GB.  I
   use a Seagate ST41200N (a CDC Wren VII) which is about 1.03 GB. (NOTE:
   Data disks may be larger.  See (3) below.)

   2)  If the device ID returned from the drive is longer than 7 (maybe 8)
   characters, the SCSI self test will fail and the system will not
   autoboot.  Nothing is really wrong.  Just do a manual boot (enter B at
   the >>> prompt) and the system will boot properly.

   3)  The maximum disk size depends on your version of VMS.  To use
   drives larger than 1GB, you need VMS 5.3-(something) or later.  To use
   drives larger than 4GB, you need a fairly recent release of VMS, but
   I'm not sure which.  Probably VMS 6.2 or later.

   I hope this helps.  Good luck!

   -----------------------------------------------------------------------
   Chris Scheers, Applied Synergy, Inc.

   817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asiairmail.net


   Date:          4 Jan 1996 02:11:45 GMT
   From:          [1]Chris Scheers (asiairmail.net)
   Organization:  Applied Synergy, Inc.
   Newsgroups:    [2]comp.sys.dec
   References:    [3]1

   jcpwerple.net.au (John Peterson) wrote:
   >A few days I posted a query re. using 3rd Party SCSI Drives in
   >Vaxstation 3100 Model 30. Thanks for the answers.
   >
   >I have since tried a Quantum LPS240 SCSI in this machine. VMS does not
   >recognise it (cannot initialize it)
   >At the monitor level (>>>) the drive is recognised correctly complete with
   > size, type (LPS240) etc.
   >
   >After booting VMS from Netwok/CD-ROM the device appears as DKA300:
   >SHO DEV indicates a "GENERIC SCSI DRIVE". When trying to initialize
   >the drive, I get the error  %INIT-F-DRVERR, Fatal Drive Error.
   >
   >Trying with an RZ22 works straight away.
   >
   >Am I missing something? e.g. Is some other low level formatting step
   >required.

   You may need to do a low level format from the console.  Before you do
   that, however, I would try something else first: From the console, do
   a BOOT DKA300 to see if the system can access the drive correctly.
   The drive should spin up and be accessed a bit, and then the console
   will return an error indicating that the file system was bad or that
   it couldn't find the file.  This will show that it can at least access
   the drive.  Knowing the results of this might give us other clues.

   WARNING: THE FOLLOWING PROCEDURE MAY MAKE THE DRIVE UNUSABLE!!!

   If you want to do a low level format, use the console command TEST 75
   For a DKA300 drive, the responses would be "0" (SCSI bus A), "3" (ID
   #3), "1" (Yes, do it!)  If this succeeds, you should then be able to
   do an INIT from VMS.

   If it fails, it may have left the drive in a condition where it won't
   work on either the VAX or on the original system.  For example, I once
   had a drive which would not work on either the VAX or the original PC
   (neither machine could reformat it) after I tried to format it on the
   VAX.  After reformatting the drive on an Amiga, I was able to reformat
   it on the PC and everything was happy again.  (Sometimes (Most of the
   time?), SCSI is magic.)

   BTW: I have successfully used a Quantum LPS50S on a VS4000-VLC.

   >Also, Could someone also shed some light on the meaning of the SS, EP
   >and WS jumpers on the LPS240S drive.

   I don't know about the others, but "EP" is probably Enable Parity.
   Parity should be enabled for the VAX.  (If the jumper is off, this
   might explain the problems you are seeing.)

   -----------------------------------------------------------------------
   Chris Scheers, Applied Synergy, Inc.

   817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asiairmail.net

   References

      1. mailto:asiairmail.net
      2. news:comp.sys.dec
      3. http://anacin.nsc.vcu.edu/Bullseye/news/88/25/4cdnrm:\
         24meq:40werple:2enet:2eau.html
   
------------------------------------------------------------------------------

   (5d) Design of the MicroVAX-3100/90 from the Digital Technical Journal
                     Volume 4, Number 3, Summer 1992 

                  The Design of the VAX 4000 Model 100 and
                   MicroVAX 3100 Model 90 Desktop Systems

                 By Jonathan C. Crowell and David W. Maruska

   1  Abstract

   The MicroVAX 3100 Model 90 and VAX 4000 Model 100 systems were
   designed to meet the growing demand for low-cost, high-performance
   desktop servers and timesharing systems. Both systems are based on the
   NVAX CPU chip and a set of VLSI support chips, which provide
   outstanding CPU and I/O performance.  Housed in like desktop
   enclosures, the two systems provide 24 times the CPU performance of
   the original VAX-11/780 computer. With over 2.5 gigabytes of disk
   storage and 128 megabytes of main memory, the complete base system
   fits in less than one cubic foot of space. The system design was
   highly leveraged from existing designs to help meet an aggressive
   schedule.


   2  Introduction

   The demand for low-cost, high-performance desktop servers and
   timesharing systems is increasing rapidly. The MicroVAX 3100 Model 90
   and VAX 4000 Model 100 systems were designed to meet this demand. Both
   systems are based on the NVAX CPU chip and a set of very large-scale
   integration (VLSI) support chips, which provide outstanding CPU and
   I/O performance.[1]

   Each member of the MicroVAX 3100 family of systems constitutes a low-
   cost, general-purpose, multiuser VAX system in an enclosure that fits
   on the desktop. This enclosure supports all the required components of
   a typical system, including the main memory, synchronous and
   asynchronous communication lines, thick-wire and ThinWire Ethernet,
   and up to five small computer system interface (SCSI)-based storage
   devices.

   The MicroVAX 3100 Model 90 system replaces the Model 80 as the top
   performer in the line; the new model has considerably more than twice
   the CPU power of the previous model.[2] The Model 90 system also
   includes performance enhancements to the Ethernet and SCSI adapters,
   as well as an increased maximum system memory of 128 megabytes (MB).
   The CPU mother board for the MicroVAX 3100 Model 90 system is called
   the KA50.

   The VAX 4000 Model 100 system is housed in the same desktop packaging
   as the MicroVAX 3100 Model 90 and provides the same base
   functionality. The VAX 4000 Model 100 adds two key features found in
   all previous VAX 4000 systems, i.e., Digital Storage Systems
   Interconnect (DSSI) storage and Q-bus expansion. The CPU mother board
   for the VAX 4000 Model 100 system is called the KA52.
   
   The KA50 and KA52 CPUs are built from a common CPU mother board
   design; the base CPU mother board is configured to create either the
   KA50 or the KA52 product module. The DSSI and Q-bus optional hardware
   is added to the CPU mother board to convert a KA50 to a KA52. Also, to
   provide the additional superset functionality found on the KA52 CPU,
   the different system read-only memories (ROMs) are added during the
   manufacturing process.  In this paper, the KA50 and KA52 CPUs are
   referred to as the CPU mother board or module, except where
   differences exist.

   The system design was highly leveraged from existing designs to help
   meet an aggressive schedule. This paper describes the design and
   implementation of these systems.


   3  Design Goals

   The design team's primary goal was to develop a CPU mother board that
   would provide at least twice the CPU performance of the MicroVAX 3100
   Model 80, while supporting all of the same I/O functionality of the
   previous systems.  This new system would leverage the core CPU design
   from the VAX 4000 Model 500 system, thus delivering the high
   performance of the NVAX CPU chip to the desktop.[3]
 
   The team set additional goals to increase system capability and
   performance. These goals were to

   1. Increase the maximum system memory from 72MB to 128MB
 
   2. Provide error correction code (ECC) protection to memory using 
      memory arrays that previously supported only parity
  
   3. Increase the performance of the Ethernet adapter
  
   4. Increase the performance of the SCSI adapter


   Early in the project, the team proposed creating a second CPU design
   that would have the features of the larger VAX 4000 systems. This
   proposal resulted in the design of a DSSI adapter option for the CPU
   mother board, as well as a Q-bus adapter to provide a means to upgrade
   the CPU power of older Q-bus{-}based MicroVAX systems.
 
   The project to design, implement, and field-test these systems was
   accomplished under an aggressive schedule. Both designs were ready to
   ship to customers in just over nine months from the official start of
   the project.


   4  System Overview

   The MicroVAX 3100 Model 90 system supports the same I/O functionality
   as the previous generation of systems, the MicroVAX 3100 Models 40 and
   80.  The features include a SCSI storage adapter, 20 asynchronous
   communication ports, two synchronous communication ports, and an
   Ethernet adapter.

   The VAX 4000 Model 100 includes the same I/O functionality as the
   MicroVAX 3100 Model 90. In addition, the system provides the I/O
   functionality of the larger VAX 4000 systems, that is, a
   high-performance DSSI storage adapter and a Q-bus adapter port that
   connects to an external Q-bus enclosure.

   Both systems provide 24 times the CPU performance of a VAX-11/780
   system.  The memory subsystem uses Digital's MS44 single in-line
   memory modules (SIMMs) and thus provides 16MB, 32MB, 64MB, 80MB, or
   128MB of main memory.

   As shown in Figure 1, the system enclosure used to house both systems,
   namely the BA42B, provides mounting for the CPU mother board, up to
   five locations for disk and tape devices, a 166-watt power supply, and
   fans for cooling the system elements. In addition, the enclosure
   shields the system from radiated emissions. All I/O connections are
   filtered and exit the enclosure through cutouts in the rear panel. The
   system enclosure is compact and measures 14.99 centimeters (5.9
   inches) high by 46.38 centimeters (18.26 inches) wide by 40.00
   centimeters (15.75 inches) deep.

   The system enclosure contains two shelves that support the mass
   storage devices. In the MicroVAX 3100 Model 90, these storage
   locations are cabled to support SCSI disks and tapes. The upper shelf
   supports three SCSI disks, whereas the lower shelf supports two SCSI
   devices (any combination of removable or 3 1/2-inch disks) with access
   through a door in the front of the enclosure. In the VAX 4000 Model
   100, the top shelf is configured to support three 3 1/2-inch DSSI
   disks; the bottom shelf supports two SCSI devices, as in the MicroVAX
   3100 Model 90.

   The VAX 4000 Model 100 DSSI support is provided by a high-performance
   DSSI adapter card based on the shared-host adapter chip (SHAC), i.e.,
   a custom VLSI design with an integrated reduced instruction set
   computer (RISC) processor.[3] The system is configured with DSSI as
   the primary disk storage. The DSSI bus exits the enclosure by means of
   a connector on the back panel. This expansion port can be used to
   connect the system to additional DSSI devices, or to form a DSSI-based
   VAXcluster with a second VAX 4000 Model 100 or any other DSSI-based
   system.

   The Q-bus support on the VAX 4000 Model 100 is provided by the VLSI
   adapter chip, i.e., the CVAX Q22-bus interface chip (CQBIC).[4] There
   are no Q-bus option slots in the system enclosure. The Q-bus connects
   to an expansion enclosure through a pair of connectors at the rear of
   the system enclosure.  Two shielded cables and the H9405 expansion
   module are used to connect the Q-bus to the expansion enclosure. The
   near end of the Q-bus is terminated in the system enclosure.


   5  CPU Mother Board Design

   The design goals presented engineering with constraints that forced
   design trade-offs. Some key constraints were (1) fitting the required
   functionality on a single 10-by-14-inch module; (2) designing the
   system to adhere to the system power and cooling budget; and (3)
   minimizing changes to the functional view of the module over previous
   designs, to decrease the number of software modifications required for
   operating system support.
 
   The primary way the design team minimized system development was to
   leverage as much as practical from existing designs. The CPU mother
   board design used components from the VAX 4000 Model 500, MicroVAX
   3100 Model 80, and VAXstation 4000 Model 90 systems. Using proven
   design components allowed for a shorter development cycle, smaller
   design teams, and consequently, a higher-quality design, while meeting
   an aggressive schedule.
 
   The design is structured so that both CPU mother boards can be built
   using the same printed wiring board (PWB). The added functionality for
   the KA52 is provided by a daughter card, additional hardware and
   cabling, and different system ROMs. The shared design helped reduce
   the complexity in testing and qualifying the system design.

   The CPU module contains three major sections: the CPU core, the memory
   subsystem, and the I/O subsystem. Figure 2 is a block diagram of the
   basic CPU module for the VAX 4000 Model 100 and MicroVAX 3100 Model 90
   systems.  Figure 3 is a photograph of the module, including the DSSI
   daughter card option.

   The CPU mother board includes a linear regulator that generates local
   3.3-volt (V) current for the CPU core chip set. The voltage is stepped
   down from the 5-V supply. The regulator is necessary because the 3.3-V
   direct current (DC) of the system is not sufficient to meet the ±3
   percent tolerance regulation or to supply the required maximum
   current.

                                   NOTE
      Figure 3 (CPU Mother Board) is a photograph and is unavailable.


   CPU Core

   The CPU core consists of three chips: the NVAX CPU chip, the NVAX data
   and address lines (NDAL) memory controller (NMC) chip, and the
   NDAL-to-CVAX pin (CP) bus adapter (NCA) chip. The NVAX chip directly
   controls the 128- kilobyte (KB) backup cache. The core chip set is
   interconnected by means of the NDAL pin bus, as shown in Figure 2. The
   NDAL bus is 64 bits wide, has a 42-nanosecond (ns) cycle time, and
   supports pended transactions.[1] The peak bandwidth of the NDAL bus
   performing 32-byte operations is 152 megabytes per second (MB/s).
   
   NVAX CPU Chip. The NVAX CPU chip is an advanced implementation of the
   VAX architecture in Digital's fourth-generation complementary
   metal-oxide semiconductor (CMOS-4) technology. The NVAX device
   consists of 1.3 million transistors on a die approximately 0.6 inch on
   a side.

   The NVAX CPU chip contains the VAX CPU, a floating-point unit, and
   backup cache controller logic. Some NVAX features that enable it to
   increase performance are the use of a pipelined architecture, a 2KB
   virtual instruction cache (VIC), a 96-entry translation buffer, an
   on-chip 8KB primary cache, and an on-chip backup cache controller. The
   CPU cycle clock and NDAL bus clocks are generated with an on-chip
   clock generator supplied by a 286-megahertz (MHz) oscillator.

   The NVAX CPU is based on a high-performance macropipelined
   architecture similar to that of the VAX 9000 CPU.[1,5] The VIC allows
   the caching of instructions that have already been translated to
   virtual addresses. Having the backup cache controller on the chip
   decreases backup cache access time because no external logic, with the
   resulting delays, is required.

   NVAX Memory Controller Chip. The NMC is the NVAX memory controller
   implemented in Digital's third-generation complementary metal-oxide
   semiconductor (CMOS-3) technology.[6] The NMC consists of 148,000
   transistors and is the high-speed interface to the system main memory.
   The NMC is the arbiter for the three chips on the NDAL bus, namely,
   the NVAX, the NCA, and the NMC. The NMC chip manages the array of
   ownership bits that correspond to each 32-byte segment of memory. Each
   of these segments corresponds to a cache line. The ownership bit
   indicates whether the valid copy of the data is in memory, in the CPU
   write-back cache, or in an I/O devices buffer.
 
   The NMC has four command queues that accept read, write, and remove
   write privilege transactions from the NDAL bus. Buffers hold the read
   data to be returned to the node that requested the data. The NMC and
   the memory subsystem provide the 95MB/s of bandwidth shared by the
   NVAX and the I/O devices.

   NDAL-to-CP Bus Adapter Chip. The NCA chip, also implemented in
   Digital's CMOS-3 technology, is the interface from the NDAL to the CP
   bus.[6] The NCA consists of 155,000 transistors and supports two CP
   buses. The CP bus used on the CVAX microprocessor family is also used
   on many of Digital's custom I/O adapter chips, such as the CQBIC, the
   SHAC, the second-generation Ethernet controller (SGEC), and the system
   support chip (SSC).[3,4,7,8] Thus, the hardware and software designs
   for these I/O functions could be leveraged from previous efforts. The
   NCA performs direct memory access (DMA) from the I/O devices and
   supports the cache consistency protocol required for the NDAL bus.

   The NCA was designed to optimize DMA traffic from CP bus devices. In
   the KA50 CPU, the CP bus devices include the SGEC Ethernet adapter,
   the SSC, the field erasable programmable read-only memory (FEPROM)
   subsystem, the CP-to-EDAL adapter chip (CEAC), and the SCSI quadword
   first in, first out (SQWF) chip. In addition, the asynchronous
   communication option is attached to the CP bus. The KA52 CPU also
   attaches the CQBIC Q-bus adapter chip and the SHAC DSSI host adapter
   chip.


   Memory Subsystem

   The memory subsystem is controlled by the NMC chip. The main memory is
   implemented using MS44 SIMMs and low-cost gate array (LCGA) chips to
   provide an interface between the NMC and the SIMMs.[9] The SIMMs are
   used in groups of four to provide two interleaved banks, each with a
   64-bit data path and eight bits of ECC. This interleaving scheme
   increases the bandwidth of main memory by alternating data between
   both banks of memory. The ECC provides single-bit error correction and
   double-bit error detection.
 
   The individual SIMMs are available in either 4MB or 16MB variants.
   Since four SIMMs form a complete functional set, sets can be 16MB or
   64MB in size. Therefore, because the system supports up to two sets of
   SIMMs, the total system memory size can be either 16MB, 32MB, 64MB,
   80MB, or 128MB, depending on the combination of SIMM size and the
   number of sets.

   To coincide with the cache coherency scheme used in the NVAX CPU chip,
   the NMC keeps track of the cache lines that have write privilege
   reserved by the CPU or I/O devices. This state is stored in separate
   dynamic random- access memories (DRAMs). These DRAMs interface
   directly to the NMC by means of a private bus. The ownership bits are
   protected by ECC.


   I/O Subsystem

   Because the MicroVAX 3100 Model 90 was intended as an upgrade for the
   Model 40 and 80 systems, the I/O subsystem of the earlier systems
   dictated the design of the new Model 90. In addition, the I/O
   subsystem of the KA52 CPU module for the VAX 4000 Model 100 supports
   two functions found in the other VAX 4000 systems, the DSSI adapter
   and the Q-bus adapter.[9] The I/O subsystem includes a ThinWire and
   thick-wire Ethernet adapter, four built- in asynchronous terminal
   lines, a connector for the asynchronous option, and the CEAC and SQWF
   chips.

   A bus interface was incorporated in the I/O subsystem to support the
   DSW42 synchronous communication option, the SCSI adapter chip, and the
   QUART four-port asynchronous controller chip. The CEAC and SQWF chips,
   which are gate arrays designed for the VAXstation 4000 Model 90, are
   used to create the EDAL bus.

   Support for the SCSI bus is provided by the 53C94 SCSI adapter
   chip.[10] The 53C94 chip is interfaced to the system on the EDAL bus
   and uses the SQWF chip to increase its DMA performance. The SQWF chip
   makes it possible to buffer data moving to the CP bus. The SCSI bus
   operates in synchronous mode for high-performance storage access of
   5MB/s.

   The QUART gate array supplies the logic for four built-in serial
   ports.  The QUART, originally used on the DZQ11 Q-bus device, provides
   the same software interface as that device. The third port provides
   modem control functions by means of additional logic; the first,
   second, and fourth ports are data leads only.

   The SGEC Ethernet adapter chip was chosen because it provides higher
   performance than the Ethernet adapter used on the MicroVAX 3100 Model
   80.  The SGEC is the adapter chip used on all VAX 4000 systems. In
   addition, this chip directly interfaces with the CP bus.

   The limited size of the CPU mother board required the DSSI adapter to
   be added by means of a daughter card. The Q-bus adapter chip and bus
   termination are provided directly on the mother board.


   6  Console and Diagnostics

   The MicroVAX 3100 Models 80 and 90 differ in their console designs and
   diagnostics. Because the basic CPU core of the MicroVAX 3100 Model 90
   and the VAX 4000 Model 100 systems is very similar to that of the VAX
   4000 Model 500 system, the design team decided to adopt the console of
   the Model 500 and add the required commands and functionality.
   Borrowing proven designs, such as the console of another NVAX-based
   system, significantly shortened the product development schedule.

   One enhancement to the CPU mother board was the addition of a FEPROM
   subsystem. If an update is required, the console and diagnostic code
   on the CPU can be reprogrammed in the field. In contrast, previous
   systems required the memories to be in sockets and the parts to be
   replaced in the field. With FEPROMs, a program is loaded from any
   bootable device. This program erases the FEPROMs and reprograms them
   with the new ROM image. This enhancement serves as an easy mechanism
   for updating the ROMs in the field to provide new features or to fix
   bugs that may be discovered.

   On power-up, the CPU starts executing from the FEPROM memory and runs
   the power-up self-test to help verify that the system is fully
   operational.  Upon completion of the execution of this test, the
   system transfers control to the console program. Depending on the
   values configured in nonvolatile memory, the console program either
   boots the system with the correct parameters or stops for console
   input.
  
   In earlier systems, the speed of executing from ROM could be more than
   an order of magnitude slower than running from cached main memory. The
   NVAX CPU chip added the virtual instruction cache, which allows the
   caching of instruction stream references from I/O space. This feature
   greatly increases the performance of the ROM code.


   Console
   
   The console program gains control of the CPU whenever the processor
   halts or performs a restart operation such as power-up. The console
   provides the following services:

   1. Interface to the diagnostics that test components of the CPU and 
      system
  
   2. Automatic/manual bootstrap of an operating system following 
      processor halts

   3. An interactive command language that allows the user to examine 
      and alter the state of the processor

   There are minor differences between the KA50 and KA52 consoles.
   Largely, these differences relate to the KA52 CPU mother board support
   for the DSSI bus and the Q-bus. Although the console is similar to
   that found on the VAX 4000 Model 500, some new commands were
   implemented to provide functionality that exists on previous MicroVAX
   3100 systems. These commands include LOGIN and SET PSWD (set
   password), which give support for a secure console; SET /SHOW SCSI_ID;
   SHOW CONFIGURATION; SHOW ERROR; and various commands to support a
   system exerciser.

   On the KA52 CPU, the console supports the DSSI bus and the Q-bus with
   a set of commands. These commands allow polling of the DSSI bus to
   determine what devices are present and to configure the internal
   parameters of each device. The system can be booted from devices on
   the SCSI, DSSI, or Q-bus chips, as well as over the Ethernet port.


   Diagnostics

   Diagnostics help isolate faults in the system down to the level of the
   field-replaceable units. Significant effort was expended on the
   development of onboard diagnostics. However, as for the console, the
   philosophy used in developing these diagnostics was to leverage as
   much of the software design as possible from existing designs.

   With the advent of larger boot and diagnostic ROMs, the diagnostic
   coverage of the power-up self-tests greatly increased, including
   extensive testing of the cache, the memory, and the CPU core. These
   tests help assure the customer that a failed component will be
   detected and reported upon power-up. In many cases, the new tests can
   help isolate failures in the individual SIMM or cache chip. This
   feature is used extensively in manufacturing, as well as by field
   service.

   During the power-up sequence, an instruction exerciser (HCORE) is run
   to test the floating-point hardware. This test provides very good
   coverage of the floating-point unit. In the past, HCORE has been run
   as a standalone diagnostic in manufacturing before a system is
   shipped. The design team for the two new desktop systems believed that
   this test should run on every system power-up self-test.

   The CPU core is designed to function over a wide range of
   environmental conditions. Some variables of the environment are
   temperature, voltage, and minimum/maximum component parameters at a
   given clock frequency.  Exceeding the worst-case design envelope can
   cause unpredictable results.  For example, to avoid problems caused by
   a defective main clock oscillator that may be running too fast, the
   diagnostics measure the speed of the CPU cycle clock to determine if
   it is within the accepted tolerance. If the cycle is faster than the
   design margin dictates, an error is reported.


   7  Design Tools
 
   The design of the CPU mother board uniquely merged components from
   several designs. The success of this approach relied on the use of
   design tools to perform the merge and to verify the correctness of the
   merge.

   The normal design process is to create a set of design schematics and
   to verify these through simulation. Once the design is logically
   verified, the layout process begins. The layout process includes the
   use of the SPICE simulator to give direction to the physical layout
   structure and to check the integrity of the layout.[11] After the
   layout is complete, the database is fed back into logic simulation,
   which again verifies the correctness of the design database.

   The CPU mother board designers took a different approach. Since the
   physical placement of the connector portion of the module was the same
   as for the MicroVAX 3100 Model 80 module, this design element was used
   as the starting point for the overall design. The database was edited
   using the VAX layout system (VLS), and the only components saved were
   those that were to be used in the new CPU module. This procedure
   provided the correct placement for all I/O connectors that exited the
   system enclosure.

   In addition, the VAX 4000 Model 500 CPU core was used as the basis for
   the CPU mother board etch layout. The Model 500 design has proven to
   have very good signal integrity due to its well-thought-out circuit
   board layout.  To leverage Model 500 work in the layout of the CPU
   mother board, the designers extracted the printed circuit board signal
   routing from the Model 500. This signal routing included the CPU core
   and cache treeing, the most critical areas. This approach eliminated
   the need to model critical signal interconnect in the design and
   guaranteed that the signal integrity and connector layout would be
   identical to that of the proven Model 500.

   Database comparison tools were used to guarantee that the schematics
   matched the physical layout database. As a final step, the physical
   layout database netlist was used to create a simulation model. DECSIM,
   Digital's simulation tool, was used to verify the final correctness of
   the design database.


   8  Performance
  
   The CPU I/O subsystems on both the MicroVAX 3100 Model 90 and the VAX
   4000 Model 100 provide exceptional performance. The DSSI bus on the
   KA52 CPU was tested under the VMS operating system performing
   single-block (512-byte) read operations from RF35 disk drives. The
   read rate was measured at more than 1,200 I/Os per second. The SCSI
   adapter on both CPUs was measured at more than 500 I/Os per second for
   single-block reads.

   The Ethernet subsystem used on both the KA50 and KA52 modules is very
   efficient and has been measured transmitting 64-byte packets at a rate
   of 14,789 packets per second. The measured receive rate for 64-byte
   packets was 14,785 packets per second.

   The performance of the CPU subsystem has traditionally been measured
   using a suite of 99 benchmarks.[12] The results are scaled against the
   performance of the VAX-11/780 processor, and the geometric mean is
   taken.  This calculation yields the VAX unit of performance (VUP)
   rating. The processor VUP rating for both the KA50 and KA52 CPUs is 24
   VUPs-more than twice the performance of the MicroVAX 3100 Model 80.
   Table 1 presents a summary of the performance results for the VAX 4000
   Model 100 and the MicroVAX 3100 Model 90 systems.

   The performance of the system in multistream and transaction-oriented
   environments was measured with TPC Benchmark A.[14] This benchmark,
   which simulates a banking system, generally indicates performance in
   environments characterized by concurrent CPU and I/O activity and in
   which more than one program is active at any given time. The
   performance metric is transactions per second (TPS). The measured
   performance of the VAX 4000 Model 100 is 50 TPS tpsA-local; that of
   the MicroVAX 3100 Model 90 is 34 TPS tpsA- local. The difference in
   performance between the VAX 4000 Model 100 and 10 the MicroVAX 3100
   Model 90 is a result of their different disk subsystems, i.e., the
   DSSI and SCSI adapter support.


   9  Acknowledgements

   The authors would like to thank all the designers of other products
   whose logic components were used in the VAX 4000 Model 100 and
   MicroVAX 3100 Model 90 designs, namely, the VAXstation 4000 Model 90,
   VAX 4000 Model 500, and MicroVAX 3100 Model 80 teams. The authors
   would also like to acknowledge the many engineers who helped design
   and qualify the VAX 4000 Model 100 and MicroVAX 3100 Model 90 systems
   on a very aggressive schedule. Special thanks to Harold Cullison and
   Judy Gold (diagnostics and console), Matt Benson and Joe Ervin (module
   design and debug), Cheryl Preston (signal integrity), Dave Rouille
   (design verification), Colin Brench (EMC consultant), Larry Mazzone
   (mechanical design), Billy Cassidy and Walt Supinski (PWB layout), and
   Rita Bureau (schematics).


   10  References and Note

   1. G. Uhler et al., "The NVAX and NVAX+ High-performance VAX
      Microprocessors," Digital Technical Journal, vol. 4, no. 3 (Summer 1992,
      this issue): 11-23.
   
   2. MicroVAX 3100 Models 40 and 80 Technical Information Manual, rev. 1
      (Maynard, MA: Digital Equipment Corporation, Order No. EK-A0525-TD,
      1991).

   3. KA680 CPU Module Technical Manual, (Maynard, MA: Digital Equipment
      Corporation, Order No. EK-KA680-TM-001, 1992).

   4. B. Maskas, "Development of the CVAX Q22-bus Interface Chip," Digital
      Technical Journal, vol. 1, no. 7 (August 1988): 129-138.

   5. J. Murray, R. Hetherington, and R. Salett, "VAX Instructions That
      Illustrate the Architectural Features of the VAX 9000 CPU," Digital
      Technical Journal, vol. 2, no. 4 (Fall 1990): 25-42.

   6. Jon Crowell et al., "Design of the VAX 4000 Model 400, 500, and 600
      Systems," Digital Technical Journal, vol. 4, no. 3 (Summer 1992, this
      issue): 60-72.

   7. P. Rubinfeld et al., "The CVAX CPU, a CMOS VAX Microprocessor Chip,"
      ICCD Proceedings, (October 1987): 148-152.

   8. G. Lidington, "Overview of the MicroVAX 3500/3600 Processor Module,"
      Digital Technical Journal, vol. 1, no. 7 (August 1988): 79-86.
  
   9. M. Callander, Sr., L. Carlson, A. Ladd, and M. Norcross, "The VAXstation
      4000 Model 90," Digital Technical Journal, vol. 4, no. 3 (Summer 1992,
      this issue): 82-91.

   10.NCR Microelectronics Products Division, NCR 53C94, 53C95, 53C96 Advanced
      Controller Data Sheet (Santa Clara, CA: NCR Corporation, 1990).

   11.SPICE is a general-purpose circuit simulator program developed by
      Lawrence Nagel and Ellis Cohen of the Department of Electrical
      Engineering and Computer Sciences, University of California at Berkeley.

   12.VAX Systems Performance Summary (Maynard, MA: Digital Equipment
      Corporation, Order No. EE-C0376-46, 1991).

   13.SPEC: A New Perspective on Comparing System Performance, rev. 10
      (Maynard, MA: Digital Equipment Corporation, Order No. EE-EA379-46,
      1990).

   14.Transaction Processing Performance Council, TPC Benchmark A Standard
      Specification (Menlo Park, CA: Waterside Associates, November 1989).


   11  Biographies

   Jonathan C. Crowell An engineering manager in the Entry Systems
   Business Group, Jon Crowell was the project leader and system engineer
   on the VAX 4000 Models 100, 400, 500, and 600 and the MicroVAX 3800,
   3900, and 3100 Model 90 systems. He is now working on the design of
   the next generation of VAX 4000 systems. Previously, Jon worked in the
   Systems Integration Group qualifying Q-bus devices and DSSI adapters
   and storage devices. He joined Digital in 1986. Jon received a
   B.S.E.E. (1981) and an M.S.E.E. (1986) from Northeastern University.
   He hold six patents and is an active member of IEEE.

   David W. Maruska Principal engineer David Maruska is a member of the
   Entry Systems Business Group and is presently involved in the design
   of the next generation of VAX 4000 CPUs. He was the lead designer for
   the KA50 and KA52 CPUs and project leader for the VAX 4000 Model 200
   system, the KZQSA Q-bus- to-SCSI adapter, and the Futurebus+
   exerciser. Dave joined Digital in 1982, after receiving a B.S. in
   computer engineering from Boston University.  He worked on graphics
   workstations for Mosaic Technologies and Raster Technologies from 1983
   to 1985 and then returned to Digital in 1986.


   12  Trademarks

   The following are trademarks of Digital Equipment Corporation:
   Digital, KA50, KA52, MicroVAX, MS44, Q-bus, Q22-bus, ThinWire, VAX,
   VAX 4000, VAX 9000, VAX-11/780, VAXcluster, VAXstation, and VMS.

   SPEC, SPECfp, SPECint, and SPECmark are registered trademarks of the
   Standard Performance Evaluation Cooperative.
  
   SPICE is a trademark of the University of California at Berkeley.

   TPC Benchmark and tpsA-local are trademarks of the Transaction
   Processing Performance Council.


                                  ===*===

   Copyright 1992 Digital Equipment Corporation.  Forwarding and copying
   of this article is permitted for personal and educational purposes
   without fee provided that Digital Equipment Corporation's copyright is
   retained with the article and that the content is not modified. This
   article is not to be distributed for commercial advantage. Abstracting
   with credit of Digital Equipment Corporation's authorship is
   permitted.  All rights reserved.

                                  ===*===

*============================================================================*
   
   (6) MicroVAX-3xxx/VAXstation-3xxx specifics (other than 3100..)

------------------------------------------------------------------------------
   
   (6a) What is a VAXstation 3520 exactly?

   From: iviecc.usu.edu (Roger Ivie)
   Newsgroups: comp.sys.dec
   Subject: Re: VAXstation 3520 info?
   Date: 14 Jan 96 18:13:29 MDT
   Organization: Utah State University
   Message-ID:
   References:

   In article , ericgoonsquad.spies.com (Eric Smith) writes:
   > I just bought a VAXstation 3520.  I'm not sure if I got a good deal or
   > not, but I didn't pay too much.
   >
   > Can anyone tell me the general specs?  Which generation of VAX CPU
   > does it use?  Are there newer plug-compatible VAX CPU cards I could
   > put in to upgrade it?
   
   The VAXstation 3520 is a dual-CPU CVAX-based workstation. The 3540 had
   four CPUs. The system uses a proprietary bus called Mbus, which on
   paper can run 26MB/s, but in reality doesn't ever come close. The Mbus
   is a write-back cache bus; each agent in the system has a cache and
   can intercept memory transactions for which it owns the data,
   supplying the data instead of the memory. The difficulty with this is
   that it takes time to knock the local processor of the internal
   pin-bus so you can fetch the data from its cache, so accessing data
   that is in a cache is lots slower than accessing data in main memory.
   The cache also doesn't have an invalid state, so once something gets
   in a cache it can be difficult to get it back out.

   The system has a three-board graphics engine with its own dedicated
   MicroVAX II.

   You can get a QBus adapter for it. There are two variants: the FTAM,
   which supports only a TK70 controller, and the FQAM, which supports a
   wider range of Qbus peripherals. The FTAM is built around the CQBIC
   chip which, combining its scatter/gather mechanism with the real-world
   timing of the Mbus, can require up to 20 microseconds to complete a
   Qbus transaction; the TK70 controller is supported because it has a
   particularly long timeout. The FQAM does really seriously evil things
   to guarantee it can meet standard Qbus timings, but is a) slow and b)
   makes certain absolutely nothing else is happening on the system when
   the Qbus is active.  --
   -------------------------+---------------------------------------------
   Roger Ivie | "They say that heaven is like TV.  iviecc.usu.edu | A
   perfect little world that doesn't really http://cc.usu.edu/~ivie/ |
   need me." -- Laurie Anderson

*============================================================================*
                                      
   (7) VAXstation serial pinouts


   6-pin modified modular jack (MMJ) used for serial ports on the
   VAXstation.  DEC carries four DB-to-MMJ adaptors.  They are internally
   wired as follows

                      Rdy Out  TX+  TX-  RX-  RX+  Rdy In
    Adaptor   Gender     1      2    3    4    5     6       Use with:
   --------------------------------------------------------------------------
    H8575-A     F      20      2    7    7    3    6&8     VTxxx terminal
    H8571-C     M       6      3    7    7    2     20     DEC printer
    H8571-D     M       6      3    7    7    2     20     Modem
    H8571-E     M      20      2    7    7    3    6&8     Female terminal
                                                           or LaserWriter
   --------------------------------------------------------------------------

   RS-232 using DB-25 connectors:
                                                   DTE           DCE
                                                Terminal        Modem
                                               or computer
   Pin Number Signal Name
       2          TD        Transmit Data                   -->
       3          RD        Receive Data
   

==============================================================================

   (8) I've forgotten the SYSTEM password - what can I do?

   Information contributed by:
   James T. Boldway, jboldwaycapecod.net 
   VMS FAQ maintained by Steve Lionell, lionelquark.zko.dec.com

   Here's how to break into a VAX running VMS.  You do have a access to
   the system console and the system itself, physically, don't you?
   You're going to need to reboot the system.  Depending upon the system
   cabinet, you might also need a key; the same key used with almost any
   VAX, or PDP-11, such as an 11/44, or a PDP-8, should do.  You'll need
   this physical access in order to get in.  This is your own VAX that
   you're planning on breaking into, isn't it?

   Here's what you need to do:

   1. Without the system password, there's no point in performing an
      orderly system shutdown if your system is still running.

   2.  Halt the system by pressing the halt button or typing ^P 
       on the console of some models.

   3.  Boot into the SYSBOOT prompt.  The syntax for this varies by
       system - it typically involves a flag of 1, for example:
 
          B/1   <--------- This should worked for a MicroVAX II
          B/R5:1
          b -flags 0,1  <----- This should work with recent Alpha systems


       Note: the above would have the boot device appended to them; for
       example:

          B/1 DUA0:

       If your system has a hardware password, which some VAXstations have,
       you will need to know the password and enter it using the LOGIN
       command at the console.  If you get an "Inv cmd" error while trying 
       to boot with a flag of 1, and can't LOGIN using the hardware password, 
       you're going to need to know how to resest the hardware password, or
       call in a DEC repairman to do it for you.

       Does anyone reading this know how to change the hardware password?
       Are there any jumpers which need to be shorted to allow one to
       this?  Does a new EEPROM need to be burned?  What does one need to
       do in order to change this hadware password?  If you know, please
       send me e-mail and I'll include it in the next version of this
       FAQ.  

   4.  At the SYSBOOT> prompt, enter :

         SET/STARTUP OPA0:
         SET WRITESYSPARAMS 0
         C

   5.  Wait for the $ prompt.  The system will now be accepting startup
       commands form the console.  Enter the following:
 
	 SPAWN
         SYS$SYSTEM:STARTUP

       This causes the system to complete the startup, but it leaves you
       logged in.  The SPAWN is necessary, as, without it, you'll be logged
       out when the startup finishes.

   6.  Enter the following:

         SET DEFAULT SYS$SYSTEM:  ! or wherever SYSUAF.DAT resides
         RUN SYS$SYSTEM:AUTHORIZE
         MODIFY SYSTEM /PASSWORD=newpassword
	 EXIT

       This changes the SYSTEM password to a new value.

   7.  Enter the following:

          SYS$SYSTEM:SHUTDOWN

       The system will now shut down.

       Reboot the system normally - the SYSTEM password should now be 
       set as you specified in step 7.

       Some people will suggest a method using the UAFALTERNATE SYSGEN
       parameter.  This isn't recommended, as it is not reliable.

==============================================================================

   (9) How can I modify my copy of VMS for more users? [R.D.D.]

   DISCLAIMER: This information is provided only for educational
   purposes.  It may be illegal to actually modify your version
   of VMS.  Of course, it's not illegal to know how to do it. :-)

   Order the booklet "Secrets of License Management", by Mark Hittinger,
   from:

                Proflix, Inc.
                P.O. Box 43358
                Middletown, Kentucky 40243

                Telephone: (502) 244-0455
 
******************************************************************************
   
   Disclaimer: This FAQ and its contents are not connected with any 
   way with either Digital Equipment Corporation, University of Liverpool, 
   or Virginia Commonwealth University, Medical College of Virginia Campus,
   or any other organization mentioned in this FAQ.  
  
   While the maintainers of this FAQ believe the information in it to be
   correct, the reader is responsible for verifying the accuracy of any 
   information contained in this FAQ before relying upon it.  The maintainers
   of this FAQ assume no responsibility for any errors or omissions, or
   anything else in this FAQ.

******************************************************************************



-- 
R. D. Davis  *  Tel: +1 410 744-4900 (work) *  http://www.access.digex.net/~rdd
===============================================================================
   Computer preservationist - many types of unwanted older computer systems 
   disassembled, removed (mostly locally), and preserved.