Dear Antonio and Allison,
   
   I finally have the time to continue our wonderful discussion on the
differences between Q-bus MicroVAXen and BabyVAXen, as well as the role of
TK50Z in this matter.
   
   Antonio wrote:
> There is nothing special about the console code itself (except that it
> executes out of ROM at address 0x2xxxxxxx). On most systems the ROM is
> actually double mapped and one of the mappings is in halt-protected space
                                                       ^^^^^^^^^^^^^^^^^^^^
> which means that pressing the halt button won't halt it (so infinite
> loops are a bad idea).
   
   Then probably the special property of the console code that I was
talking about is this halt-protection.
   
> The KA410 disks are controlled by a 9224, the tape by a 5380.
   
   This is saying the same thing that I have said before.
   
> [...] at the time no DEC VAX had SCSI available. I presume that noone
> realised that SCSI would become what it is today so there was no
> intention of making the console significantly different to that of the
> MicroVAX II - DUA0 and MUA0 devices seems quite reasonable in that light.
   
   You are giving reasons, but the facts remain facts regardless of the
reasons. My intention in starting this particular thread was to discuss the
facts about certain aspects of the BabyVAX architecture, rather than DEC's
reasoning for choosing the approach that has been chosen.
   
> The MicroVAX 2000/VAXstation 2000 user manuals warned of terrible
> consequences if you didn't use the correct RD and TK variants with the
> box (specifically do not use the MicroVAX II variants).
   
   One important correction. These manuals give such cautions only for
connector B on the expansion adapter, which is the external ST-506/412
connector. It seems to me that the intent of this caution is to prevent
people from confusing this connector with old Sun SCSI connector. The two
are mechanically the same (3 rows of pins), and since ST-506/412 uses some
differential signals, such wrong connections can easily blow out some
circuits. But in any case these cautions don't say one thing or another
about connector A on the expansion adapter (the SCSI bus in reality and the
connector for TK50Z-Fx according to DEC).
   
   Allison wrote:
> there is SCSI as in the device level and that would be analogous to
> say 802.x
>
> Then there is CCS which is the analogue of say DECnet protocal.  Another
> words the next level up.
   
   This is correct.
   
> The boot code in the VS2k is
> limited to the fact that then the eproms used were smaller than those
> available say a year ot two later.  When it has to fit you slice off
> things you don't need.
   and
> <Your suggestion about the ROM size is wrong. KA42 and KA41 have norma
> <SCSI (CCS) code and their ROMs are 256 KB, just like on KA410.
>
> They aren't 256kb (that would be a 27020 avalable about 8 years later).
> The eproms used are 27512 (64kb) x4 for a total of 64kw(32bit words).
   
   You have misunderstood me. I have meant that the TOTAL ROM size is 256
Kbytes on all three boards (KA410, KA41, and KA42). KA410 has 4 27512 chips
and KA42 has 2 271024 aka 27010 chips. I have never seen a KA41, but it's
probably like KA42. In any case, your assumption that the difference in
functionality is due to the ROM size is incorrect. In general, the system
ROMs of KA410 and KA42 look extremely similar. KA42 introduces console
commands like SET and SHOW, but I don't think that they are that difficult
to implement. Implementing SCSI disk and tape CCS doesn't seem much more
difficult than implementing KA410-style MUA0 fiction either. In general, it
seems to me that there is PLENTY of room in the BabyVAX system ROM, given
that it doesn't do much more than the original IBM PC AT's ROM BIOS, which
uses only 32 KB of the reserved 64 KB window (the other half is used by ROM
BASIC). Yes, there are all kinds of factors like different instruction sets
and word lengths, but the difference is still by a factor of 8.
   
   Regarding TK50Z-Fx vs. TK50Z-Gx:
> The basic board 54-17639-01 is IDENTICAL for both.
   
   Does this number cover only the PCB or does it include the firmware?
   
> You confusing packaging options of the same device.
   
   But I was thinking that the firmware is also different.
   
> <   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
>
> No the vs2k calls it MUA0 and my 3100 calls it mka7 same board.
   
   But what was the SCSI ID in each case?
   
> <number to the card, which checks it itself. It is plausible that the sam
> <happens on KA410, i.e., the TK50Z will see the request no matter whether
>
> Your extrolation is called rubbing the pumkin, kids do that extroplating
> there is a pie inside.
   
   I don't quite see which of my extrapolations you are commenting on. Is
it the one where I say that TK50Z will probably see the request regardless
of whether it's for MUA0, MUA1, etc.? But this is not a rubbing-the-pumpkin
extrapolation at all, and I can show you my chain of reasoning that leads
to this assumption. But let's set this issue aside for now and come back to
it later.
   
> First off I've never booted netbsd via scsi anything.  I may add that my
> adventures with Netbsd have been less than successful.
   
   Oh, I'm not defending NetBSD at all. NetBSD is a hobbyist toy absolutely
unfit for serious use. All people who work on NetBSD/vax consider VAXen a
retrocomputing diversion. How many people here professionally manage
clusters of brand new VAXen operating in full production and competing with
Pentiums and SPARCs while giving shell access to thousands of users?
Imagine just for one second what would happen if one were to give ordinary
users shell access to a NetBSD/vax system. Given that one can usually crash
it with a simple command like ps, the uptime of such a system would rarely
exceed 30 minutes.
   But for me at least, the alternative is not Ultrix or VMS. These systems
are crippled in their own ways. First and foremost, they are commercial.
This property reduces their usefulness to 10% of what it would be
otherwise. This is not because being commercial makes them harder to
obtain. Dumpster diving and piracy are perfect solutions (for me at least).
The real reason is that they are commercial product-oriented. This is
apparent in areas like the installation procedure and the login subsystem.
Finally, there is no source code to correct these or any other problems.
The second problem is the way these systems treat KA410 BabyVAXen (see
below).
   For me the solution is Berkeley UNIX(R). In particular, 4.3BSD-Tahoe and
4.3BSD-Reno. Both are very good, and there is no simple answer as to which
is better. Each has some very good qualities that the other doesn't have. I
hope to create an intermediate system, combining the good qualities from
each. The only problem is that I haven't got either yet. But I definitely
will, no matter what it takes. If I can't get them no matter how hard I
try, I'll reconstruct them by taking a lite release with the AT&T/USL code
removed and then restore that code from some other system that has it. (I
have access to the sources for SunOS 4.something and some system based on
4.3BSD. Both are pre-Reno, so all AT&T/USL code should be there intact.)
The result probably won't match the real Berkeley UNIX(R) release line for
line, so it's still better to get the real one, but a half of the pie is
better than none.
   
> In the year the vs2k was released there was no scsi disk product in dec.
> The "scsi standard" was yet to be fixed in anything close to a solid.
> At that time Ampro was lobbying for the early version of current scsi
> standard.  The implmentation was "what was needed to connect a remoted
> TK50" without the overhead of putting the full TK50 interface on the
> vs2k board.  IE: they needed a non-vax off board bus, at that time they
> had eithernet (too costly to put in a tape), GPIB (good), or SCSI/SASI
> which had been around for a while but still in flux.
   
   This is all correct, and I dare to say that this is the exact same thing
that I am saying, only in different words.
   Regarding the distinction between KAD50, RQDXn, and other MSCP
controllers:
   
> It's done and the OS knows its a RD53 or a RA82 it's hooked up to and
> with what adaptor as well.
   
   That's the MSCP ID. This has been discussed at a great length not too
long ago on port-vax. Basically, it serves no purpose except to let the
user see the name of the disk in the SHOW DEV display. In many cases it can
be absolutely misleading. When formatting a Winchester disk on KA410 I can
set the MSCP ID to anything I want, and if I later stick that disk in a Q-
bus system with an RQDX3, it will report whatever I have put there as the
MSCP ID. Also remember how one guy here had SMD/EMD disks claiming to be
RA81s. These IDs must never be used for formatting or indeed anything other
than identification for the user.
   
> <[...] Remember, DEC doesn't want you to connect SCSI disks to KA410s.
>
> The concept didn't exist at the time.  If it was thought to sell it would
> have been done.
   
   Again, you are giving reasons, but the facts remain facts regardless of
the reasons. My intention in starting this particular thread was to discuss
the facts about certain aspects of the BabyVAX architecture, rather than
DEC's reasoning for choosing the approach that has been chosen.
   
> The ID assingment is not a problem and on the host very changable in
> software.
   
   I guess you can have the OS change it once booted, but you have to agree
that having the host adapter have one SCSI ID when booting and a different
one when running is a horrible kludge. At the very least it keeps both IDs
unavailable for other devices.
   
> Yes, device ID switches/jumpers are read by software and
> translated to a command for the 5380.
   
   What switches/jumpers?! Are you talking about the host side or the TK50Z
