Dear Antonio,
   
   You wrote:
> 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.
   
   Thanks, now I can use the actual driver names rather than say "the
driver for blahblahblah".
   
> 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.
   
   This is certainly true. However, why bother with TVDRIVER in the first
place?! _PKNDRIVER_ would work UNMODIFIED on KA410 if it didn't contain a
few lines of code that check the CPU type and prevent the driver from
loading if it's KA410. This is what I have been meaning all along by
artificial feature blocking.
   
> So there would have been no incentive to rewrite TVDRIVER.
   
   But apparently there has been enough incentive to add extra code to
PKNDRIVER to artificially prevent it from working on KA410.
   
> 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.
   
   But an all-purpose 5380 SCSI driver already exists: that's PKNDRIVER.
   
> One source tree, yes but different actual drivers.
   
   But they don't have to be different. Deliberately making them different
against all common sense constitutes artificial feature blocking.
   
> 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).
   
   There would be NO need to re-engineer the driver, unless removing the
lines that do the artificial blocking constitutes as re-engineering. As for
the system ROM, the work would be absolutely minimal: lift the DK/MK code
from the KA42 ROM, plop it into the KA410 ROM, and reassemble. I would do
this in thirty minutes (plus a few hours for learning, but DEC engineers
would have already had this) if someone were to give me the sources. But
really they didn't have to do even this. All they needed to do would be to
add the following text to the VMS equivalent of a manpage for PKNDRIVER:
"This driver has been intended for MV3100 and VS3100 only. It can be made
to work on MV2000 and VS2000, but this is unsupported and you won't be able
to boot from SCSI disks. If you want to try using this driver on an MV2000
or a VS2000 at your own risk, enable it by doing the following: ..." Not
adding this text and adding the CPU-type-checking-and-blocking code instead
is what I mean by artificial feature blocking.
   
> 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.
   
   I don't see much investment in adding four lines of text and removing
two lines of code.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu