Subject: Re: TK50Z
To: None <port-vax@NetBSD.ORG>
From: Michael Sokolov <sokolov@alpha.CES.CWRU.Edu>
List: port-vax
Date: 02/17/1998 19:37:27
   Dear Allison,
   
   You wrote:
> You were.
   
   Does this statement refer to me being alive when you first started
working on VAXen, or to me being insulting? If the latter, I sincerely
apologize. If that was the case, it was completely unintentional, and if
you point out the specific instance, I'll try hard not to repeat it.
   
> However at almost 19 you are lucky but, don't alienate
> us fossels that have been around the track in the industry neary twice
> that.
   
   Where was I alienating anyone? (Again, I apologize if I was.)
   
> The underlying assumption hardware=male.
   
   AT NO POINT WAS I MAKING THIS ASSUMPTION!!! Being unable to determine
your gender from your name, I was not making any assumptions about it
whatsoever (until Kevin has misled me).
   
> VAX was aimed at the
> supermini market, then after some time we have these little VAXen
> (730, 72x, MV-I and later) emerging and changing the rules.  A lot
> of the little VAX  oddities can be better attributed to the previous
> unibus vaxen and the ubiqitious Q-bus PDP-11s the vax hardware was
> ported to.  Much of small VAX history is a result of the PDP-11 hardware
> already in place.
   
   I know this.
   
> <  But you have to agree that the way an OS treats the hardware does tel
> <you something about the hardware itself, even if you don't use that
> <particular OS.
>
> I don't agree with that.  If anything it tells me a lot about the
> designers philosophy prior to that hardware.
   
   But if an OS uses the exact same code to support two systems, it must
follow that they are the same or at least very similar. And vice-versa, if
two systems don't share a single line of supporting code in an OS, this
indicates that there are very significant differences between them.
   
> <BTW, I wonder what do you have to say in response to my last posting on
> <the subject (the ~30 KB one from 31-JAN-1998). If you don't have it,
> <tell me and I'll send you another copy. Your response would help me
> <better understand what's going on and eventually contribute to UNIX
> <BabyVAX support.
>
> Deleted, to much, too hard to read.
   
   This is directed to the whole list. If you want working SCSI and MFM
drivers for BabyVAXen, as well as the ability to boot directly from SCSI
disks on KA410s, you should lobby Allison to read that posting and respond
to it. I have archived it at <http://sclwww.scl.cwru.edu/~mxs46/cpu13.txt>.
   
> If you haven't figured it out from 84ish to 92ish DEC internally was a
> bunch of often reorganized fifedoms and each had their own marketing.
> So each new baby vax was influenced by sometimes disparate marketing and
> engineering decisions.
   
   This is pretty much what I was imagining. Thanks for making this
explicit!
   
> What does that mean, the design rules for VS2k
> were different from 3100 and they were tasked different from the rest of
> the vax groups as DEC was uncertain where and what they were doing.
   
   This is pretty much what I was saying all along, but read further.
   
> So
> you have a basic cpu archetecture plagued by diverse hardware support,
> divergent address assignments and design rules. All annoyingly similar
> but just enough different.  Those oddities lead to things like the
> 3100m76 a really nice machine having no Ultrix support.
   
   In the case of KA43 (VS3100 M76) there are some objective differences
from KA42/41, and you do need to write some actual code (even if it's 10
lines) to make a BSD system support it. VAX BSD systems have a separate
file named ka<xxx>.c for each CPU they support. Which of these files get
into the kernel is determined by the "cpu VAX<XXX>" lines in the config
file. This is how Berkeley UNIX(R) and NetBSD work, and I can bet that
Ultrix is no different. To support KA43, you need ka43.c. This is a rather
simple piece of code, since all the hard work (supporting SCSI, Ethernet,
serial lines, graphics, etc.) is done in CPU-independent (but architecture-
dependent) files which have already been written to support KA410 and
KA42/41. Writing this file may actually take only 30 minutes for
programming and a few hours for debugging, but someone at DEC had to have
his/her manager allocate those 30 minutes and a few hours to this task,
which that manager has refused to do with the oddity you are describing as
a consequence.
   
   The situation with SCSI on KA410 vs. KA42/41 is completely different. It
