Dear Antonio,
   
   Thanks again for further enlightenment. But I still have some questions.
   In my previous posting I have said that VAXstations appear to be closer
to VAXservers than to MicroVAXen and asked why is it so. Instead of an
answer to the latter question, I have got a reminder that "when going from
one "family" to another, things may not remain consistent". Believe me, I
have learned that quite well by now. I guess that I haven't stated my
question very clearly, so I'll give it another try. First look at KA650-
based Q-bus systems. KA650 has two versions that differ only in one bit in
the EPROM. One is used in MicroVAXen and one was used in VAXservers. _For
some reason_ KA650-based VAXstations use the version used by VAXservers and
NOT the one used by MicroVAXen, as if VAXstations are closer to VAXservers
than to MicroVAXen. The "_for some reason_" part above is what I'm trying
to get an answer to. Now look at CVAX-based BabyVAXen and see the same
pattern. KA41 has two versions that differ only in one bit in the EPROM.
One is used in MicroVAXen and one was used in VAXservers. Now "bookmark"
the location of that bit in the KA41 EPROM and look at the same location in
the _KA42_ EPROM. I'm sure that you'll find the value that on KA41
signifies a VAXserver (that's why VMS considers a KA42 with a serial
console to be a VAXserver 3100). The same question as for KA650: why? What
is it that makes KA42-B be closer to KA41-E than to KA41-D? Please don't
tell me that KA41-D and KA41-E differ only in one bit in the EPROM and that
KA42 is quite different. Believe me, I have learned that by now. This
question is more ideological than technical in its nature. From the purely
technical viewpoint this is a non-issue. I have learned by now that in all
systems in general the differences between MicroVAXen, VAXservers, and
VAXstations from the technical viewpoint are: (1) MicroVAXen and VAXservers
have identical hardware except the ID bits and (2) VAXstations differ from
others in that they have the video present (or enabled if it's always
present), and are otherwise either identical or very similar. As far as the
technical stuff goes, that's it. My question, on the other hand, is
ideological. Why does DEC give VAXstations the ID bit of VAXservers and not
of MicroVAXen? There HAS to be some reason, since DEC is very consistent in
doing this. And this question has absolutely nothing to do with what the
various MicroVAX, VAXserver, and VAXstation system boards look like.
Moreover, it isn't even tied to any particular models, it applies to _ANY_
VAX that has all three versions. 3500s and 3100s are just special cases.
   You wrote:
> I don't know what you mean by "mainstream" but I expect that Digital sold
> more MicroVAX 3100s than VAXserver 3100s.
   Correct me if I'm wrong, but I think that in the strictest sense the
term "MicroVAX" means a VAX whose central processing unit is implemented in
a single integrated circuit. Whenever one wants to refer to such a VAX
without taking into account things like the console type and the licensing
status, he/she says "MicroVAX", even if it's actually a VAXstation or a
VAXserver. _This_ is exactly what I mean that MicroVAXen are the most
mainstream of the three. When I first learned about the existence of three
different versions, I didn't see any connection between VAXstations and
VAXservers. To me they seemed to be two different and independent side
branches from the MicroVAX mainstream. The only property special to
VAXservers seems to be their licensing status. As far as I understand, the
ID bit in the EPROM is there only to inform the OS of this status. Since
(also as far as I understand) VAXstations don't have the same licensing
status as VAXservers, I thought that they shouldn't have the ID bit setting
that's supposed to uniquely identify the VAXservers. However, both 3100s
and 3500s clearly indicate that they do, and therefore something is wrong
in my understanding. _This_ is what I'm asking you to clarify.
   I wrote:
> What IS the difference between "a workstation" and "a microvax"? People
> were suggesting to me that it's licensing.
   You responded:
