Subject: Retrocomputing, VAXen, and NetBSD
To: Michael Sokolov <sokolov@alpha.CES.CWRU.Edu>
From: Bertram Barth <bertram@ifib.uni-karlsruhe.de>
List: port-vax
Date: 02/09/1998 09:51:57
Michael Sokolov writes:
>    Apparently a flame war is taking place on this list regarding VAXen,
> retrocomputing, and NetBSD, and I want to make it clear to everyone what my
> position on this issue is. The way I view it is that there are two kinds of
> retrocomputing: hobbyist retrocomputing and professional retrocomputing.

Ty Sarna (sp?) has already said what is to say about that.

>    Before I have joined this list, I considered NetBSD to have one major
> merit: BabyVAX support. In theory it's outstanding. Berkeley UNIX(R)
> currently doesn't have any, and (again in theory) NetBSD/vax surpasses
> Ultrix in BabyVAX support, since it supports KA43 and treats NCR5380 SCSI
> controllers the same way for all CPUs. However, upon joining this list I
> was quickly disenchanted. It turned out that NetBSD's support for BabyVAXen
> is simply unusable because of problems with DMA and bad block replacement,
> as well as countless bugs and crashes. Please don't take this as an insult

Just to get some facts straight (which reminds me on some related statement
concerning NFS and IDE [Hi Andy!]) the drivers for NCR5380 and HDC9224 are
rather broken (while I have to say that they are/were relatively stable on
my 2 machines), but the LANCE driver is quite stable which makes NetBSD/vax
on netbooted 2000/3100 machines with swap and fs via NFS as stable as on
uVAX-II (these are the machines I could compare. YMMV).

Also due to bugs and other ugly things in the HDC/NCR drivers the performance
of 2000/3100 via NFS on a lightly loaded network is much better than the
performance with support for local disks...

And BTW: I myself don't care about a RD32 being "old" or "classical" or
	 something else. If my machine is running stable with NFS then 
	 I'll use NFS.

> toward the people who work on it. I have the highest respect for Ragge and
> Bertram for implementing the BabyVAX support. It is simply unfortunate that
> the fruits of their work go underutilized because they were based on the
> wrong codeset.
  ^^^^^^^^^^^^^

Your opinion. Mine is different. See below.

>    I have decided to base my work on implementing REAL BabyVAX support on
> the Berkeley UNIX(R) codeset for the following reasons. Since the BabyVAX
> support code in current NetBSD/vax is so poor. people who need REAL BabyVAX
> support will probably have to rewrite it from scratch. In this light, the
> present BabyVAX support in NetBSD doesn't give it any advantage over
> Berkeley UNIX(R). On the other hand, NetBSD/vax is not very well fit for
> supporting BabyVAXen. Remember that before Bertram's work NetBSD/vax didn't
> support anything except MSCP, while Berkeley UNIX(R) has a couple of
> decades of support for physical interfaces. For instance, adding absolutely
> perfect support for HDC9224 disks to Berkeley UNIX(R) should be a piece of
> cake with the superb sc/up driver as an example. Also Berkeley UNIX(R)
> would be a better base than NetBSD for developing a VAX OS that runs on the
> entire range of VAXen from 780 to perhaps VAX 4000 and MV3100 M30+.

IMHO you could do a great job in fixing/rewriting the drivers for HDC9224
and NCR5380 (plus DMA etc.) in NetBSD/vax. With these pieces existing and
working support for "BabyVAXen" would become real.

AFAIK all the rest of NetBSD/vax is as stable on "BabyVAXen" as on other
types of VAX. These two drivers are the source for all (or at least most
of) the grief. If it's really "a piece of cake with the superb sc/up driver 
as an example" then please do it! [No harm intended.]

>    As for reliability considerations, NetBSD/vax again looks pale compared
> to Berkeley UNIX(R) and Ultrix. Ultrix was a commercial product with strict
> quality requirements, so it's certainly very stable and bug-free. As it
> happens, Berkeley UNIX(R) is not that far behind. A lot of code has been
> contributed to CSRG by DEC. All of this code was originally written for
> Ultrix, so the reliability of Ultrix was essentially shared with Berkeley
> UNIX(R). Even the code written by CSRG guys themselves without DEC's
> assistance is still better than what one usually finds in NetBSD/vax.

Don't underestimate the problems with copyrights and encumbered "free"
(whatever that means) versions. I can't see the advantage of modifying
"Berkeley UNIX(R) and Ultrix" which I don't have access to over working
on NetBSD/vax which is available and running on my machines...

Ciao,
	bertram