Subject: UARTs for use in KL8-JA

From: [email-masked] (Charles Lasner)
Date: Sun, 28 Feb 1993 15:37:19 GMT

It would be tempting to use one of the newer styles of UART's in the
M8655 KL8-JA card, especially since they are rated at much higher rates
than 19,200 baud.  Presumably someone can work up a board hack to allow
for 38,400 and higher, but finding a UART for higher than 40 KBaud is
going to be difficult due to the following:

The KL8-JA design depends on an obscure behavior of the original GI UART
and the few approved alternate vendor products (TI, SMC).  When a 
character is received by the UART, it raises the character available signal
just as all similar UART's do.  However, should this character not be
unloaded by software before another character arrives, then the chip behavior
differs from other designs.  The required behavior is that the character
available signal lowers and raises again.  Most UART's merely leave the
character available signal high and also set the overrun condition.  But
the KL8-JA design demands that "wink" for every character.

I once put a socket on a KL8-JA to try out various vendors' UART's in the
board, including the Intersil/Harris 6402.  They basically came in two
flavors - ones that passed a little test, and ones that did not.  (The 6402
was in the don't pass list.)  Here's a little test program:

	KCC		/CLEAR THE FLAG NOW
	KRS		/READ THE BUFFER
	AND	(177)	/JUST 7-BIT
	TAD	(-15)	/IS IT A CR?
	SZA CLA		/SKIP IF SO
	JMP	.-4	/NO, WAIT UNTIL HE HITS CR
	KRS		/READ THE BUFFER
	AND	(177)	/JUST 7-BIT
	TAD	(-12)	/IS IT A LF?
	SZA CLA		/SKIP IF SO
	JMP	.-4	/NO, WAIT UNTIL HE HITS LF
	KSF		/FLAG UP?
	HLT		/BARF ON BAD CHIP!
/	COMES HERE IF UART IS OK.

You run the program and then hit first CR then LF.  If the program halts,
then KSF can't skip during the overrun condition caused by the user typing
two characters while there is no software "looking" at the chip.

I first noticed the problem after all appeared to be working when I attempted
to use ^S and ^Q to suspend the output of the OS/8 KL8E handler.  The program
hung :-(.  Eventually, the problem was distilled down to whether or not it
could pass the little test program above.  It is totally reasonable to expect
software to get one char out of sync with what's arriving.  It's unacceptable
that as a consequence, the interface hangs!

So, to avoid this, use only the original spec UART's in KL8-JA.  The most
likely vendor today is SMC.

cjl