> Correct (or you could call it marketing instead.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   But the licensing of DEC proprietary OSes is involved here too. As
Gunnar has pointed out, the different versions require different VMS
licenses, and VMS does enforce this.
   I wrote about the magic jumper on the KA410:
> > The jumper is not there for licencing purposes.
> > It is there so the console knows whether it is supposed to behave as a
>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > workstation or as a microvax; the fact that the OS gets to know is
>   ^^^^^^^^^^^
> > incidental.
> Now we are getting to the heart of the matter. What IS the difference
> between "a workstation" and "a microvax"? People were suggesting to me
> that it's licensing. You are saying that it isn't. It isn't the console,
> is it? The console is determined by pins 8 and 9 on the DB9 and not by
> the jumper (there are a lot of people who change the console without even
> knowing about the jumper). WHAT IS IT then?
   You responded:
> Don't confuse anything that happens on a MicroVAX 2000 with anything that
> happens on a MicroVAX 3100 or VAXstation 3100 or anywhere else. These
> things are not consistent.
   I have thought that I have made it clear that I'm talking specifically
about KA410 (MV2000 and VS2000 in DEC marketing terms). Would you like
giving this question another shot in the light of this?
   Actually, I seem to do better at writing essays than the people who
respond to my questions (my As in both semesters of freshman English are
probably quite fair). Therefore, it would probably be better if I replace
essay questions with true/false or multiple-choice ones. I have finally
arrived at a plausible theory. I'm stating it in the next paragraph, and I
would appreciate it if you could tell me whether it's correct or not. Here
it is:
   As far as I can understand from Gunnar's posting, the VAXstation VMS
license is higher than the VAXserver one, and the MicroVAX one is even
higher (the highest). If I understand it correctly, a VAXserver node is
intended to serve other nodes and not be logged into directly. Therefore,
it allows at most one user to log in directly, which is necessary for
maintenance. If this is correct, it's understandable why the VAXserver
license is the lowest. Now imagine a VAX model that has all three versions,
like 3100 or 3500. If you have a VAXstation, you can always convert it to a
MicroVAX/VAXserver. On a 3500, you would remove the VCB02. On a 3100, you
would flip the console switch up. (Yes, I know that it's not a full
conversion, but the software can't tell. A MicroVAX/VAXserver made out of
KA42 will actually be a little better than a real KA41, since KA42 has the
64 KB external cache.) The question is, is it going to be a MicroVAX or a
VAXserver? If DEC chose it to be a MicroVAX, one would be able to change a
VAXstation to a higher license class simply by flipping a documented
external switch. No good for DEC. That's why they have made it a VAXserver.
Now if you flip the switch on VS3100 or pull the VCB02 out on VS3500,
you'll only lower your license class, and that's OK with DEC.
   The 2000, on the other hand, doesn't have a VAXserver version.
Therefore, a converted VAXstation 2000 has to be a MicroVAX 2000, which
means that the conversion raises the license class. If the license class
decision were made only on the basis of the console selection, attaching a
BCC08 cable to the DB9 connector (which, I assume, is what all NetBSD users
do on VS2000s) would increase the license class of the machine. No good for
DEC. Therefore, they have made it a little more difficult by introducing an
obscure jumper on the system board just for this purpose. Now if you want
to increase your license class (perhaps even without changing the console),
you first have to find out about this jumper, and then you have to
disassemble the system unit all the way down to the system board to change
it. This sounds very plausible, and I would like to know if it's actually
correct. (BTW, I have an idea as to why Antonio seems to try to avoid
answering this question. Probably as a DEC employee he is not allowed to
talk about issues that sound like cheating on VMS licensing.) I also have
an idea as to why in my experiment one of my VS2000 identified itself as
"KA410-A". I'm pretty sure that back when this machine was new, it was
running as some kind of a server. It's possible that the guy in charge of
it knew about the licensing jumper and has changed it for a not-very-honest
purpose. I don't know which jumper it is (have to wait for the technical
manual, which probably documents it, since if you are going to replace a
broken system board with a new one, you have to know how to set the jumper
depending on whether you are doing it on a MicroVAX or a VAXstation), and I
don't feel like disassembling the box anyway, so I can't verify this now,
but this seems very plausible.
   You wrote:
> On the MicroVAX 2000/VAXstation 2000 you cannot use both serial console
> and a workstation because of physical constraints: you have to either use
> a video connector or plug in the MMJ-converter-pack to get serial lines.
   Not completely true. The 3-MMJ wee box is one way to short pins 8 and 9
