Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!ncoast!davewt
From: davewt@NCoast.ORG (David Wright)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: second serial port
Summary: That's like the DMA argument
Keywords: 2232 7 port
Message-ID: <1990Dec4.025744.18641@NCoast.ORG>
Date: 4 Dec 90 02:57:44 GMT
References: <90334.151404DXB132@psuvm.psu.edu> <1990Dec2.141048.10108@NCoast.ORG> <1990Dec3.053356.26826@monu6.cc.monash.edu.au>
Organization: North Coast Public Access *NIX, Cleveland, OH
Lines: 58

In article <1990Dec3.053356.26826@monu6.cc.monash.edu.au> edp367s@monu6.cc.monash.edu.au (Rik Harris) writes:
>I dont know what level of hardware expertise you have, David, but your
>comment is rather confusing.
	I am both an EE and a CS engineer.
>
>A CPU will add convenience to the design of a piece of hardware, not speed.
>A CPU needs to be clocked, and must access memory, and the hardware is
>limited by the speed the CPU can run at.
	Not quite true. Having a CPU on the board allows you to run custom
software on the board, without needing the HOST CPU to do this. It also allows
you have large buffers (most of the multiport boards by DigiBoard have at
least 128k of RAM on them too), and transfer this data (from all the various
ports) to the host in one big piece, rather than having to do character-level
I/O, which ties up the bus unneccessarily. Doing I/O this way at high speeds
is like trying to build a hard disk interface that doesn't use DMA. It can
be done, and for less money, but it won't run as fast as a DMA system, and
it will tie up the host CPU more than a DMA device.
	Having ANY CPU on the board allows parallel proccessing. While the
host CPU is running some other program for you, the serial board is taking
care of all the little details, like flow control, watching hardware latches
(for things like DTR/DSR), etc. If you don't have a CPU on the board, you
have to expect the host cpu to:

	a) Run the user programs
	b) Run the driver for the serial ports
	c) Watch for flow control on all ports

both b & c must be done as often as possible, or you will lose data.
>For the last year I have been working on a Packet Switching Local Area
>Network (what it is/does is not really relevant) that is pushing away
>from the CPU, because it is too slow.  We have built specialised
>circuits to have the hardware do all the buffering and switching of
>packets without CPU intervention.  Doing this, we have increased the
>potential speed of the device by ORDERS OF MAGNITUDE (more than 3
>orders).
	I think you are either getting confused and meaning the host CPU
when you say "without CPU intervention", or you are using a very slow
proccessor on your I/O board. Ideally, a board for the Amiga would have
something like a 10 Mhz 68010, or even a 68000, and as the clock speed is
only on the board, it doesn't have to match up directly with the host CPU
speed.

	I have tried to fight around multi-I/O boards for the PC that
didn't have their own CPU, and I can tell you that their producers were happy
if they could get 4 9600 baud I/O transmissions going full blast at the same
time. I almost have to laugh when you compare those boards with something
that can handle *8* ports (or even 16), running at 38400 at the same time,
without any extra host CPU activity (except for simply reading in the
data to send, that is).

	The only advantage that a board without a CPU has is that it is
cheaper, and easier to build. For a PD project, that's fine. But for
real multi-user use, especially under something like Amiga Unix, you are
going to want something that doesn't chew up your host CPU time. X
will take care of that just fine. :-)


			Dave