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