Benson-Varian Plotter and 4.2bsd

[Ben Goldfarb Esq.]

<<<<<AUTOSTEP>>>>>

Just in case people are still having problems with the distributed Berkeley
4.2bsd Varian driver, I thought I'd share my experiences.  I had my share of
grief with it, but now it seems to be working fine.  If you are getting
numerous npr timeouts, unibus resets, and cp read faults when you use the
Varian, reading paragraph 2 below will help.  Paragraph 1 is for those like
me who insist on not reading manuals.

1)  Make sure you read the manual page VA(4) before doing a kernel config!
The configuration, as the manual page points out, is counter-intuitive.  It
was explained to me as being necessary because of a RK07/Unibus problem, but
I didn't get into that too far.  For those who are too lazy to read the
manual, here is the configuration:

	controller	va0 at uba0 csr 164000	vector vaintr
	disk		vz0 at va0 drive 0

2)  The npr timeouts on the Unibus are caused by an improper switch setting
on the DMA option board.  Switch E2, section 1, should be OFF.  This means
that the GO bit is supplied to the CSR by software.  If it is ON, the GO bit
is forced on when the word count register is written -- this generates npr
timeouts.  Examining the code section below (from vastart() in the 4.2bsd 
driver) helps one see why this is necessary:

	vaaddr = (struct vadevice *)um->um_addr;
	vaaddr->vacsl = 0;
	vaaddr->vawc = -(bp->b_bcount / 2);   /* wc reg written here */
	um->um_cmd = VA_DMAGO | VA_IENABLE;   /* csr not written yet */
	(void) ubago(vadinfo[unit]);	      /* it gets writen in ubago() */

Our 4.1 driver, from Stanford, used the following sequence:

	vaaddr->vacsl = 0;	/* clear GO bit before writing new wc */
	vaaddr->vaba = sc->sc_ubinfo;
	vaaddr->vawc = sc->sc_wc;	/* wc reg written here */
	vaaddr->vacsl = ((sc->sc_ubinfo >> 12) & 0x30)|VA_DMAGO|va_intbit;
			/*  csr written here  */

It seems that the code above was intended to be used with the switch in the OFF
position (the software DOES supply the GO bit), but we had it ON.  Evidently
we got away with it because there were only a couple of machine instructions
between writing the wc register and the intended device startup time.  A
much greater amount of code is executed after writing the wc register in the
Berkeley 4.2 driver; this is why we didn't have the npr timeout problem
until we brought up 4.2bsd.

				Ben Goldfarb
				University of Central Florida
				uucp: {decvax,duke,princeton}!ucf-cs!goldfarb
				ARPA: goldfarb.ucf-cs at Csnet-Relay

P.S. to Alan Parker
Thanks for all the help.  Need to get mmdf working to get in touch with you.
I wonder if this was your problem all along?