Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!uwvax!astroatc!nicmad!madnix!aaron
From: aaron@madnix.UUCP (Aaron Avery)
Newsgroups: comp.sys.amiga
Subject: Re: Multiple Serial Ports (Re: vt100 v2.9)
Message-ID: <385@madnix.UUCP>
Date: 13 Jan 89 12:49:15 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> <150@ziggy.UUCP>
Reply-To: aaron@madnix.UUCP (Aaron Avery)
Organization: ASDG Incorporated
Lines: 62

In article <150@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes:
>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?

I agree wholeheartedly with you on the performance over inexpensiveness issue,
but you and I are not the entire Amiga community.
We also had the price vs. versatility issue to contend with. Since we were
designing the Twin-X multi-purpose I/O board, we decided to implement our serial
hardware as iSBX modules, which leads to great versatility. You can have 2, 4,
6, or 8 serial ports on one board, with varying costs to match. You could also
have 4 serial ports in one module position, and IEEE-488 (or any of hundreds
of I/O functions, for that matter) in the other.

When you start to add more and more active serial ports, of course system
performance will be degraded. With no processor or DMA support on the serial
board, the main CPU will probably spend most of its serial-support time
handling the interrupts.
The next step up is an on-board processor. With this configuration, the host
CPU spends most of its serial-support time copying the data from dual-ported
RAM into its main memory. This operation is quite efficient compared to
interrupt handling.
What I feel is the highest throughput configuration, barring protocol-specific
support on a processor-equipped board, is DMA support. With this configuration,
the host CPU only has to handle the interrupts, which only happen after
complete block requests are completed. These take up just as much host CPU
overhead as those required for the on-board CPU method. However, the RAM-
copying step is eliminated from the host's responsibility, and occurs much
faster than the host could do it anyway.

>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.

Yes, DMA on the amiga has its little problems, and our board doesn't use DMA.
But there would definitely NOT be more overhead from the host CPU. The
difference there is that the DMA method places the data in its final
destination with no code execution on the host CPU. With the dual-ported
RAM method, the host CPU must move the data to its destination itself, which
is far less efficient than the DMA would be.
 
>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.

True. And there's that cost thing again!

>>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 was not knocking anyone for programming the '86 family in assembly vs. doing
so in another language. I was bashing people for programming the '86 family
in assembly vs. programming other CPU families in assembly!
It's a joke, son!-)
 
-- 
Aaron Avery, ASDG Inc.         "A mime is a terrible thing to waste."
                                                             -- Robin Williams
UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!aaron
ARPA: madnix!aaron@cs.wisc.edu