VAX 750 Upgrade (GET YOUR FACTS STRAIGHT!)

[brown at kpno.UUCP]

>We have had the same trouble, but managed to fend the DEC-people off.

Enough of this nonsense!

I would think that since you people know about DEC and ULTRIX and presumably
that decvax is reachable via electronic mail that you could send mail to the
folks there and ask them what is really going on rather than cluttering up
USENET with misinformation.  If you don't know anyone there try
"decvax!postmaster".

The information I received from DEC concerning the 750 FCOs
is that you can run Un*x with no problems.  And indeed you can because
Un*x does not use the stuff which is being fixed(4.3BSD might though
I don't know). 

We are happily running 4.xBSD on our 750's with the FCO's installed.
4.xBSD functions happily both with and without the patch area loaded.

My understanding of the situation is that the Rev. 5 FCO installs a
"patch" area for microcode fixes.  This patch area is "RAM" which is
loaded by the OS at boot time.  The VAX will function without loading
this patch area.

Problems which Rev. 5 fixes: (taken from DIGITAL FCO)

    -	Premature Read Lock Timeout when a Read Lock Bus function is done on
	the CMI.

    -	On unaligned data transfers using the buffered data path, when Unibus
	address bits 0 and 1 are asserted the UBI microsequencer will branch
	to DATOB execution flows on a DATI.

    -	The CPU writes to a Unibus Map Regsiter and clears the valid bit
	while the UBI is asserting SSYN on the Unibus.  SSYN can be deasserted
	before MSYN deasserts.

    -	The contents of the Time of Year Offset Register are modified upon
	assertion of UBUS DCLO L.

    -	The UBI can assert DBBZ in response to a CPU Unibus reference after
	entering the purge microcode flows, causing the system to hang.

    -	The refresh logic does not always work correctly on power up with
	six or more M8750 arrays.

    -	A patchable control store is needed on the 11/750 and 11/751 CPU's.

Rumor & Hearsay:

There is yet another Rev coming out soon as well.  This will be Rev. 6.
Apparently there wasn't enough time to get all the problems straightened
out in time to release Rev. 5.  Rev. 6 should finally fix the translation
buffer parity error problem.

	regards,
	Mike Brown	National Solar Observatory
			Tucson, Arizona			(602) 325-9249	

UUCP:	{akgua,allegra,arizona,decvax,hao,ihnp4,lbl-csam,seismo}!kpno!brown
CSNET:	brown at arizona
ARPA:	kpno!brown at lbl-csam.arpa    or    brown%arizona at csnet-relay