Subject: Re: TK50Z
To: None <port-vax@NetBSD.ORG>
From: Michael Sokolov <sokolov@alpha.CES.CWRU.Edu>
List: port-vax
Date: 02/25/1998 13:48:48
Dear Antonio,
You wrote:
> And in fact the VS2K manual does make it clear that there are
> interactions between the NCR and the disk controller (e.g. they share
> buffers).
I am fully and perfectly aware of this.
> So the uVAX 3100 VMS DK driver cannot be used unmodified [...]
I'm not sure about this. First of all, let's stay away from DEC
marketing names like "uVAX 3100" and refer to the hardware the way it is:
CPUs and system boards. In this case we are talking about KA42/41, which
happens to include VS3100 M30/38/40/48 and MV3100 M10/10e/20/20e, but not
VS3100 M76 or MV3100 M30+. Second, DEC has once made a daughterboard that
when connected to a KA42 would give you a KA42 system with the same mass
storage controller arrangement as on KA410: one SMC HDC9224 and one NCR
5380. On such systems both VMS and Ultrix support both controllers, and the
5380 is supported as a generic SCSI port for disks and tapes. Now, I can
bet that the HDC9224 is supported on this system by the exact same driver
as on KA410. A question for you: does this system (KA42 with a SCSI/MFM
mass storage controller daughterboard) use a shared DMA buffer for the two
controllers like KA410 does, or does it use separate buffers? If it uses a
shared buffer, then it's no different from KA410 in this respect, and the
same driver arrangement which is used for the former (and which is present
in the generic VMS and Ultrix distributions) could be used unmodified on
the latter, giving it the generic SCSI disk and tape support. If this KA42-
SCSI/MFM system uses separate DMA buffers, then the HDC9224 driver that's
shared between this system and KA410 must be able to accomodate both DMA
schemes, and the same could be done for the generic disk/tape 5380 driver.
> There is also the minor fact that at the time that the uV2K/VS2K shipped
> the uVAX 3100 didn't exist and neither did its console. So there was no
> SCSI disk driver around in any form. Since the NCR chip was just used as
> a cheap way to interface to an existing low-end tape unit, there was no
> need to write a full blown SCSI driver; all that was done was the bare
> minimum to get the *required* functionality.
This is obviously true. However, there is only one product called "VAX
VMS" and only one product called "VAX Ultrix". There is no "VMS for VS2000"
or "VMS for VS3100". When KA42 and KA41 were developed, the single central
source trees for VMS and Ultrix had to be modified. The new versions of VMS
and Ultrix with KA42/41 support also have to run on KA410. Since the mass
storage subsystem hardware is either absolutely identical or has _VERY,
VERY, VERY, VERY_ minor differences between KA410 and KA42/41, writing a
new driver with the support for generic CCS-speaking SCSI disks and tapes
and using this driver for both KA42/41 and KA410 in the new versions of VMS
and Ultrix is the only sensible choice that could have been made by an
engineer in the sober state of mind. However, the decision was apparently
made by someone else, with the result that the old driver has been retained
and is used instead of the new one when running on KA410. _THIS_ is what I
mean by artificial feature blocking.
Sincerely,
Michael Sokolov
Phone: 440-449-0299
ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu