Path: utzoo!attcan!uunet!lll-winken!netsys!ziggy!scotty
From: scotty@ziggy.UUCP (Scott Drysdale)
Newsgroups: comp.sys.amiga
Subject: Re: Multiple Serial Ports (Re: vt100 v2.9)
Message-ID: <150@ziggy.UUCP>
Date: 12 Jan 89 01:47:17 GMT
References: <8812150227.AA09671@postgres.Berkeley.EDU> <14049@oberon.USC.EDU> <554@sunkisd.CS.Concordia.CA> <3241@sugar.uu.net> <147@ziggy.UUCP> <373@madnix.UUCP>
Reply-To: scotty@ziggy.UUCP (Scott Drysdale)
Organization: Un*x Link,Frederick Md.
Lines: 65

In article <373@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes:
>In article <147@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes:
>>first of all, anyone who develops a multiport serial board that doesn't have
>>it's own CPU on board is absolutely nuts.  using interrupts from the UARTs
>>is also grounds for the electric chair.  i've done this before - the board was
>
>We've done this before, too. And I guess we're absolutely nuts and should be
>put to death, too.
>
>The real toss-up here is that if you want to design a high-end (pricey)
>multiport serial board, you must choose between an on-board processor, and
>DMA support.

so the parts cost is around $30 more than a non CPU design - but you end up
with much greater throughput.  i prefer performance over inexpensiveness.
how well would the interrupt or polling scheme using only the 68000 work when
you add several of these boards to the machine with 8 ports on each board?

>With DMA, the main CPU doesn't have to move any data anywhere, thus data-
>transfers are easier on it. Also, the main CPU gets about as many interrupts
>either way - there's a bit more overhead for checking the ports to see who's
>really done, and vectored interrupts would take care of that.

yeah, DMA is cool - but DMA on the amiga has it's little problems.  i think
a DMA design without it's own CPU would be as costly as the CPU on board
approach and would require more overhead from the host CPU than the CPU on
board method.

>The main reason for putting a processor on-board is to add intelligence to it,
>such as command parsing, built-in error correction protocols, etc.

that's one of the good things about a CPU design.  you *CAN* do those things
"offline" and get better performance.  there is no penalty (except cost) for
having the CPU and not really needing it for offline processing.

>>an intel SBC547, which is a multibus I card with and 80186, 4 zilog SCCs, and
>
>Oh, and since I'm nuts, I guess I get to call anyone who programs an 80186 in
>assembly nuts.

assembly is the only way to program an '86 family CPU correctly - the compilers
i've met up with get too bogged down with bookkeeping to do a decent job.  the
'547 board was mostly PL/M (which has the best code generator i've seen other
than microsoft C) and only the 1ms UART poll interrupt handler was done in
assembler.  i think this one should be assembler all the way.

>>anyone have any comments?
>
>Yes. I like the idea of a timer interrupt for handling this if you don't have
>DMA. The real problem with that is when you only have one CPU to handle the
>interrupts, the timer is more overhead than needed when the ports _aren't_
>very active.

yes - that's true (more overhead when there's nothing to do).  but that's
no problem, since the board's purpose in life is to handle serial ports, and
nothing else.  as i said before, it's a GOOD thing to have the board busier
polling ports since it'll naturally tend to send things to the host in
bigger bunches.

>Aaron Avery, ASDG Inc.         "A mime is a terrible thing to waste."
>                                 {decvax|att}!               -- Robin Williams
>UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron
>                               {uunet|ncoast}!marque!

  --Scotty