side? There are no host adapter SCSI ID switches or jumpers on KA410! It's
not changeable for the console either, at least on KA410 for sure.
   
> the probe is even less a probem.
   
   See below.
   
> The difference is that the PC bios is the base IO for the system.  The
                                                                     ^^^
> roms in most microvax system are not part of nor used by the running OS
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> as it loads it's own fully configured drivers.  The reason is this allows
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> bug fixes and the secondary problem of slow eproms.
   
   i386 Unices do exactly the same thing. OS/2, Windows NT, and Novell
NetWare may do so as well.
   
> the old part was fried.  The new one that works for either vs2k or 3100
> works fine [...]
   
   I have forgotten to tell you that mine is probably the same. It says on
it: "(C) DEC90", "LM9107", and "453E6".
   
> disassembling 32k of z80 code is unappealing though I have
                                                      ^^^^^^
> the tools, skills and experience.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   
   I do too.
   
> <them away). I'm really serious about revolutionizing the VAX hardware
> <support. However, I also realize that this involves paramount work, and
>
> I never considered it a problem but, I know where and how to find data I
> need.  But then I've cultivated that skill over the last 29 years.
   
   I have seen a VAX for the first time in my life in June 1997, but I'm
making amazing progress. Also ten years ago (at the age of 8) I worked on
PDP-11s (actually poorly-compatible Soviet clones, but still).
   
> <floppies, and TK50 tapes. However, their architecture is completely
> <different. The obvious difference is that the IIs are Q-bus and the 2000
>
> The bus or lack thereof is different however, the archetecture is still
> vax.
   
   Whenever I say "architecture" I mean the architecture of the system, not
