|
HP OpenVMS Systemsask the wizard |
|
The Question is: I've got a uVAX 3500 here with me that just plain and simply refuses to work. It detects it's disk and floppy controller but neither of the disks or tape on the chains. When I try to netboot it I never see any network traffic coming from it. So question is; can someone think of a quick solution for this or can I get technical manuals for the uVAX 3500 from somewhere? I got this system for free and I'm only an out-of-work hacker so I can't pay the money to have anyone from Digital officially lay their hands on it. Thanks. The Answer is :
The Wizard does not know of particularly many MicroVAX 3500 systems that
have a floppy drive installed. Without specific details of the system
itself and the specifics of the Q-bus configuration, and without specific
details of the bootstrap failure being seen here, it is impossible to
answer this question.
Information on properly determining and setting CSR and interrupt vector
values on Q-bus modules, as well as the serpentine nature of the Q-bus
(which you don't have to worry about in the BA213 box typically used on
the MicroVAX 3500) have been posted to comp.os.vms, and these discussions
are available via the http://www.dejanews.com and INFO-VAX archives.
The Wizard would first recommend reading about the Q-bus configuration
from information in the newsgroup archives and that is referenced at
various MicroVAX sites referenced by the OpenVMS FAQ, and then posting
the above-requested information to comp.os.vms, and requesting assistance
from the denizens of the newsgroup with correcting the configuration.
Some of the related discussions include topics (407), (1866), (3232),
and (5219).
--
Here are a few of the various discussions on this topic retrieved from
the comp.os.vms archives... Various email addresses have been altered
to avoid automated email spam, the information is otherwise unmodified:
In article <r-larkin-ya023680002506981400110001@news.cso.uiuc.edu>, r-larkin*uiuc.edu (Ronald P. Larkin) writes:
: I have looked around at netnews and on the web and failed to find a
:listing of the recommended order of Q-bus modules. Hardware manuals for
:individual devices are kind of coy on the topic--they usually say the
:closer to the CPU the higher the bus priority, but don't recommend where
:to put the device relative to other kinds of devices. I've seen such
:lists printed in DECUS or someplace, but don't remember where.
Devices that are less sensitive to bus delays go further from the
bus master (usually the processor) module, while devices that are
more sensitive must be placed correspondingly closer.
Smarter and "newer" Q-bus controllers tend to be less susceptible
to delays accessing the bus, while dumber and "older" devices tend
to be more sensitive.
Device such as streaming tapes (and their controllers), for instance,
tend to have radically lower transfer rates if they cannot receive
information from the host fast enough. Non-streaming tapes can be
further from the bus master, as they can tend to be more slow-moving,
and more oblivious to bus latency... Disk controllers tend to be
fairly tolerant of latency. (If the disk device driver and host
software is smart enough, it can even resubmit the requests -- this
capability is part of the support associated with mount verification
and with error recovery. Tapes, unlike disks, tend to have the tape
position as an important and assumed part of their basic operations,
unlike the block-addressable disks.)
The exact order of modules is something of a black art. With typical
"recent" Q-bus controllers on typical MicroVAX Q-bus systems, the order
is traditionally network, serial and point-to-point communications,
disks, and tapes, respectively. Though occasionally you will find a
Q-bus widget that starts having problems with bus latencies, indicating
a need to reorder the modules in the Q-bus.
: Also, what does VMS >AUTOCONFIGURE actually do?
AUTOCONFIGURE probes the Q-bus CSR space looking for the CSRs of
device controllers. Depending on which CSR addresses return valid,
a particular device type is assumed and configured. Gaps in the
address space indicate the next sort of controller should be checked
for. See the appendix associated with the SYSGEN documentation for
additional details.
The CSR is the address that the device driver communicates with the
device. CSRs are often read-write, but can have restrictions on which
hardware instructions are used to access the contents of the CSR.
The interrupt vector is the address that the device uses to communicate
with the device driver. Interrupts usually occur in response to something
that has happened out on the device, such as an I/O completion, or an
error. Interrupts often cause the driver to "wake up" and look at the
contents of the CSR.
: My SYSGEN manual does
:not give the procedure for using >CONFIGURE and then >AUTOCONFIGURE to
:set up a set of controllers.
CONFIGURE tells you the CSRs that AUTOCONFIGURE will be looking for,
and it allocates the available interrupt vectors for those devices
in the floating vectors.
You enter the CONFIGURE subsystem, then you specify the secret name of
each and every Q-bus device present. Omit none. When you are done,
CONFIGURE will provide you with a list of CSR and interrupt vector
settings. You then use the device controller manuals to encode the
CSR and (when necessary) interrupt vector settings into each module.
There are interrupt vectors at fixed locations -- these vectors are
always assigned to specific devices, and there exists a pool of interrupt
vectors assigned to any device, the floating vectors. Sometimes the first
controller of a given type will have a fixed interrupt vector, and any
additional matching (or similar) controllers will use vectors allocated
from the floating vectors.
Some modules have soft-loaded interrupt vectors -- the device driver
loads the interrupt vector -- and others have switchpacks that set
the interrupt vector. Do not, under any circumstance, trust what
any SYSGEN display tells you about the current interrupt vector
settings of any Q-bus modules. On any non-soft-loaded device, you
must pull the module and check.
The other thing to be aware of when working with the Q-bus are the
differences in the slots -- Q22/CD vs Q22/Q22 -- and the serpentine
pattern (and you can search with the word serpentine to find previous
discussions) used in a particular enclosure. The BA23 has one pattern,
the BA123 has another, and the BA2xx and BA4xx enclosures. Which box
effects which slots need DMA grant cards, and which slots you can
insert dual-width Q-bus modules into. (Most any Q22/Q22 slot can accept
a quad-width DMA module, but you'll want to be aware of the implications
of using a Q22/CD slots.)
And I won't even get into a discussion of the available slots and the AC
and DC loads...
: I've also looked at a bunch of the Hoffman postings and at my VMS 5.5
:docs. My system hardware manuals are older than most of my peripheral
:devices.
Am I really the only one that is answering Q-bus questions around
here? And why do I suddenly get that "older than dirt" feeling? :-)
-------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoffman@xdelta.ZZenet.dec.com
note to those folks not contributing spam -- there is no ZZ in my address
++
Followups set to vmsnet.sysmgt.
In article <35183633.70A3A0EE@dial.pipex.com>, Gary Gale <gary.g*dial.pipex.com> writes:
:Apologies in advance for the cross-posting - if this enrages anyone
:please bear with me...
:I'm trying to hook a uVAX 3500 onto our LAN - fairly straightforward
:most of the time but it appears that the board isn't getting any power.
:From a physical level, I've checked the connections and everything
:_looks_ fine. From a firmware level, I get no self-test problems when
:booting.
:I've got an Applied Telesis CentreCOM 210T transceiver to convert from
:thick-wire down to 10 Base T but at no time do I even get a power
:indication, likewise on the hub I'm getting no signal at all.
:So - no apparent problems, no diagnostics but no network either. Anyone
:out there care to point me in the direction of an on-line resource I
:could peruse or have any suggestions?
Uh, which Ethernet board? Which operating system? Which system
enclosure (BA23, BA123, or the BA2xx more typical of the MicroVAX
3500 series)? Which slot have you plugged the Ethernet board into?
Do the board and the bulkhead match?
One common older DIGITAL Ethernet board is not IEEE 802.3, and is
not supported on recent OpenVMS versions: the DEQNA. (I would not
expect to see a DEQNA in an S-box BA2xx series enclosure, but I
digress.)
Typical DIGITAL Q-bus Ethernet controllers have only a few different
CSR addresses, sometimes as simple as a primary and a secondary CSR
address setting. One can usually see pretty quickly from the MicroVAX
3500 console if the console "sees" the controller correctly, which means
that the controller is at the correct CSR address.
If you are not seeing power on the transceiver, then I would expect
there is a wiring fault, or there is a controller fault. Even the
older Ethernet boards are only missing "heartbeat" -- they should
power the transceiver if they are functioning. If the Ethernet
board is plugged into a Q-bus slot, then it has power. (Beware
plugging any Q22/Q22 quad controller, and any Q22 dual controller,
into a "CD" slot. Q22/CD quad controllers and Q22 dual controllers
are commonly used in the BA2xx series enclosure.)
You are heading into the art of configuring a Q-bus -- there have
been several previous discussions. Visit www.dejanews.com and look
through the archives for "hoffman serpentine quad dual" and/or a few
other keywords or incantations -- I've posted details before.
-------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoffman*xdelta.ZZenet.dec.com
note to those folks not contributing spam -- there is no ZZ in my address
++
In article <MSGID_1=3A163=2F506.0_33f7f17a@fidonet.org>, Doug_Murray*rdbbs.jammys.net (Doug Murray) writes:
: I have a few questions about the MicroVAX II system.
:1. Does anyone have the list of >>> commands? I know I can Examine and
:Deposit to/from registers, but dont have a clue as to what other commands are
:available at that level.
E, D, B, H, U, and I -- Examine, Deposit, Boot, Halt, Unjam, and Init
-- are all the commands you will likely ever need.
:I have a MicroVAX II system with a DHQ11 controller, but it seems that my
:system does not see any of these ports or controller. the card is located in
:the bottom part of Slot 4.
:I have been told that some of these slots cannot
:be used for certain interfaces.
This depends on the specific enclosure. In the BA23, the first three
slots are for the CPU and memory -- the so-called Q22-CD slots -- while
in the BA123, the first four slots are Q22-CD slots. In the BA2xx and
BA4xx, all slots are Q22-CD. Starting in slot 4 of the BA23 and in
slot 5 of the BA123, the Q22-bus becomes serpentine -- going from the
upper slot to the lower slot, then to the lower slot of the next higher
slot, then to the upper slot, then to the upper slot of the next higher
slot. (Got all that? It's easier to draw it out on paper.) The BA2xx
and BA4xx do not have a serpentine pattern.
What does this mean? It means you have to insert dual Q22 cards in the
appropriate slot, and that you may or may not need a bus grant card when
a dual and a quad Q22 module are adjacent. You can place a dual-width
card in the upper-portion of a Q22-CD slot. You cannot place a dual-width
card in the lower-portion of a Q22-CD slot. And you can place CPU and
memory cards only in a Q22-CD slot, not in a Q22-Q22 slot.
A full-width module is called a `quad' -- four sets of contact `fingers',
while a half-width module is called a `dual' -- two sets of `fingers'.
:Would anyone know where this card should be
:located? I attempted to AUTOCONFIGURE the system but still the ports or
:controller do not show up.
This usually means one or more CSRs are mis-set. Use the SYSGEN
CONFIGURE command -- specify *all* Q22-bus cards present in the
system -- to determine the correct settings for the CSR(s) and
interrupt vector(s) for each module(s) in the system. Then check
*all* modules -- adding or removing a module can cause a series
of cascading CSR and/or interrupt vector changes throughout the
entire Q22-bus.
:Additionally, if someone has technical documentation on the MicroVAX II
:system, I would gladly workout some arrangement to get a copy. Its not
:obvious on how to set the CSR's and Vectors.
The CSR and vector documentation is included with the documentation
for each module. It is not in the MicroVAX KA630 CPU documentation.
The CPU technical documentation is the EK-KA630-UG KA630 CPU module
user's guide.
-------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering h*ffman*xdelta.enet.dec.c*m
headers and addresses munged to avoid automated spammers: junk-e-mail
++
In article <40qmoi$l1q@explorer.csc.com>, rmsmith*csc.com (Robert Smith)
writes:
:I may be suffering from Oldtimers (keep forgetting whether I
:read something on this or not disease) but can some kind person
:please explain to me the meaning of Q-22 C/D?
:I think it means Q bus, 22 bit addressing, and C/D slots are wired
:for DMA (or NPR in the days of the unibus).
:For example - the microvax backplanes are listed as Q22 with the first N
:slots C/D. On a BA123 box I believe this is the first four slots.
BA23: 3, BA123: 4, BA2xx & BA4xx: all.
:Now I think this means that the cpu goes in one, the mem in the next two,
:and I don't think I really know what goes in slot 4....
:Is the BA23 backplane the same?
:thanks in advance for any help in getting this thru my thick skull!
The Q22 is commonly used as an I/O bus, and the CD interconnect has
various uses but is most commonly used as part of a CPU-to-memory
interconnection. As any owner of the MicroVAX I may directly or
indirectly realize, the Q22 bus does have memory space in addition
to I/O space, but the memory space is limited to a 4MB address space.
The CD interconnect (with the over-the-top ribbon cables) allows
access to rather more memory -- it's part of the memory subsystem
on some MicroVAX and VAX 4000 processors.
The DMA circuitry is part of the Q22 bus, and the CD interconnect is
quite seperate from the Q22 DMA request and grant processing.
One can place a dual-width Q22 card in a Q22/CD slot, but one cannot
place a quad-width Q22 card into a Q22/CD. (One can sometimes get
around this -- don't try this one at home folks, this is a professional
hardware hacker's trick and it can trash the board if not done right
and it can void service contracts and warrantees -- by cutting the Q22
DMA etch that would otherwise have been installed in the CD slot.)
If no card is installed in an intermediate Q22 slot, one must insert
a Q22 DMA grant card -- `holes' in the Q22 bus are bad news and can
cause bus hangs and other errant behaviour -- into the Q22 slot. And
the mistaken insertion of a Q22 grant card into a CD slot has the
potential to cause problems. There is no CD grant card. (Much to
the relief of ASCAP. :-)
In the BA23, the first three slots are Q22/CD, and subsequent slots
are serpentine Q22.
BA2xx, BA4xx series:
6 5 4 3 2 1
<-Q22 <-Q22 <-Q22 <-Q22 <-Q22 <-Q22
<-CD <-CD <-CD <-CD <-CD <-CD
BA23 series:
6 5 4 3 2 1
Q22 <-Q22 Q22 <-Q22 <-Q22 <-Q22
| A |
V | V
<-Q22 Q22 <-Q22 CD <-CD <-CD
BA23 series:
6 5 4 3 2 1
<-Q22 Q22 <-Q22 <-Q22 <-Q22 <-Q22
A |
| V
Q22 <-Q22 CD <-CD <-CD <-CD
------------------------------ Opinionative -------------------------------
Stephen Hoffman OpenVMS Engineering h*ffman@xdelta.enet.dec.com
---------------------------------------------------------------------------
++
In article <61617n$oij$1@java.imsa.edu>, Beverly Thurber <tsunami*imsa.edu> writes:
:i've recently picked up a microvax ii. it's a rackmount system that
:has some sort of hard drive (5 1/4" full height) and a tape drive.
:i plugged it in with a null-modem cable going to my laptop and turned it
:on, but nothing came up on my laptop's screen. the led on the back of
:the vax is flashing, alternating between 9 and f. any suggestions on
:how to make it work?
The DB9 pinout on the MicroVAX II predates the PC DB9 pinout, and
is based on an older standard -- the folks that designed the PC
invented a new pinout, which has become the new standard. For
adapter and pinout details, as well as a wealth of other answers
and URLs, please see ftp://ftp.digital.com/pub/Digital/dec-faq/vms,
this is the OpenVMS Frequently Asked Questions (FAQ).
Without knowing the Q-bus hardware configuration, it's hard to say
exactly what is wrong here -- the self-test has obviously failed.
The Q-bus design uses a "cascading" assignment of addresses -- the
control and status register (CSR) and interrupt vector settings --
and this means that the system is sensitive to the settings of each
of the modules present in the Q-bus. This comes into play when
Q-bus modules are added or removed. Also of interest is the
Q-bus backplane wiring -- in enclosures from the MicroVAX II
vintage, the Q-bus wiring is "serpentine":
BA23:
Q <- Q Q <- Q <- Q <- Q
| ^ |
V | V
<- Q Q <- Q CD <-CD <-CD
BA123:
Q <- Q Q <- Q <- Q <- Q <- Q
| ^ |
V | V
<- Q Q <- Q CD <-CD <-CD <-CD
The MicroVAX II Q-bus is normally wired right to left or top-to-bottom,
with the CPU in the topmost or rightmost slot, and the memory module(s)
in immediately adjacent slots. The KA630 MicroVAX II supports up to
two 8 MB memory modules, and a total of 16 MB of memory. The typical
disks were the RD53 and the 159 MB RD54. The typical tape drive is
the TK50 DLT drive.
A dual Q-bus card (two sets of connector fingers -- half the width
of the MicroVAX II Q-bus enclosure) must reside in a Q-bus slot. A
quad-width module -- the full width of the MicroVAX II Q-bus enclosure
-- can reside in a Q-Q or a Q-CD module. Q-bus dual modules can not
be placed in a CD slot. In general, the CPU and memory modules should
be plugged into a CD slot. (Do not plug a Q-bus module into a CD slot.
Q-bus enclosures after the BA123 and BA23 use entirely Q-CD slots, and
the modules for these enclosures are intended to be used in Q-CD slots.)
The Q-bus cards generally have a code number -- the letter M and then
(usually) four digits -- stamped or etched on them somewhere, usually
on the module's spine. The KA630 MicroVAX II CPU module is the "M7606",
for instance. If you tell us which modules are present and in which
slots, and which slots are empty, and if you can tell us which MicroVAX
II enclosure -- the "space heater" BA23 or the "coffee table" BA123 --
we can start to help you.
The FAQ has URL pointers to websites with more MicroVAX information.
-------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering h*ffman@xdelta.enet.dec.c*m
headers and addresses munged to avoid automated spammers: junk-e-mail
++
In article <3tvhl6$11f@sloth.swcp.com>, phdewi*swcp.com (Phillip Williams)
writes:
:Hello
:On one of my uVAXIIs when ever I try to set a term ie
:set term txa0:/device=vt200/speed=9600/nomodem/perm
:it comes back with error setting txa0: device timed out
:I have switched out the dhv11 but no luck.
:any thoughts.
:phillip
NOTE: I would recommend all hardware service be refered to a qualified
service technician -- one can cause physical, electro-static or other
damage or destruction to the hardware and surroundings, and one can
potentially damage or destroy one's self if not trained and familiar
with working inside the enclosure. Dangerous voltages and electro-
static-sensitive components are present inside the enclosure.
--
My guess is that the CSR and vector settings are incorrect on one or
more modules residing in the Q-bus. You will have to use SYSGEN
CONFIG command to determine what the correct settings are, and then
you must remove each module and check (and reset if necessary) the
switchpacks that encode the CSR and (when it is not softloaded) the
interrupt vector. DO NOT ASSUME THAT ANY SYSGEN COMMANDS CAN DISPLAY
THE ACTUAL INTERRUPT VECTOR SETTINGS -- THEY DO NOT. The only reliable
way to determine that the CSRs and the interrupt vectors are set
correctly is to decode the settings off the Q-bus modules.
When one swaps modules into or out of a Q-bus, one *must* re-evaluate
the CSR and interrupt vector settings of *all* modules residing in the
Q-bus. (Unlike many more modern busses, the Q-bus requires manually
configured settings, and the insertion or removal of an I/O module can
and often does have a cascading serioes of settings changes on the
remaining modules in the Q-bus. And folks new to working in the Q-bus
often neglect to specify _all_ modules present in the Q-bus; this will
usually lead to a non-functional or mis-functional system. DO NOT
FOCUS ON ONE Q-BUS MODULE -- EVALUATE ALL SETTINGS ON ALL MODULES.)
In addition to the CSR and interrupt vector, one also needs to take
the serpentine path of the Q22 portion of the Q-bus within various
enclosures (the pattern varies depending on the particular Q-bus
backplane used), and one must account for the slots in the Q-bus
backplane that have the CD (memory) interconnect in addition to the
Q22 interconnect. (The Q22/CD slot pattern also varies depending
on the particular Q-bus backplane used.) EMPTY Q-22 SLOTS WILL
CAUSE PROBLEMS WITH SUBSEQUENT Q-22 MODULES. INSERTION OF Q-22
MODULES INTO CD SLOTS CAN INTRODUCE OTHER, INTERESTING, PROBLEMS.
Alternatively, the DHV11 could be dead.
Again. refer service to a qualified technician...
------------------------------ Opinionative -------------------------------
Stephen Hoffman OpenVMS Engineering h*ffman@xdelta.enet.dec.com
---------------------------------------------------------------------------
In article <0095000015704357000002L072*@MHS>, JOHN MALMBERG <LNUSSAT.JMALMBER*eds.com> writes:
:Hoff writes:
:> It is possible to use a Q22/Q22 board in a Q22/CD slot, but I generally
:> prefer to sever the DMA grant etch -- this will prevent any sort of odd
:> positioning-dependent problems relative to any CD-cogniscent modules in
:> the enclosure. (Most folks don't deal with CD-cogniscent modules.) When
:> moving a Q22/CD board to a Q22/Q22 slot, one must check for, and add in
:> if necessary, the DMA grant etch.
:Useful information to know for keeping the home World Box System with it's
:Q22/Q22 running with what ever I can scrounge :-)
Be aware of the differences in the serpentine pattern in the BA23,
BA123, and BA2xx/BA4xx series. (If you search the archives of the
group for "Q-bus" and "serpentine", you'll likely find a few of the
previous answers I've posted on this particular subtopic.)
:Good Q-Bus information can be hard to find now for some of us.
Most early technical manuals for Q-bus systems have an appendix on the
Q-bus, giving the wiring, timing, etc. This information was available
seperately, as well. (The VAXstation II owner's manual is one of the
manuals that has a Q-bus appendix.)
Also visit INFO-VAX and www.dejanews.com -- I've answered a number of
Q-bus questions over the years, and the archives are searchable.
:Since the CXA16/CXB16/CXY08 only seem to be supported for the BA213, BA215, and
:BA440 backplanes, all of which are only Q22/CD slots, I would assume that they
:are Q22/CD boards, not a Q22/Q22 boards, but nothing in my copy of the
:documentation to confirm or deny my assumption.
You will have a better chance with boards that have a detachable bulkhead.
If the S-box bulkhead (BA2xx/BA4xx) is attached to the module, the module
will not fit in the BA23 nor BA123. Also note that S-box modules are
allowed to use slightly more clearance due to the larger seperation in
the S-box -- modules were closer together in the BA23 and BA123. If you
are swapping modules, check the clearance carefully before "jamming" a
module into one of the backplanes with narrower seperations...)
The DHV- and DZV-series controllers were rather more common in the older
BA23/BA123 enclosures.
And the KA630, KA650, and KA655 all use the same BA23/BA123 bulkhead,
and the same BA2xx bulkhead -- the modules can be used in either the
BA23/BA123 or the BA2xx series enclosures. (The KA640 doesn't fit in
the BA23/BA123 due to mechanical and RFI limits, and it uses a bulkhead
that differs from the KA630, KA650, and KA655.)
Radio Frequency Interference (RFI) requirements can (and do) limit which
Q-bus modules can be used in particular enclosures.
:In looking this up, I have also found that several but not all of the quad
:height boards have switch packs for exactly the purpose that you mentioned.
In addition to switchpacks, some Q22/Q22 boards will have a zero-ohm
resistor, rather than etch. This makes cutting the grant easier...
:I would still caution such modifications to only be made by experienced
:persons who assume all risk.
Ayup, one of the two ends of a soldering iron can be quite hot. :-)
And if you are not trained and experienced in working inside a system
enclosure with static-senstive components and with the potential (no
pun intended) for contact with dangerous power levels, don't do it.
If the documented maintenance procedures are not followed, damage or
death to human and/or to hardware could result.
-------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoffman@xdelta.ZZenet.dec.com
note to those folks not contributing spam -- there is no ZZ in my address
|