8-port serial async cards??

[uhclem at trsvax.UUCP]

R5>Anvil advised us that they would be looking into the problem and attempt to
R5>fix it, but that they weren't confident of being able to do so (this I don't
R5>understand -- we're talking RAW input -- which should be more efficient than
R5>"cooked" output, no -- besides there's an 8MHZ 80186 on that board!).  This
R5>conversation took place about 6 weeks ago -- and we have not heard anything
R5>from Anvil yet regarding a possible fix.

The problem on some of these boards IS the choice of the 186.  Face it, the
intel 80186 is rather limited on IN/OUT opcodes.  Boards that use 8530 serial
chips with a 186 further complicate the problem by performing all
communication to a port via two ports.  One is the data path, the other is a
control pointer that selects what register the other port will access, very
muck like the 6845 CRTC.  Hardly any of these boards bother to add the glue
necessary to use these as memory mapped devices, so you find code like this:

		mov	dx, ctlportA
		mov	al,RR2		;Want to read Rx status
		out	dx,al
		jmp	$+2		;Because they pick the 8530's
					;with slow recovery time as much
					;as 4 8530 clocks + 200 usec
		mov	dx,datportA
		in	al,dx		;Read status
		test	al,CHARAVA	;Is a Char available
		jnz	xxx
		mov	dx,ctlportA	;Point at data reg
		mov	al,RR8
		out	dx,al
		jmp	$+2
		mov	dx,datportA
		in	al,dx		;Read byte

Any questions?  You haven't even checked for framing or parity errors yet,
much less cleared them or resolved the interrupt on the embedded 8259.
Although 8250's require less juggling, they require more intervention than
the 8530.  And if you find a board with an 8251 on it, keep walking very fast.

The 8530 also provides vectored interupt support with 8 vectors per chip
(four per port, Rx, Tx, Special, Error), but the 186 interrupt system
doesn't understand Z80 IM2 vectoring, so it usually isn't used, and each chip
must be polled to find out which one (or more) of the eight items generated
the interrupt.  So with an 8259 interrupt controller, the best it can
do is narrow the source of the interrupt down to a chip.  Then you must
read the interrupt register on the chip and call all the routines necessary
to handle the eight possible pending interrupt sources.

An 80186 with an 8030 (a version of the 8530 that lends itself to being
memory-mapped, all 16 registers directly accessible) would be far more
efficient.  For example, an memory-mapped 8030 doing the same task as above:

		mov	ax, Seg8030A
		mov	es,ax

		mov	bx, Off8030A
		test	es:[bx+RR2],CHARAVA	;Is a Char available
		jnz	xxx
	;	jmp	$+2			;Not normally needed on
	;					;the 8030 but you can add it
		mov	al,es:[bx+RR8]		;Read char

I forgot to mention wait states.  Although they may have an 8MHZ 80186
and 150nsec memory (slowest possible with 0 wait states), some designers
made too lengthy or used to slow address decoding schemes and were forced
to add a wait state.  Sometimes these are added to help handle arbitration
when the onboard memory can be accessed by the host CPU (286/386).  So
the 186 may actually be running at an effective 6MHZ or less.


My ideal board would use a Z280 and an 8030.  The Z280 reads IM 2 
interrupts so the exact routine necessary could handle each interrupt
without any other checking.  (A Z180/HD64180Z could also be used but
you would need at least 10MHZ to handle 38,4000 on 8 lines.)  The Z280 has
onboard CTC's and DMA, so this would reduce the external part count.  The
plain old 6MHZ Z80 can handle eight ports, but max would be 8 9,600 baud
conversations, or 4 19,200.


<My opinion, and not that of my golden retreiver who is busily applying
 for a federal grant so he can develop HDTV compression algorithms...>
						
					"Thank you, Uh Clem."
					Frank Durda IV @ <trsvax!uhclem>
				...decvax!microsoft!trsvax!uhclem
				...sys1!hal6000!trsvax!uhclem
			If it made sense, they wouldn't buy a new one.