is certainly true that there are some differences between the two (UV2 vs.
CVAX and some DMA differences), but these are already handled at the
ka<xxx>.c level. Now look at a higher level, the drivers for CCS-speaking
SCSI disks and tapes, called perhaps rz.c and tz.c. I can bet that
somewhere in those files there are two lines similar to the following:
   
   if (cputype == UV2)        /* Is this a VS2000? */
       return 0;              /* Y - Don't load the driver */
   
   These two lines are absolutely unnecessary. Take them out and you'll
have a version of Ultrix that supports SCSI disks on KA410 systems. I know
that VAXstar (VS2000) and PVAX (VS3100) were designed by different teams. I
know that the two teams had different mass storage solutions in mind. But
there was only one Ultrix source tree, and no matter how the engineering
teams were structured and no matter what mass storage solutions did they
have in mind, adding two lines of code to the Ultrix source tree that
artificially block the loading of a driver cannot be classified as anything
but high treason and a crime against humanity.
   
> There are amazingly good sources for VAX hardware and software design.
> The VMS orange or gray wall and the other more scarce DEC stds 1->201.
> DEC standards are the basic internal hard and fast rules for how to do
> everything from a outside corrigated box lable to what a VAX is and must
> do.  Other standards like Q-bus, MSCP, MASSBUS and other useful items
> are encased there.  DEC stds obviously are not public and a full set is
> a wall of binders as well.  But most of the important parts are burried
> in tech manuals for disks, tapes, display systems and the like.  If you
> read enough of them the whole picture is available.  Most of those are so
> old that unless scanned by someone they will not be on the net.
   
   Thanks for the information!
   
> As to reading tons of
> paper, good.  No doubt many here have contributed to the origination of
> those tons.
   
   Don't hold your breath, most of those tons are not about DEC hardware.
My interests are quite diverse, and I have actually contributed more to the
IBM PC and MS-DOS world than to the DEC world. (The balance may shift a
little, though, when I release my work on BabyVAX support.)
   
> I've only written a few CPU manuals and some of my better
> works are enshrined in some dusty archive as a design spec, or technical
> description.  I'd severly doubt your not impressed with that.
   
   I certainly have the highest respect for your work. Have you ever seen
any implications to the contrary in my postings?
   
> By the same
> token nor am I of your comment of what you've read.  It's unimportant and
> ego basting.
   
   I have never had a slightest intention of basting my ego. However, in a
lot of your comments you treat me like a newbie or a beginner, and I'm
trying to convey it to you that I'm not one. Let's end this childish
argument and talk like professionals, OK?
   
> Results speak for themselves [...]
   
   I fully agree. That's why I'm trying so hard to get some work done ASAP.
   
> [...] right no this newsgroups goal is
> PORT-VAX or better said improving the quality of NetBSD to a reliable
> robust OS for VAX platforms.
   
   BUT WHY NECESSARILY NETBSD?!?! If there are much better codesets around,
why not use them instead? As for the encumbered code, I have addressed that
issue in the posting immediately preceding this one.
   
> <   I have never proposed any convention, so I don't know what you are
> <referring to, but if I were to give a definition for "busless", I would
> <use something like what you are saying. BTW, what's 4004?
>
> The convention predates you and you misused it.
   
   Where was I misusing the convention?
   
   PLEASE read my posting archived at
<http://sclwww.scl.cwru.edu/~mxs46/cpu13.txt>. Even if you find my work
useless because it's for Berkeley UNIX(R) and not for NetBSD, having a
replacement system ROM for KA410 that allows booting from SCSI disks would
be extremely useful for everyone, don't you agree?
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu