Whilst playing pleaseantly with VAXentoyz of KA630/KA650 calibre,
in anciente BA123 cabinete..... I seem to be hitting some TK50
quirks.... probably old hat, but I can't seem to backtrack to it if
it is, and thus am looking for some fixes or places to try fixing
(me not muchofa code guru but what da heck...I seem to be da one
complainin' da most....(:+}}...).

Symptom: A.   MVII KA630 on TKQ50 runs Ultrix fine to/from TK50 tape.

         B.   MVII KA630 on TKQ50 runs NetBSD-1.4.3 and 1.5.1B2 not at
              all.  Tape blinkenlights itself to pieces.

         C.   MVIII KA650 on TKQ50 runs Ultrix fine to/from TK50 tape.

         D.   MVIII KA650 on TKQ50 runs NetBSD-1.4.3 and 1.5.1B2 not
              at all.  Tape blinkenlights itself to pieces.

Change to latest revision controller that I can find and:

         E.   MVII KA630 now works in Ultrix and NetBSD-1.4.3, but
              1.4.3 emits a fair number of sync timeout errors.
              NetBSD-1.5.1B2 emits same sync timeout errors but
              seems to work a little better.

         F.   MVII KA650 now works in Ultrix and NetBSD-1.4.3, but
              1.4.3 emits a fair number of sync timeout errors.
              NetBSD-1.5.1B2 still not working...tape blinkenlights.


It smells like a timing problem, since when the cpu speeds up, the
thing starts having problems, possibly initializing the transport.

From the DEC newsfeed on the net, from the guys there, I find, 
QUOTE:

> Recently, I had run into a problem of upgrading an MVII to an MVIII,
> and then started having TK50 tape problems.  A few folks on the grapevine
> suggested that there were problems in the KA650 cpu with TK50 tapes, but
> I did not find out exactly what.  In essence, using a KA650 cpu instead
> of a KA630 cpu boardset made the tape unread/writeable.  Putting the
> KA630 boardset back, and all was fine.  It was not a particular hardware
> problem with my boardsets, but was a known bug in early KA650 cpus.
> Anyone know anything about this?  Is there a fix or workaround in
> Ultrix or NetBSD?

  Could be 2 things (or an interaction).

  1) There have been a lot of firmware fixes to the TQK50 controller - try
     getting new firmware. Note that it's usually cheaper to just buy a re-
     placement controller.

  2) Early KA650 CPUs had a problem with the Q-bus interface chip, which
     broke a lot of 3rd-party controllers. This was one of the most expen-
     sive FCO programs inside Digital (but not as big as the RA81 HDA one).
     I forget the exact rev where the fix got made, but if your CPU has the
     "fancy" console firmware, with "help", command recall, etc. it is al-
     most certain you have the new QBIC's.

UNQUOTE.

and

QUOTE:

> Recently, I had run into a problem of upgrading an MVII to an MVIII,
> and then started having TK50 tape problems

I ran into this problem 10 years ago, upgrading an '86 vintage MVII to a
CPU card from a MV3600.  The problem is in the firmware for the TK50
Q-Bus controller.  I was able to obtain a newer EPROM for the TK50
controller card and that fixed it.  However, the system I worked on has
long since been scraped so I don't have the firmware rev number anymore.

UNQUOTE.

So, I digs around in me spare parts box for what TKQ50s float to the
surface, and find 3, with the latest a 1988 vintage card from a VAX
4000/200 crate, and plops it in for some testing.

The later revision TKQ50 helps some, but is still not right, except
on Ultrix.

Another fellow from the net, who did the MVII coding for V10 Research
Unix, including the TK50 bits, and who went over his sources for me,
replied,
QUOTE:

Can you say any more about the symptoms?  e.g. what error do you get,
and does it happen when the device is opened or only at read or write
time?

I use my TK50 about once in a blue moon, but I was pretty sure it
worked fine even after I replaced all my KA630s with KA650s.  Not
utterly positive, so I just fired it up for the first time this
millenium; it reads an old tape fine, and writes and reads a scratch
tape fine too.  Of course my device driver has no code in common with
anyone else's, and if the problem was specific to early KA650s I don't
know whether mine qualify.

The one oddity I can see in my driver code is that the UQSSP driver
(which is used in common by the various MSCP ports of that type--
UDA50, KDA50, KRQ50, TKQ50, RQDX3, ad nauseum) has a special hack
in the reset code.  If an interrupt occurs while initializing the
port:
	a.  There is a 100us stall before reading the SA register.
	A comment says the UQSSP spec requires this.  I don't remember
	just when it went in.
	b.  If an interrupt occurs during initialization, SA should
	have either the ERR flag set or one of the STEP[1-4] bits.
	(Actually STEP[2-4], I think, but never mind.)  My driver
	loops 20 times waiting for that:

		for (i = 0; i < INIRETRY; i++)
			if (rp->udsa & (STEPS|ERR))
				break;

	INIRETRY Is a manifest constant with value 20.

I vaguely remember putting that loop in; I thought it happened
during the first Research UNIX port to the MicroVAX II (which was
done mostly by Ted Kowalski, with me stepping in now and then when
he needed a hand), but an old informal change log I still have
says (with my name attached) that it happened in 1988 and was
needed by Mayfair.

If there isn't such a wait-for-slow-device loop in whichever BSD
you're using, you might try sticking one in to see if it helps,
at least if you're not sure the port-init code is finishing
correctly.  I can't tell you offhand what goes where in the driver
(one day I will have enough time and disk space ...), but the
magic numbers in loop above are

#define	INIRETRY 20	/* TQK50 botch -- needs time to settle */
#define	ERR	0100000
#define	STEP4	040000
#define	STEP3	020000
#define	STEP2	010000
#define	STEP1	04000
#define	STEPS	(STEP1|STEP2|STEP3|STEP4)

I'd be interested to hear how it comes out in any case.

UNQUOTE.

In V10 Research UNIX, he had to put in a delay loop counter for
20 loops to allow enough time for the TK50 to initialize
correctly.  In perusing the Ultrix PDP-11 code, where the TK50
support first came in, there is a delay counter of 200 loops
in the initialization process before certain registers are set.

Where is all this happening in the NetBSD VAX code?  My first
grepping through only turned up the boot tmscp.c bits, and I
would think it might be elsewhere that I need to look.

This really needs some fixing.  Surely I am not the only `El Stupido'
with this problem?

Any pointers as to where to look for the right bits to fix,
do holler.  Although TK50's are dinosaurs, they are still useful,
on the older Qbus toyz, and it really needs to be done right, if
continued support for them is desireable.  I was hoping 1.5.1
would work on these tape transports, but it don't quite do that
in my hands.

If anyone has the correct eprom code, or can burn a good eprom set,
that I should be using, do holler.

Need input!  Need input!  As Johnny No. 5 was want to say......(:+}}...

Thanks

Bob