==================================================================
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.