on the DB9, but not the only way. You can also connect a BCC08 cable, which
shorts pin 8 and 9 on the DB9 end, to the DB9 connector on the KA410. I
have seen zillions of people do this, using both genuine and home-made
BCC08 cables. I have also done that myself when I was conducting the
experiment that I have described in my previous posting. This way, you can
connect the serial console to the DB9 with a BCC08 cable and connect the
monitor, keyboard, and mouse to the DB15. You boot with the serial console
and then run an application that uses the video.
   You wrote:
> On a MicroVAX II you add a few extra boards (VCB01 or VCB02) and the
> console will notice and use them and you have a workstation. Playing with
> the DB9 console connection has no effect [...]
   You still haven't explained why all MicroVAX IIs that I have seen have
their consoles connected with BCC08s, the cables that short pins 8 and 9,
and I believe that these are the official MicroVAX II console cables.
   You wrote:
> [...] in fact in a BA213 chassis has no DB9 it has
> MMJ instead and yet the behaviour is the same as in BA23 or BA123.
   In this case there is no external DB9, but there IS the internal
connector on the CPU board itself that was simply connected to the DB9 in
BA23/BA123. In BA213 it's connected to the small PCB on the back of the CPU
cover, and that thing may short pins 8 and 9.
   I'm not discussing the presence or absence of the base mono video on
KA42 and KA41, since things are pretty clear here (KA42 has it and KA41
doesn't).
   You wrote:
> As far as a hypothetical KA410 goes, it could have been designed without
> video circuitry. I don't know how the hardware is arranged but if I
> remember (and if noone else posts it first) I'll look in the tech manual
> tonight.
   Please do so. Actually, KA410 without the base mono video may not be so
hypothetical after all. If you read the description of the experiment in my
previous posting, you'll see that I have an MV2000 that doesn't want to
work with the graphical console. For the details see my previous posting.
But the system board doesn't show signs of omitted components, so the video
hardware may still be there. Actually I can bet that it's there, since the
monitor was synching properly (see my previous posting). It's probably the
system ROM that doesn't support the video in this case. This would mean
that MV2000s did come with a different ROM after all, at least the later
ones (this one is pretty new, V2.3).
   You wrote:
> I suspect that the GPX and SPX addon boards require the base mono video
> circuitry which the KA42/KA43 have.
   I strongly doubt this. In Jim Agnew's MicroVAX FAQ there is an article
about a guy who used both video subsystems simultaneously by connecting two
monitors with a special home-made cable. He had two monitors connected to
his VAX, and the two worked independently. This worked equally well with
2000s and 3100s, using the same cable. The guy has even got this to work
with VMS! This is actually not surprising if you look at the pinout of the
DB15. Mono video uses pins 3 and 9, while GPX uses pins 1, 2, 10, and 11.
I'm pretty sure that the former two are connected to the base video
circuitry and the latter four are connected to some pins on the option
connector. In this case the GPX option can put out its signals on these
pins without affecting or relying on anything else in the system, including
the base mono video. This is probably the case, since there isn't much to
borrow from the base mono video anyway. There is the frame buffer, but the
GPX option must have its own since it must be much larger. There is the
refresh circuitry, but I can't see how can it be shared if both the output
signals and the frame buffer are different. I don't know much about the SPX
board, but if it can be plugged into systems that predate it (I think it
can), then it has to work in the same way as the GPX one.
   You wrote:
> I don't remember whether the VAXstation 2000
> uses the same GPX board as the VAXstation 3100s.
   It does.
   You wrote:
> However, if you added a GPX to your hypothetical KA410-without-mono-video
> then it would probably not work.
   Since KA410-without-mono-video turns out to be not so hypothetical after
all, this is testable. I just don't have time for it now.
   You wrote:
> You can mechanically insert the GPX/SPX boards into a KA41 but although
> it has the same connectors as a KA42 they are connected to different
> circuitry: in this case they are for the asynch/synch comms board
> options.
   You have to be careful with the word "circuitry". The option connector
has two functional parts. The first is pretty much the bus. We normally say
that BabyVAXen are busless. This is true in the sense that they don't have
a generic I/O bus, but they do have an internal bus which allows for
certain devices but is far from generic. In this case the internal bus
happens to be pinned out on the option connector. Since it's just the bus,
it doesn't care whether it's used for video or communication options. The
other functional part consists of the pins that are connected to pins 1, 2,
10, and 11 on the DB15. It's easy to see that the bus part is the same on
all systems in question. It has to be the same on VS2000 and MV2000 because
they use the same system board. It has to be the same on VS2000 and VS3100
because they use the same video options. It has to be the same on MV2000
and MV3100 because they use the same communication options. This completes
the system of equations. The video signal part has to be the same on KA410
and KA42 for them to use the same video options, and on KA41 the video
signal pins are probably not connected to anything. This means that if you
stick a GPX or SPX board in a KA41 system it should appear to work. It will
be visible to the CPU, and it will generate the video signals internally.
The only problem is that there is no way to get these signals to the
monitor, since there is no place to hook it up!
   You wrote:
> The VAXstation 3100-30 and 3100-38 use that motherboard but the
> VAXstation 3100-76 does not ... it has a strange internal cable that
> carries the internal SCSI bus around the system box and carries the
> external SCSI bus to the external 68-pin connector.
   Thanks for pointing this out to me!
   You wrote:
> I have not seen the insides of a DECstation 3100 recently enough to
> remember what happens in that box.
   I think you are right in that the controllers are on the system board as
in KA43. If KN01 used the same daughterboard design as KA42, additional
complications will arise. Explaining this requires a little detour. Since I
was planning to take it up eventually anyway, please allow me to use this
convenient excuse.
   The BabyVAX architecture begins with MicroVAX 2000 and VAXstation 2000.
These systems were apparently intended for the same marketing space as
MicroVAX II and VAXstation II (smaller ones, not 630QE with two RA81s).
Both use the MicroVAX II processor chip. Both use RDxx disks, RXxx
floppies, and TK50 tapes. However, their architecture is completely
different. The obvious difference is that the IIs are Q-bus and the 2000s
are single-board. However, the differences don't end here. If you examine a
Q-bus system, you'll see a slave processor (usually Z80) and one or more
EPROM chips on almost every Q-bus card. On KA410 there are no slave
processors and all of the work is done by the CPU. In general, these
classical VAXen are design the relieve the CPU of as much work as possible.
The software interfaces of UNIBUS and Q-bus devices are usually very high-
level, like MSCP and TMSCP, and DMA-based. However, every feature has a
price. In this case, literally. Apparently the goal for BabyVAXen was to
make something that looks just like MicroVAX II for the user while cutting
down on the expensive intelligent controllers. And so a completely new
architecture was designed from scratch. The same RDxx disks are used, but
their software interface doesn't even resemble MSCP. The same TK50 tapes
are used, but their software interface doesn't even resemble TMSCP.
   Normally when the hardware architecture undergoes a drastic change a
large portion of the OS has to be rewritten from scratch. Dunno about
Ultrix, but in VMS this was done in a very peculiar way. One thing that was
confusing me for a long time is the choice of device names in the KA410
version of VMB and the corresponding VMS drivers. On KA410 the MFM disks
are called DUAn and the TK50 is called MUA0, making me incorrectly believe
that they are MSCP and TMSCP for a long time. However, this is certainly
not the case. On KA410 the MFM controller has a cylinder/head/sector-level
interface, which is a far cry from MSCP. NetBSD handles it in the expected
way: it uses a special driver, hdc/rd, for this purpose. It does not try to
pretend that these disks are MSCP, but instead handles them in their own
non-MSCP manner, just like MASSBUS disks on VAX-11/780, VAX-11/750, and VAX
8600. VMS and VMB, on the other hand, choose to call them DUAn, which means
drive n on the first _MSCP_ controller. Furthermore, although I don't know
anything about VMS, it seems to me that it really does treat these disks as
MSCP. Apparently, for marketing or other reasons DEC wanted a II and a 2000
to be able to use the same RD54, call it the same name, and make it work
the same. The last part is important, since I think that in VAXclusters VMS
ascribes some special meaning to MSCP disks that doesn't apply to other
disks. It seems like VMS has drivers for different types of MSCP, like
UNIBUS/Q-bus MSCP and BI MSCP, and then there are higher layers like
clustering support. In this light it seems like the MFM disks on KA410 are
supported by yet another "MSCP" driver that internally does in software
what RQDXn does in hardware (firmware actually): converts from logical
blocks to cylinders, heads, and sectors. As a result, VMS and VMB can lie
that the RDxx disks are MSCP without the user suspecting anything. I
wonder, how does Ultrix behave in this regard? Does it also lie that these
disks are MSCP by using the ra driver, or does it use a special non-MSCP
driver like NetBSD?
   The story is more interesting with TK50, TK50Z, and SCSI. I'm sure that
you are aware of the fact that the SCSI hardware on KA410 is fully generic
and no different from that of KA41 or KA42's daughterboard, except that
there is only one SCSI bus. And sure enough, NetBSD supports fully generic
SCSI on KA410 by using the exact same driver as on KA41, KA42, and KA43.
DEC, however, chose to do otherwise. DEC supports only one type of device
on KA410's SCSI bus: TK50Z-Fx (note the "F", TK50Z-Gz is a normal SCSI tape
drive no different from TZ30, Exabyte EXB-8200, or anything else). I'm
pretty sure that this device has a normal electrical interface, but it's
command set is probably completely different from standard SCSI and is
something like TMSCP over SCSI. On the first glance it seems an overkill to
include a SCSI bus that won't do anything except interfacing to one tape
drive. It seems that DEC could have done the same thing they did with MFM:
strip off the intelligent controller, give CPU access to the physical
controller that used to be accessible only to Q-bus card's slave processor
and its firmware, and connect the TK50 drive by extending its 26-pin
interface over an external cable to the system unit. On a closer look,
however, the approach chosen by DEC makes more sense. If they were to
follow the hypothetical approach, they would have to rip the design of
TUK50/TQK50 into two parts, the intelligent controller and the underlying
physical controller, and include only the latter in the BabyVAX design. I
don't know the design of TUK50/TQK50, so I can't say for sure, but this
might be difficult. They would also have to write a driver that looks like
TMSCP to higher OS layers but talks directly to the physical controller,
just like they did with MFM. This may also be difficult. With TMSCP over
SCSI, however, there should be less work to do. The driver for TMSCP over
SCSI may be quite similar to the one for TMSCP over UNIBUS/Q-bus. The
adapter board that sits between the SCSI bus and the TK50 can be made
really similar to TUK50 and TQK50, except that it's for the SCSI bus rather
than UNIBUS or Q-bus. Note that TZK50, the adapter board's name, sounds
really close to TUK50 and TQK50.
   And so DEC chose to use this design. KA410's system ROM has the code for
TMSCP over SCSI or whatever that is instead of standard SCSI disks and
tapes, both in the diagnostics and in VMB. KA410 support code in VMS
doesn't reveal the existence of SCSI to the higher layers but only lies
about the virtual MSCP and TMSCP. (BTW, how does Ultrix treat the SCSI
controller on KA410? Does it also support only TK50Z-Fx? Does it present
this drive as tms0 or as something else to higher layers?) This went on
until KA42/41 appeared on the horizon. By then DEC had realized that one
can connect more devices to the SCSI bus than just one TK50, and
implemented support for generic SCSI disks and tapes. There is no lying
about MSCP any more: SCSI disks are called "DK" instead of "DU" and SCSI
tapes are called "MK" instead of "MU". Since having both the generic SCSI
code and TMSCP over SCSI would be very cumbersome (and the two may very
well be mutually exclusive), the code for TMSCP over SCSI was laid to rest,
and TK50Z was converted to a standard SCSI tape drive by changing the
firmware EPROM on TZK50. This sounds like MSCP and TMSCP have been finally
laid to rest. This is true on KA41 and KA43, but not always on KA42. This
baby uses a daughterboard with the mass storage controllers, and there is a
version of this daughterboard with an MFM controller which is just like the
one on KA410. The hardware is unchanged, and the MFM subsystem doesn't
interfere with the SCSI subsystem, so DEC was able to keep the MSCP lying
code for the former while using new SCSI drivers for the latter.
   As a result, on a typical VS3100 M30 almost all devices would be SCSI
and the RX23 would feel very lonely being the only pseudo-MSCP device.
Returning to the original issue of KN01 (DS3100/2100), the problem is that
if it used the same daughterboard design as KA42, it would have to support
the MFM controller. In general it seems to me that MIPSen don't like MSCP
that much. Well, DECsystem 5400 is Q-bus, and probably it has to cope with
MSCP controllers, MSCP is not the preferred interface for MIPSen.
Therefore. the PMAX designers probably weren't very anxious about porting
the make-MFM-look-like-SCSI code to Ultrix/pmax. Putting two NCR 5380 chips
on the system board and not providing for an MFM controller would be an
easy way to dodge the MFM issue for PMAX.
   Regarding the SCSI-1 connector, thanks for clarifying the Centronics vs.
Amphenol issue!
   You wrote:
> Teammate vs Teammate II means nothing other than perhaps TeammateII was a
> follow-on to Teammate i.e. something to fill the same marketing space.
   This is exactly what I have meant in my previous posting. BTW, there was
one question there that you have apparently overlooked:
> By the way, do you remember that in the SHOW DEV output that Thordur has
> once posted the host adapter's SCSI ID was 7 and not 6 on both SCSI
> buses? 7 is the standard in SCSI in general, but both KA42 (VS3100) and
> KN01 (DS2100/3100) use 6 (at least by default, I don't know if it's
> changeable). Is this yet another difference between KA41 and KA42?
   Do you have any idea as what's going on here? And what is the host
adapter's SCSI ID determined by in the first place? Is it the way the
circuits are laid out on the board (some pins on the 5380 tied high or low)
or does the system ROM give the 5380 a command during initialization to set
this ID?
   You wrote:
> VAXstation 3100-30: CVAX chip @ 90ns, 64KB external cache
> VAXstation 3100-38: CVAX chip @ 60ns, 64KB external cache
> VAXstation 3100-76: Rigel chip @ 28ns, 128KB external cache
> MicroVAX 3100-10:   CVAX chip @ 90ns, unknown external cache
> MicroVAX 3100-10e:  CVAX chip @ 60ns, unknown external cache
> MicroVAX 3500/3600: CVAX chip @ 90ns, 64KB external cache
> MicroVAX 3800/3900: CVAX chip @ 60ns, 64KB external cache
> MicroVAX 3300/3400: CVAX chip @ 100ns, unknown external cache
   In this case the "unknown" external cache is very likely to be none. 90
ns bus cycle corresponds to 22 MHz clocking (apparently there are two
clocks per cycle), and 60 ns corresponds to 33 MHz. 100 ns corresponds to
20 MHz. Actually I have thought that KA640 clocks at the same rate as
KA650. You are saying that it's slower. One more reason to stay away from
KA640.
   You wrote:
> VAXstation 4000 boxes are different (at least the VLC and VAXstation
> 4000-60 are, I haven't seen a VAXstation 4000-90).
   Then how can the same Nemonix board swap into both MV3100 M30+ and
VS4000? Maybe the boxes are different but compatible, sort of like BA23 vs.
BA123?
   You wrote:
> The SCSI interface is on board, but the SCSI connector is on the box and
> is connected to via a ribbon cable.
   I'm not arguing here, since I have never seen any of the machines in
question and the picture in the Nemonix ad is too poor.
   The following line from my previous posting:
> And I'm still curious about the KA630 and KA650 console thing.
   still stands. You still haven't explained why all MicroVAX IIs that I
have seen have their consoles connected with BCC08s, the cables that short
pins 8 and 9, and I believe that these are the official MicroVAX II console
cables.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu