Dear Allison,
   
   I guess that I need to clarify a few details. You wrote:
> Funny the one I use works with either(vs2000 or 3100m76) but the firmware
> is 453-E6 on the scsi card.
   I don't have mine handy, so I can't verify the firmware number, but this
is definitely a TK50Z-Gx, since TK50Z-Fx would _NEVER_ work on something
like VS3100 M76 whose SCSI is fully generic. (As I have explained in much
more detail in my lengthy posting, TK50Z-Gx is a standard SCSI tape drive.)
However, you have to be careful with KA410 (MV2000 and VS2000). Unless you
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 significantly
modify it, the phrase "works with KA410" (or your "works with vs2000" for
that matter) can mean two completely different things. Since you write that
your TK50Z-Gx works with your KA410, I can bet that you were testing it by
trying to access it from running NetBSD system. This will surely work,
since NetBSD always uses normal SCSI drivers, no matter what DEC wants you
to think. However, if you were to try to BOOT from your TK50Z-Gx from the
">>>" prompt, or to do anything with it under VMS, you would see a
different story. When running on KA410, VMS does not use any real SCSI
drivers, nor does it even acknowledge the existence of SCSI. (That's why
VMSers would declare in a thundering voice that it's absolutely impossible
to connect a SCSI disk or any other device except TK50Z-Fx to the Amphenol
connector on MV2000 and VS2000.) Instead, it uses some very special driver
that talks to TK50Z-Fx and appears to VMS's higher layers as a TMSCP
device. As I have explained in much more detail in my lengthy posting,
TK50Z-Fx doesn't even resemble a standard SCSI tape drive. It is something
very very special and I conjecture that it does something like TMSCP over
SCSI (see my lengthly posting for more details).
   The fact that VMS doesn't support normal SCSI but only supports fake
TMSCP to TK50Z-Fx doesn't make me cry. One can always throw out VMS and use
a real VAX OS (currently only NetBSD/vax but I hope to help Berkeley
UNIX(R) join the pack). A much more disappointing fact (for me, at least)
is that KA410's system ROM suffers from the same problem. This creates
three serious (IMHO) problems:
   1. You can't format SCSI disks using KA410's diagnostics like you can
with KA42/41's.
   2. You can't boot directly from any standard SCSI devices.
   3. The system ROM's inclination toward TK50Z-Fx may very well interfere
with an OS'es desire to support standard SCSI devices. First, the
KA410/TK50Z-Fx incarnation of the SCSI bus uses a very peculiar assignment
of SCSI IDs. The host adapter is set to ID 0 (!) and the TK50Z-Fx is set to
ID 1. Since this is what the system ROM is written for, it sets the host
adapter's SCSI ID to 0 regardless of whether you want it or not. This means
that you'll probably have to stick to this absurd assignment of IDs even if
your devices are standard SCSI and are accessed only by the OS. Second,
during initialization the system ROM always probes for TK50Z-Fx. Given that
TK50Z-Fx was intended to be the only device on the SCSI bus except the host
adapter, this probe may very well be intrusive and unwelcome to standard
SCSI devices.
   I find these problems so severe that I consider KA410's SCSI controller
unusable unless an alternative system ROM is written for KA410. KA410 and
KA42/41 seems to be very similar from the software viewpoint. As far as I
know, NetBSD uses exactly the same support code for the two. And of course,
the system ROM on KA42/41 puts TK50Z-Fx to rest and uses standard SCSI
code. This makes me dream about taking KA42/41's system ROM and porting it
to KA410. Of course, there are problems. First, which version of KA42 or
KA41 to use as the starting point? If the resulting beast is to support
KA410's MFM controller, the starting system must be something with a
similar controller. There is only one such system: KA42 with a SCSI/MFM
daughterboard. This spells out an early VS3100 M30 with a real RX23 (not
RX23S). Someone will have to provide such as box if people want me to
tackle this project. Second, unlike KA42 KA410 doesn't have the LANCE
Ethernet right on the system board, but has it on a daughterboard with its
own ROM. This means one will have to find the LANCE Ethernet code in the
to-be-adapted ROM and carefully cut it out. Otherwise it will conflict with
the ROM on the daughterboard. Third, unlike KA42 has its SCSI and MFM
controllers right on the system board. This means one will have to
incorporate the code from the daughterboard's ROM into the main ROM. You
may suggest starting with KA41 instead of KA42, but what about the MFM
controller? KA41 never has one, and its ROM has no supporting code for it.
And finally, how would one go about actually doing this? If it turns out
that the code corresponding to each line in the "T 50" configuration
display is a well-separated section of the ROM, the task may be doable
without the sources. Otherwise, the sources will be required. I have a
friendly field servie guy, but the system ROM source is quite different
from discarded hardware or publicly available docs.
   You wrote:
> I missed that and you have my interest as I have another SCSI card that
> appears to not work but it also has different firmware.
   I'm sending you another copy of the posting that you have missed by
private E-mail.
> The firmware is
> marked V4.5 TZK50.
   I will compare both of your firmware numbers with mine when I'm in my
office tomorrow.
> That firmwhere when put in the good card does not
> work on either 3100 or 2000, I suspect it's broken/bad Eprom.
   A bad EPROM is not a very plausible explanation. A much more likely
explanation is that it's a TK50Z-Fx. If this is the case, it should work
with KA410's VMB (the ROM boot code) and VMS. You have probably missed this
fact by testing only under a running NetBSD system :-).
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu