Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!ncar!ames!netsys!ziggy!scotty
From: scotty@ziggy.UUCP (Scott Drysdale)
Newsgroups: comp.sys.amiga
Subject: Re: Multiple Serial Ports (Re: vt100 v2.9)
Message-ID: <154@ziggy.UUCP>
Date: 14 Jan 89 05:47: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> <385@madnix.UUCP>
Reply-To: scotty@ziggy.UUCP (Scott Drysdale)
Organization: Un*x Link,Frederick Md.
Lines: 56

In article <385@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes:
>In article <150@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes:
[...cost/performance mutterings deleted...]
>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.

i still think you're getting into more overhead with DMA vs. onboard CPU.
obviously, doing a write from DMA to serial port would be deliciously
efficient - but input's another story.  how are you going to have the DMA
controller stop waiting for bytes from the UART and inform the host that
the transfer is complete without periodically polling the DMA to see if
anything came in, or adding timers on the serial board to generate interrupts
if no bytes have arrived after a certain (programmable) delay?  applications
for serial ports vary widely in their input rates, such as a user sitting
at a keyboard (one byte bursts), a mouse or other low volume instrument
(small bursts, say less than 50 bytes) and big bursts (like downloading
data from another computer or packet network).  though i suppose you could
have the host software dynamically adjust delays depending on how busy
things get.  i guess it'd work out ok, but...  a system i'm doing at work
uses DMA to/from a UART (it's a communications tester) and must poll the
receive and transmit DMA quite frequently to make sure no overflow occurs.
the maximum rate we've been able to transmit/receive at using this technique
(with the other tasks in the system disabled) is around 70Kbytes/second,
using an 8Mhz 80186 (see, that's where the 186 part of my design comes from -
THAR'S EMULATORS IN THEM THAR HILLS!), whereas the 8Mhz 186 in the intel 547
running my polling software can do an aggregate of 153.6Kbytes/second
(8 ports at 19.2K baud, all transmitting/receiving simultaneously.

>>>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!-)

the whole '86 family is a joke - but it can be fun to program the silly
things.
> 
>-- 
>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

 --Scotty