the CPU. This is much more important than the CPU. NetBSD, for instance,
uses completely different code for supporting classical UNIBUS/Q-bus VAXen
and BabyVAXen, and the two could have easily be treated as different
architectures. On the other hand, BabyVAXen and PMAXen have nearly the same
architecture (the same approach to handling serial lines, the same SCSI
subsystem, the same Ethernet subsystem, etc.), and if the design of UNIX
allowed it (unfortunately it doesn't, see later) they could have been
treated as the same architecture. There are countless other examples.
TURBOchannel is normally for the pmax architecture, but some VAXen can have
it too (VS4000). And vice-versa, DECsystem 5400 is Q-bus. PCI is normally
for i386, but Alphas have it too. VME is used by several architectures with
all kinds of CPUs from Motorola 68K to SPARC. Ideally, UNIX should have a
block of code for each bus, supporting all devices that can be connected to
that bus but not assuming anything about the CPU. The CPU-specific portions
would then only need to glue the different buses together. Unfortunately,
this is still a dream. Even NetBSD with its very multiplatformist ideology
is still far from this. (IIRC, VME has been generalized but all other buses
are still tied to CPU architectures.)
   
> <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
>
> Actually the RQDXn it's a T-11, TQK50 is 80186, DEQNA/DELQA custom logic,
> DHV-11 is 2 8051, the only z80 is on the SCSI adaptor.  Within vax
> systems z80s were rarely used.
   
   OK, I didn't know this. However, when I wrote "usually Z80" I was
looking at more than just TZK50. For instance, Dilog ESDI controllers use
Z80, IIRC. Yes, I know that they are non-DEC, but their design ideology is
no different from that of comparable DEC controllers.
   
> <classical VAXen are design the relieve the CPU of as much work as
> possibl[e]
>
> ...and emulate existing unibus adaptors on the larger vaxen.
   
   Just making sure that you have understood me correctly. The sentence
that you are quoting is about Q-bus MicroVAXen and NOT about BabyVAXen. On
the former the Q-bus does indeed look almost the same as UNIBUS to the
software, and that's why I put them in the Classical VAX category together
with VAX-11/7xx and VAX 86xx. BabyVAXen, on the other hand, are completely
different. They don't have a single controller that's compatible with some
UNIBUS/Q-bus card, and as a result NetBSD/vax doesn't share a single driver
between the two.
   
   In my previous posting on the subject I wrote:
> 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.
   You gave a verbose response which essentially says that this couldn't be
otherwise. Well, was I ever disagreeing? I don't think so. Then I was
writing about the wonderfully misleading choice of device names in VMB and
VMS on KA410. You responded:
> Your looking at the pumkin again and seeing pie.
   followed by a description of the division of labor between the CPU and
the T-11 on Q-bus systems and the absence thereof on BabyVAXen. Well, your
description fully agrees with what I was writing (except that I didn't know
that it's a T-11), so where is the pie that I'm seeing and you are not?
   
> It was a convenience to having a uniform OS with minimal changes.  the
> fact that the end drives are MFM is unimportant and I have a q-bus CMD
> scsi that looks just like a RQDX3 to anyone on the Qbus.  They did that
> so the VMS driver for the RQDX would not know the difference. By making
> device look the same at the driver level you avoid changing the OS and
> restrict your scope of change to a driver(if at all).  It's good sense
> to have a kernal that is uniform and unaffected by a hardware change.
   
   This is completely true as far as the MSCP abstraction on classical
VAXen and MicroVAXen is concerned.
   
> IE: I don't have to recompile VMS to run on a vs2k or a KA630.  As it
> works out since the devices are standardized a bootable RD54 from my
> MV-II also will boot nicely on the VS2k without any changes. this makes
> creating additional disks for my systems that use MFM drives very easy.
   and
> Ultrix for my vs2k on rd54 also will boot in the mv-ii on a
> RQDX3.  You claim the archtecture is different, I can say that when the
> configured media of two DEC OSs can be move between a KA630 and the vS2k
> on a given rd53/54 and work the same it must be similar somehow?
   
   Aha! Now YOU are looking at a pumpkin and seeing a pie. You are seeing
that two DEC OSes, which are well-known to do a great job at obfuscation,
seem to use the same code for the two systems and surmising that they have
similar architectures. I can't tell you much about VMS, but in the case of
Ultrix what you are saying is plain wrong. You are saying that you have an
Ultrix kernel that works on both KA630 and KA410. Great. Now, have you
actually looked at the config file for it? I bet that you haven't,
otherwise you wouldn't be saying such nonsense. Since I haven't laid my
hands on our department's copy yet, and no one has bothered to send me a
copy of the GENERIC kernel config file, the only config file that I have is
the sample provided in "ULTRIX-32 V3.1 / UWS V2.1 Release Notes and
Installation Guide" (AA-ME85B-TE). You may be right in that both KA630 and
KA410 use the same "options VAXxxx" line. The sample that I have is missing
this line, so I can't tell. However, those lines that are present tell me
quite a bit. First observe that the configuration mechanism in Ultrix is
perfectly aware of the unique busless architecture of BabyVAXen. Take a
look at the following lines:
   
> device sm0 at uba0 csr 0x200f0000 flags 0x0f vector smvint
> device sg0 at uba0 csr 0x3c000000 flags 0x0f vector sgaint sgvint
[...]
> device se0 at uba0 csr 0x200e0000 vector seintr
   
   If you have, as you claim, a good knowledge of UNIBUS/Q-bus systems,
these lines should immediately ring a bell in your head. "at uba0"
indicates UNIBUS/Q-bus, right? But how can a UNIBUS or Q-bus device
possibly have any of the above addresses? UNIBUS and Q-bus addresses can be
18-bit or 22-bit, but never 32-bit! It's clear as a day that these are raw
VAX addresses typical of BabyVAXen. This particular config file includes
the line "options VAX420", suggesting that it supports KA42/41 (which DEC's
software division likes to call "420"). These particular lines are clearly
for the mono video, GPX video, and LANCE Ethernet, respectively, on
KA42/41. However, I can bet that these same lines are used for KA410,
simply because these subsystems are identical on the two boards. I will be
able to tell you the exact answer if you send me a copy of the GENERIC
config file or wait until I lay my hands on our department's copy. But
suppose for now that these lines are indeed uses on KA410. This already
indicates that at least some code is different between KA630 and KA410,
since supporting graphics and Ethernet on a Q-bus system requires different
lines:
   
> device qv0 at uba0 csr 0177200 flags 0x0f vector qvkint qvvint
> device qd0 at uba0 csr 0177400 flags 0x0f vector qddint qdaint qdiint
[...]
> device qe0 at uba0 csr 0174440 vector qeintr
   
   These lines are for QVSS, QDSS, and DEQNA/DELQA, respectively. This
should already tell you that you can make a kernel that will run on one
system but not on the other simply by removing one set of lines. It may be
the case that the installation program always keeps both sets, but that's a
completely different and irrelevant story. DEC's own docs say that it's OK
for you to build your own kernels manually and tell you how to do it.
   But let's proceed to the more interesting stuff: disks and tapes. As it
turns out, Ultrix is closer to NetBSD than to Berkeley UNIX(R) in the way
it configures MSCP and TMSCP devices. It does so in three steps. For
example, the first MSCP controller on a UNIBUS or Q-bus would be configured
like this:
   
> controller uda0 at uba?
[...]
> controller uq<n> at uda0 csr 0172150 vector uqintr
[...]
> disk ra<n> at uq0 drive <n>
   
   On the other hand, the first MSCP controller on a BI would be configured
like this:
   
> controller kdb0 at vaxbi? node?
[...]
> controller uq<n> at kdb0 vector uqintr
[...]
> disk ra<n> at uq0 drive <n>
   
   From this you can see three types of drivers: low-level MSCP drivers
like uda and kdb that support various forms of MSCP (U/Q, BI, etc.), the
generic MSCP driver (uq), and the MSCP disk driver (ra). This configuration
clearly doesn't support KA410, so I don't know how would it fit in this
scheme until I have the GENERIC config file. But most probably there is a
driver that sits under uq and talks to the HDC9224. This would clearly be
an example of obfuscation. Although I don't know much about MSCP, I think
that it's a packet-based protocol. In this case it's possible that uq and
ra (the common drivers) generate MSCP packets and drivers like uda and kdb
become much simpler: all they have to do is to send the packets to the
controller. But now think about the implications of this for the HDC9224
driver. In this case uq and ra would waste CPU cycles to generate MSCP
packets only to have the HDC9224 driver waste more cycles to decode them!
It would be many orders of magnitude better to treat HDC9224 disks the same
way UNIBUS RK, UNIBUS RL, MASSBUS RM, and MASSBUS RP disks are treated:
without involving MSCP at all (this is what NetBSD does and what I plan to
do in Berkeley UNIX(R)). You may argue that going through MSCP improves
generality and saves programming effort, but this argument is invalid. One
has to write a very complicated driver that handles disk geometry and bad
block forwarding anyway, and interfacing this driver to uq would probably
be MORE difficult than interfacing it directly to the generic UNIX disk
code (disk labels, filesystems, etc.). One difference would be that these
disks wouldn't be called ra<n>, and would be called something else instead
(NetBSD uses rd<n>). This, as well as examination of the config file, would
reveal to the users that these disks are not MSCP after all, and for
marketing or other equally stupid reasons DEC didn't like this, choosing to
implement an obfuscator instead.
   With tapes the story is exactly the same. Simply substitute "klesiu" for
"uda", "klesib" for "kdb", and "tms" for "ra". (Interestingly, though, uq
stays intact.) It is also probable that there is a driver sitting under uq,
supporting TK50Z and looking like TMSCP to uq. Whether this is the case can
be easily verified by looking at the GENERIC config file. And now an
interesting conclusion. Look at the following line:
   
> controller scsi0 at uba0 csr 0x200c0080 vector szintr
   
   This line supports the first NCR 5380 SCSI controller on KA42/41. Now,
this controller is exactly the same hardware-wise as the one on KA410. This
means that if DEC enabled this line on KA410 your VS2000 would immediately
start supporting generic SCSI disks and tapes just like VS3100! Somehow DEC
blocks this line on KA410, since it's certainly present in the GENERIC
kernel (how would it support KA42/41s otherwise?), but booting this kernel
on a KA410 probably won't give you generic SCSI. You wrote earlier:
   
> <[...] Remember, DEC doesn't want you to connect SCSI disks to KA410s.
>
> The concept didn't exist at the time.  If it was thought to sell it would
> have been done.
   
   But here we see an example to the contrary. Making Ultrix support SCSI
disks on KA410 would be a matter of 5 minutes: simply remove the artificial
blocking! The same is probably true for VMS and VMB. But DEC didn't do it,
instead engaging in _ARTIFICIAL FEATURE BLOCKING_, a kind of high treason
and a crime against humanity for which one must be immediately executed.
   Finally, I'm presenting my theory about TK50Z on KA410. Please comment
on its plausibility, but keep in mind that it's only a theory.
   Consider any reasonably standard SCSI device with a reasonably standard
SCSI command set (CCS or old SASI). There certainly are differences between
CCS and old SASI. There are differences between SCSI disks, tapes, and
other devices. Many devices deviate from the standard a little bit in one
way or another. But still there is one thing that unites them all: the
standard command FORMAT. All commands consist of 6 bytes. The first byte
contains the class and the command code. The remaining bytes differ from
one command to another, but the format is still very similar.
   Now consider the following. It looks like in Ultrix TMSCP packets are
generated by uq and tms drivers, and then they are handed off to the low-
level TMSCP driver. If this driver is klesiu or klesib, it just sends these
packets to the controller. But what if it's the TK50Z driver for KA410?
What does it do? Well, I don't know. But I do have a theory based on the
following hypothetical scenario. Oftentimes when an engineer is trying to
read another engineer's mind in order to guess what thoughts have gone into
the design of something, he may think, "Suppose I were him. How would I
design that thing?" This is the approach that I'm taking. Suppose that I
were a DEC engineer at the time when BabyVAXen were designed. Suppose I
were given the assignment to implement this TK50Z obfuscation, i.e., to
write the driver that would talk to uq and tms on one end and to the 5380
on the other end and the TZK50 firmware to go with it. How would I do this?
My starting materials would be:
   1. The klesiu and klesib drivers that merely send already-prepared TMSCP
packets to the respective controllers.
   2. The firmware for TUK50 and TQK50.
   If it were OK to assume that the TK50Z would always be the only device
on the SCSI bus (as it is according to DEC's official words), I could have
very well come up with the following quick and easy solution: break away
from standard SCSI completely and send _TMSCP packets_ over the SCSI bus.
That's right, there would be no more 6-byte commands, there would be TMSCP
packets instead. With this approach (call it TMSCP over SCSI) the
programming task would be very easy. The low-level TMSCP driver would very
similar to the existing ones: simply send the packets over the SCSI bus
instead of UNIBUS, Q-bus, or BI. The TZK50 firmware would also be easy to
adapt from that for TUK50 or TQK50: simply receive the packets from the
SCSI bus instead of UNIBUS or Q-bus. The alternative approach of making
TK50Z a standard or almost standard SCSI tape drive and using CCS or
almost-CCS would be considerably more difficult. The low-level TMSCP driver
would turn from something trivial into a sophisticated program converting
TMSCP packets to tape CCS commands, and the TZK50 firmware would have to be
written from scratch.
   Which approach has been chosen in reality? I don't know, and this is one
of the things that I'm trying to find out. I'll get a little closer to the
answer if you tell me what SCSI ID was your TK50Z set to when you were
testing it on KA410 and KA43. If the generic SCSI approach is used, it's
obvious why the same drive works with both, but new questions arise. How is
the issue of SCSI ID handled in this case? Why does only TK50Z work and not
other tape drives, even though CCS is the same everywhere? Or maybe any
SCSI tape drive will work? If the TMSCP over SCSI approach is used, the new
firmware probably allows both access methods.
   If the TMSCP over SCSI approach were indeed used, this would have
important consequences. Do you remember me saying that TK50Z may be seeing
the request regardless of n in MUAn? With the TMSCP over SCSI approach this
is very likely. A TMSCP packet contains the unit number, right? With the
approach in question this packet is sent over the SCSI bus, right? Then
TK50Z will have to see the original unit number, no matter what it is, and
decide for itself whether it's valid or not. I hope that now you can see
that this is not "rubbing the pumpkin", but there is some justification to
this theory.
   The second consequence, a much more important one, would be that TMSCP
over SCSI and CCS would probably be mutually exclusive. Think about it,
some packets are being sent over the SCSI bus, but different devices don't
agree on their meaning! KA410 system ROM, VMS, Ultrix, and TK50Z would
interpret them as TMSCP packets, while NetBSD and standard SCSI devices
would interpret them as CCS commands! I don't know the format of TMSCP
packets, but it may be that a sequence of bytes that means something like
"get status" in TMSCP will mean "reformat disk" in CCS! This, in turn,
means that even if you connect only standard SCSI devices to the SCSI bus,
run only NetBSD, run VMS or Ultrix, and boot only from MFM disks or over
the net, the TMSCP over SCSI design of the system ROM will still cause you
grief. Each time you turn on the machine the system ROM will probe for
TK50Z in a TMSCP over SCSI manner, messing up all standard SCSI devices
(all because there probably isn't a concept of SCSI ID in TMSCP over SCSI).
Depending on how lucky you are, your OS may restore the devices back to
normal once booted, but this intrusive probe may still be a major
annoyance. That's why it's so important to create an alternative system ROM
for KA410 if it turns out that the TMSCP over SCSI approach is indeed used.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu