"sokolov@alpha.CES.CWRU.Edu" "Michael Sokolov" wrote:

>> 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

I don't have any info on either of the two PVAX daughter boards so I don't know
whether the SCSI/MFM variant suffers from the same hardware limitation as the
UV2K implementation.

>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.


On a UV2K DVDRIVER implements the MFM disks and TVDRIVER drives the tape.

On later systems the SCSI drivers use a common set of subroutines to handle
SCSI protocol details and what you find in e.g. PKNDRIVER.LIS for the 5380 is
the stuff required to talk to the 5380 itself and make it waggle the wires.

TVDRIVER could be converted to fit into the later scheme of things and become
(a currently mythical) PKVDRIVER but that would not have been a trivial task.
However, by the time the VS3100s came out, the VAXstation 2000 was efectively
obsolete (i.e. more expensive to produce but offering about one third of the
power). So there would have been no incentive to rewrite TVDRIVER.

And note that the comments to TVDRIVER itself point out that it takes advantage
of its environment (i.e. it only has to support one device on a limited range
of systems). This made it easier and quicker to write in the first place but
would have probably made it a poor base for a new all-purpose 5380 SCSI 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

One source tree, yes but different actual drivers.

> 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.

I wasn't there so I don't know for certain but ...

When the UV2K/VS2K was developed SCSI was not perceived to be the way disk
drives were going to be headed in the future. The RD53/RD54 already existed and 
most of the code to support them as MSCP devices also existed (all that error
recovery etc.). The SCSI chip was used purely to provide a tape interface for a
box which had limited expandability - this was one of the reasons that it could
be built so comparatively cheaply.

When the VS3100/UV3100s came into being, admittedly only a few years later, DEC
must have realised that there was a market for cheaper systems and someone
decided that despite the disadvantages SCSI disks were cheap but sufficiently
reliable for a low end system (remember that at this stage SCSI devices varied
quite widely in their behaviour). So since SCSI was here to stay someone
decided that it would be a good idea to separate SCSI-ness from the particular
hardware implementation of the systems SCSI bus. Thus the new SCSI drivers were
born and the UV2K implementation stayed outside the fold. To have done
otherwise would have required not only a re-engineered driver but also a
re-engineered console (no point having a disk if you cannot boot from it).
Given that the 2K systems were effectively obsolete there would have been no
point in devoting resources to this task as there was no expectation of a
return for that investment.

Antonio

Antonio Carlini                            Mail: carlini@marvin.enet.dec.com
DECnet-Plus for OpenVMS Engineering
Digital Equipment Corporation              Worton Grange, Reading, England