Dear Allison,
   
   You wrote:
> Ok, here goes.  The only difference between the 3100m76 and the vs2000
> scsi is 0/zip/nada/zero!
   and
> Don't forget, SCSI is the bus level
> protocal and what's said over the bus can be anything in the way of
> higher protocal just like eithernet.
   Note that I am writing "standard SCSI", rather than just SCSI. I called
a SCSI device standard if and only if it uses the Common Command Set (CCS),
which is a standard. As for the electrical interface, you are right, it's
absolutely the same everywhere. I think that even the original SASI and
standard SCSI have the same electrical interface. However, the SASI command
set and CCS are certainly different and, IIRC, incompatible.
   When I was writing about SCSI drivers in different OSes and ROMs in my
previous posting, I was referring to the code for different device types,
not to the code for writing to 5380's registers.
   You wrote:
> Now what your talking about is CONSOLE ROM support... and that is whole
> different can of worms.
   First of all, the term "console ROM" is not entirely correct. Although
MicroVAXen don't have a separate console processor, it seems to me that
MicroVAX CPUs do have a notion of console mode. It is clearly stated in
technical manuals for all Q-bus MicroVAXen that the ROM on Q-bus MicroVAX
CPUs consist of two distinct parts: the console code and the VMB. The
console code is what has some kind of special property, something that
distinquishes it from any other code that the MicroVAX can execute. My
guess is that when it executes the CPU chip is in some special console
mode. VMB is the ROM boot code. Unlike the console code, it has NO special
properties, and it is no different from the OS or any other code. If
MicroVAX CPUs do have some console mode, this mode is OFF when VMB is
executing. At least on Q-bus CPUs, it works as follows. When the machine is
sitting at the ">>>" the console code is executing and apparently the CPU
is in some kind of console mode. Upon receiving the BOOT command, the
console code copies VMB from ROM to RAM, takes the CPU out of the console
mode, if any, and transfers control to the RAM copy of VMB. That's why it
is not considered to be a part of the console code. The whole thing with
VMB included is called the system ROM, the CPU firmware, etc., but not the
console ROM.
   Regarding the SCSI device support code in VMS/VMB on KA410 and other
systems, they are COMPLETELY different. This is explained properly in 4
relevant paragraphs of my lengthy posting. Since apparently many of you
were unable to find these paragraphs in there, I'm enclosing them at the
end of this posting. Basically, KA42/41 (VS3100 M30/38/40/48 and MV3100
M10/10e/20/20e), KA43 (VS3100 M76), and all other systems are designed for
standard SCSI devices (disks and tapes with CCS). Standard SCSI disks are
called DKAn and standard SCSI tapes are called MKAn. Note that these names
are different from DUAn and MUAn (MSCP and TMSCP). There is no attempt to
present standard SCSI devices as MSCP devices. The DEC-approved version of
TK50 for such systems is TK50Z-Gx.
   With KA410 (MV2000 and VS2000) the story is completely different. You
wrote:
> The VS2000 does have console rom support for
> tk50 via scsi adaptor, but only that.
   This is right. What we disagree on is what version of TK50. The only
official word from DEC that I currently have on this is the VS2000 customer
doc kit. Unfortunately, it is of no help to resolving our dispute, since it
just says "TK50". However, I know from several sources that the DEC-
approved version of TK50 for KA410 is TK50Z-Fx. Unlike TK50Z-Gx, which has
two external connectors like all standard external SCSI devices, TK50Z-Fx
has only one external connector and terminates the SCSI bus internally. (I
see three sockets on my TZK50 board that look like those for resistor
networks.) TK50Z-Gx has external switches for setting the SCSI ID, while
TK50Z-Fx certainly doesn't. Either it's internally jumpered to SCSI ID 1
(this is what the TEST 50 configuration display suggests), or the concept
of SCSI ID is completely foreign to it (remember, it was intended to be the
only device on the SCSI bus except the host adapter).
   But the most peculiar thing is how this version of TK50 is treated by
VMS and VMB. Lo and behold, it appears as MUA0! Yes, MUA0, unit 0 on the
first _TMSCP_ controller. How can it possibly be a standard SCSI tape
device (i.e., one that uses CCS and will work with everything from a KA42
to an IBM PC AT with Adaptec 1520A) if it uses this naming? In this naming
there isn't even a place for the SCSI ID! "0" is definitely not it, since
it can't be at SCSI ID 0 (that's where KA410 puts the host adapter!). If
you ever used a TK50 on a Q-bus or UNIBUS system, you would have a
different feeling for this digit "0" in "MUA0". As you probably know (I
hope), TQK50/TUK50 supports only one TK50 unit. Therefore, the unit number
(the number after "MUA") is essentially fixed. Normally it's 0, but at
least on TQK50 it's jumperable. Thus on these Q-bus and UNIBUS systems VMS
and VMB look only at the "MUA" part, identify the TQK50/TUK50, and pass the
number to the card, which checks it itself. It is plausible that the same
happens on KA410, i.e., the TK50Z will see the request no matter whether
it's for MUA0, MUA1, or whatever (whether it will accept it is another
matter). In this case it becomes clear as a day that the SCSI ID is either
hard-coded in the KA410 MUAn driver or is ignored by TK50Z-Fx (that's what
I have meant earlier by the concept of SCSI ID being completely foreign to
it).
   You wrote:
> I've booted via TK50.
   Maybe it was a TK50Z-Fx? Or maybe you were loading the boot program over
the net and then telling it to read the kernel from the tape? This would
certainly work, since the standalone boot program's SCSI code is CCS. If
you really claim that you were able to boot from the ">>>" prompt from the
same TK50Z-Gx on both KA410 and KA43, could you answer the following two
questions for each case? 1. What was the SCSI ID of the TK50Z? 2. What
exact command were you typing at the ">>>" prompt?
   You wrote:
> <reverse-engineer its system ROM (or have a friendly UFO pilot fly right
> <into former DEC's archives and steal the sources for you) and
> <significant
>
> At one time I had access to it [...]
   If you can still get to it somehow, you can instantly gain the ability
to boot from standard SCSI disks and tapes (not just TK50) on KA410 by
giving me a copy.
   You are refuting my statements on KA410 system ROM's limitations by
saying that SCSI was too new at the time of KA410. But this doesn't make
our lives easier. Also strictly speaking the real reason for the system ROM
not supporting SCSI disk booting and formatting is that according to DEC
you are not supposed to connect a SCSI disk at all. The reason that you are
giving may be a reason for THAT, but no more.
   Your suggestion about the ROM size is wrong. KA42 and KA41 have normal
SCSI (CCS) code and their ROMs are 256 KB, just like on KA410.
   You wrote:
> I can't format MFM drive from my MVII
> (KA630) console either and must use MDM for that.  Same difference
   No, it isn't the same difference. Q-bus CPUs never have things like MFM
disk formatting in their ROMs, since Q-bus systems are freely configurable.
Why should KA630 give a preference to MFM disks over, say, RA81s? And how
is it going to tell whether it's an MFM disk or an RA81 in the first place?
Telling this difference requires digging below the MSCP abstraction layer,
and that is a very bad thing to do for something as generic as a Q-bus CPU.
On BabyVAXen, on the other hand, everything is on the system board (or at
least on a proprietary daughterboard that's tied tightly to the system
board). Therefore, the diagnostics can be be built into the ROM. Also the
architecture of BabyVAXen is so different from the software viewpoint from
that of classical VAXen that the ordinary MDM won't work at all. DEC had to
either write a completely different MDM (from scratch, since the
architecture changes are too great to leverage even a single line of code
from the existing MDM), or build all diagnostics into the ROM, even the
Field Service ones. They chose the latter. It may actually have been easier
for them to write, and it also makes life much easier for Field Service
troubleshooting workstations without diskette or tape drives. In this light
not supporting SCSI disk formatting in KA410's ROM means not that it was
left out for simplicity, but that this task was not intended to be doable
at all. Remember, DEC doesn't want you to connect SCSI disks to KA410s.
   You wrote:
> <   3. The system ROM's inclination toward TK50Z-Fx may very well
> <interfer with an OS'es desire to support standard SCSI devices.
>
> Can't imagine how.
   Read the words immediately following the ones you have quoted! There I
have mentioned two possible problems: assignment of SCSI IDs and mutually
intrusive probes.
   You wrote:
> It's not used like a PC rom bios!
   Actually the similarity with IBM ROM BIOS is pretty good in this case.
The MicroVAX CPU system ROM can be called only with the memory management
off. Similarly, IBM ROM BIOS can be called only in a standard real-mode
environment (or at least an emulated one created via V86 mode).
   You wrote:
> You have never designed hardware and put drivers behind it.
   Although I have never produced a design of my own, I'm proficient in
hardware. I have no trouble with understanding existing designs and reading
schematics and hardware datasheets.
   You wrote:
> I spent some time today with my prom programmer and yes one of them
> contains all 0FFh... fried since it will not program either.
   It's a pity that we'll never know what code did it contain.
   You wrote:
> One of the small benefit of a career in hardware engineering.
   I benefit from my proficiency in hardware a lot too.
   You wrote in a different posting:
> Its the intimate hardware knowledge needed to make drivers work that is
> missing.
   I already have the basic understanding and the necessary skills. The
missing part is the details, and this blank will be filled as soon as I get
the docs from Richard (I guess I'll have to hurry up or Compaq will throw
them away). I'm really serious about revolutionizing the VAX hardware
support. However, I also realize that this involves paramount work, and I
expect some reward for it. The only reward that I want is being able to use
the results of my work myself. Since (no personal prejudices intended here)
I do not consider NetBSD suitable for any serious use, including this work
only in NetBSD won't do me personally any good. I intend this work
primarily for Berkeley UNIX(R) (this doesn't mean that I don't want NetBSD
to use it too). However, I still don't have a copy of it, and I don't feel
like starting any work before I have it. So if you (this is directed to the
whole club) want, you can take the following deal: you give me copies of
4.3BSD-Tahoe and 4.3BSD-Reno (legal or illegal, I don't care), and I give
you all of the following:
   1. Perfect support for BabyBAXen (KA410, KA42/41, and KA43) without the
bugs and limitations of your current code (PIO only, etc.).
   2. Very likely support for later VAX designs based on SOC, Rigel,
Mariah, and NVAX chips (MV3100 M30+ BabyVAXen and VAX 4000 Q-bus systems).
   3. Very likely downloadable and ROMable images of an alternative system
ROM for KA410 with real SCSI support.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu
   
   Enclosure: 4 relevant paragraphs from my lengthy posting:
   
   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.