Dear Emanuel,
   
   You wrote:
> i got this machine as a VAXSTATION 3500.
   Is it in a floorstand BA213 enclosure? Does it have a big front door?
Does this door actually say "VAXstation 3500" on it? Do you know if it
comes directly from DEC or has been tinkered with? So far the only thing I
know about VAXstation 3500 is the following line from Jim Agnew's
_MicroVAX/VAXstation Systems FAQ_:
>  0A | 1 | 65D | 2.8   | Q      | VAXstation 3200, 3500   | Mayfair/GPX
   The processor type of 0A and subtype of 1 indicate the KA650 series of
Q-bus CPUs, and Mayfair is the general nickname for the MicroVAX 3 series,
which is based on these CPUs. In this case "Mayfair/GPX" tells me that it
has GPX-level video. The performance of 2.8 VUPs tells me that the CPU is
clocked at 22 MHz and the 64 KB cache is in place. This is just like the
ordinary KA650. So far so good.
   What's really strange in that line is that it indicates that the
software-accessible CPU ID is "65D". Actually, a lot of my assumptions,
some of which I express on port-vax, are based on these CPU IDs from that
FAQ. So far I have been assuming that they come from the hardware and are
therefore authentic. But now I'm beginning to question that. Although I
plan to learn VAX system programming some day, I don't know it now, so I
cannot find the truth myself. Since that article in the FAQ was written by
a VMSer, it might be the case that these IDs are actually constructed by
VMS based on many different factors and not only on the CPU. I don't know
anything about VMS (and in this case I won't waste a single minute on
learning it), so I can't tell whether this is possible or not. Returning to
the system in question, if this ID (65D) were hard-coded somewhere in the
firmware on the CPU itself, this would mean that the CPU is different from
the ordinary KA650. I was assuming that DEC has incorporated the GPX-level
graphics into the KA650 CPU and called it KA65D.
   This assumption is not without problems. Consider a related case: KA640.
This is KA650 with DSSI and 4 MB of RAM incorporated into it. But whenever
you squeeze something into a standard-sized board that's already packed,
there are problems. Often you have to take something out. In this case
KA640 is slightly slower than KA650 (2.4 VUPs instead of 2.8 VUPs). I have
noticed the exact same performance loss on MV3100 M10/10e/20/20e relative
to the corresponding VS3100 models. I'm assuming (this is just a guess,
really) that in both cases the 64 KB cache was taken out. Now look at this
hypothetical KA65D. GPX graphics requires a lot of circuitry. First it
requires 512 KB of memory for 4 planes or 1 MB for 8 planes. This is
clearly a very high-end VAXstation, so the designers would certainly go for
8 planes, especially if this is going to be cast in stone on the CPU. Plus
this is not a BabyVAX, and whatever module implements the video is also
responsible to providing the keyboard and mouse ports, so these would also
have to be on the CPU. Now we are talking about a lot of circuitry,
probably more than what they have added on KA640. And yet this hypothetical
KA65D CPU performs just like the ordinary KA650! Plus I have never seen DEC
incorporate advanced video into the CPU. I mean, this is just stupid! Of
course, DEC does a lot of extremely stupid things, but this is just too
stupid.
   And so I was puzzled by this line in the FAQ since I have first seen it.
> if you are interrested in the configuration, please look at "console at
> ka650" mail.
   Let's see:
> KA650-BA M7620-BA
   Aha! This is exactly the same CPU that I have taken out of a VAXserver
3600. And that was put in there by DEC, since I know for sure that no one
had messed with that machine in this sense. The manual, which is common to
MicroVAX 3600 and VAXserver 3600, says that the former uses KA650-AA and
the latter uses KA650-BA. This means that you have the same CPU that's used
in VAXservers. And believe me, it doesn't have any video on it!
> MS650-AA M7621-A   << 8mb memory cards???
> MS650-AA M7621-A
> MS650-AA M7621-A
> MS650-AA M7621-A
   These are the very first memory modules for KA650-series CPUs. And yes,
they are 8 MB each. I have two of them, coming from the same machine as the
abovementioned CPU (what a pity that it only had 16 MB...).
> VCB02      M7169-00   << ???
> VCB02       M7168-00
> VCB02      M7168-00
   Aha! Here we go! This is what gives you 8-plane video, as well as
keyboard and mouse ports. M7169 is the main board, and each M7168 is 512 KB
of video RAM. You can have one or two of them, giving you 4 planes and 8
planes, respectively. You have two, so that's 8 planes. This whole thing is
known as VCB02, QDSS, or "dragon board". Now your situation starts becoming
clearer to me.
   Things were very sane on the IIs. The CPU was always the same, KA630-AA
(unless you had the crippled KA630-AB without floating point math). You
could have QVSS (mono) or QDSS (4-plane or 8-plane) video by plugging the
necessary board(s) into the Q-bus. The console was selected in a very sane
way. KA630 has a 10-pin connector on it, and all pins except the last one,
which is unused (the number has to be even), are connected to an I/O
distribution panel insert, which simply outlets them to the outside world
via a DB9. The serial console data lines are there, but there is one more
thing. If pins 8 and 9 are shorted, the serial console is selected,
otherwise, the graphical console is selected if present. I don't know what
will happen if there is no graphics card but the pins are not shorted. The
standard BCC08, which is the official console cable for MicroVAX II, shorts
these pins on the DB9 end, so selecting the console is just a matter of
plugging or unplugging this cable!
   Systems in BA213 enclosures have muddied the water. The I/O distribution
panel is gone, and now there are covers on top of Q-bus cards. I have never
seen a VAXstation in a BA213, only MicroVAXen. The latter use an MMJ cable
instead of BCC08 for the console, and the cover on top of the CPU has an
MMJ on it. Pins 8 and 9 don't exist on the MMJ, so they are shorted
internally by the circuit on the back of the cover. (But not the KA650 CPU
itself! KA650 can replace a KA630 without doing anything to the console: a
MicroVAX II will become a MicroVAX 3, and a VAXstation II will become a
VAXstation 3.) What this internal shorting means is that you cannot select
the graphical console no matter what you do with the console cable. The
only way you can do that is to disconnect the internal cable between the
CPU itself and the cover. The question is, how did DEC make VAXstations in
BA213 enclosures? The trick with disconnecting the internal cable doesn't
seem likely. There probably was a different CPU cover for VAXstations.
   I will be able to say more if you answer the following questions. These
questions apply ONLY to BA213. If your system has a different enclosure,
tell me what it is and I will ask different questions. If your system IS in
a BA213, open the front door. You should see the Q-bus card cage. Normally
you won't see the cards themselves, only their covers. Each cover is held
in place with two quarter-turn fasteners, one at the top and the other at
the bottom. Turn them with a Phillips screwdriver. The rightmost slot is
#1. That's where the CPU sits. On MicroVAXen it's covered with a double-
width cover, which also covers the first memory module. Is this also the
case on your system? These covers also have stickers on them. What does
this one say? What connectors does this cover have on it, and what cables
are connected to them? Remove this cover. Is there a baud rate selector on
the back? What internal cables go to the cover and to the CPU? Repeat this
for the VCB02 boards and their covers. Do the monitor, keyboard, and mouse
connect with one cable to a DB15 like on VS2000? Where does this cable go?
> Anyway, why this machine don't understand most of this monitor
> commands ?
   I don't think that the commands you are trying to use exist on KA650. I
haven't got the docs for KA650 from Richard yet, but I do have the complete
list of console commands for KA630 (from the exceptionally good MicroVAX II
630QB technical manual). This guy has mostly low-level commands like
reading and writing hex bytes at absolute addresses and transferring
control. The only high-level command is BOOT, which starts the VMB. This is
expected for classical VAXen with buses like UNIBUS and Q-bus: the CPU
doesn't and shouldn't know anything other peripheral devices and
controllers, and so it shouldn't mess with them. In busless BabyVAXen
things are bound more tightly, and so the KA410 BabyVAX system board
introduces amenities like MFM disk formatting and ROM diagnostics. I think
that commands like SET and SHOW first appeared in KA41/42 BabyVAX system
boards. Maybe they were back-ported to later Q-bus CPUs like KA650, I don't
know. Will find out everything when the truck with the docs from Richard
pulls up at the door of my office.
> now i have to setup a linux box (or my NetBSD/pmax) , for the mop-boot.
   First I have to inform you that Q-bus MicroVAXen with DEQNA/DELQA cannot
netboot NetBSD because of the lack of standalone drivers in the boot
program (MOP will work and the boot program will load and run, but it won't
be able to load the kernel or anything else). But my second reaction is,
why do you want to netboot in the first place?!?! You have a tape drive!! I
personally find netbooting flawed from the outset. Suppose that you live in
a distant village in the former Soviet Union and your VAX is the only
computer in the radius of two hundred kilometers. What are you going to
netboot from? With a tape drive, on the other hand, you should be able to
buy (for a small fee that's only for the tape, the software should be
totally free) the bootstrap tape from the group that distributes the OS,
boot from it, and run your solitary VAX!
   I also have to inform you that if you intend to run NetBSD on your VAX,
you'll have to part with graphics and switch to the serial console. NetBSD
doesn't support any graphics on QDSS (actually on anything), not even
terminal emulation, so if your VAX runs with the graphical console, it
simply won't work. If you answer my questions about your cabling
configuration, I will be able to tell you how to switch the console.
   On the other hand, you should remember that NetBSD is not the only
operating system for VAXen. There is also Berkeley UNIX(R), which IMHO is
vastly superior. The only problem with it is that people who have copies of
it are not willing to share them. The two releases suitable for this
purpose are 4.3BSD-Tahoe and 4.3BSD-Reno (both must obviously be compiled
for VAX, even the former). These do have working support for QVSS and QDSS
graphics, but I don't know how good it is. I personally would always run
with a serial console on architectures like VAXen and MIPSen that support
this, and only run with a graphical console on architectures like IBM PC
that don't support serial ones.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu