[comp.sys.amiga.hardware] Second serial port

perley@galaxy (Donald P Perley) (11/30/90)

Of coursr I ignored all this stuff when I didn't need it, but now...

I want/need a second serial port for my 2000.  The local dealer
quoted ~$350 for the commodore 2 port board.  I figure for that much
I might as well spend a little more and get a whole extra computer
(with serial port included!).

How are the aftermarket options priced (ASDG, others?), and is there
anything special about the commodore board that makes it so expensive?

-don perley

perley@trub.crd.ge.com

blgardne@javelin.es.com (Blaine Gardner) (11/30/90)

perley@galaxy (Donald P Perley) writes:

>I want/need a second serial port for my 2000.  The local dealer
>quoted ~$350 for the commodore 2 port board.  I figure for that much
                                ^^^^^^
Would you believe SEVEN ports?

>How are the aftermarket options priced (ASDG, others?), and is there
>anything special about the commodore board that makes it so expensive?

The A2232 from CBM is a seven port board, not two. The ASDG and
Checkpoint boards have two ports. I've got the A2232, and it works well.
Supported baud rates are 300-19,200 and a 100K baud mode. MIDI is not
supported, so you'll need one of the other boards if MIDI baud rates are
important to you.
-- 
Blaine Gardner @ Evans & Sutherland  580 Arapeen Drive, SLC, Utah 84108
blgardne@esunix.UUCP                       BIX: blaine_g
{decwrl, utah-cs}!esunix!blgardne          PLink: BlaineG
DoD #0046                          My other motorcycle is a Quadracer.

DXB132@psuvm.psu.edu (12/01/90)

In article <14383@crdgw1.crd.ge.com>, perley@galaxy (Donald P Perley) says:

>Of coursr I ignored all this stuff when I didn't need it, but now...

>I want/need a second serial port for my 2000.  The local dealer

As mentioned in some recent postings, there is a public domain I/O board
coming early next year that lets you add 8 ports (4 serial/4 parallel) to
a 500/1000/2000. 'Public domain' means it's sold at-cost. Expect a typical
4 port (2 serial/2 parallel) board fully populated to cost roughly $60.
Add another 4 ports by plugging in a couple chips.
Or you could spend  $200 on a commercial board that doesn't do half as
much, if you like. Unless you have a 500 or 1000, in which case there is
no commercial alternative.

To answer your question: Commodore's board is fancier than most, having its
own CPU and so forth, but $350 is a bit much, considering that the components
on the board are so darn cheap. FCC approval is expensive, but that shouldn't
bother big companies like Commodore. Maybe they're trying to make a profit
:-)

-- Dan Babcock

joseph@valnet.UUCP (Joseph P. Hillenburg) (12/02/90)

perley@galaxy (Donald P Perley) writes:

> 
> I want/need a second serial port for my 2000.  The local dealer
> quoted ~$350 for the commodore 2 port board.  I figure for that much
                                 ^ Thats 7 ports. Get your facts 
                                   straight.

> 
> -don perley
> 
> perley@trub.crd.ge.com


                        Joseph Hillenburg
             Secretary, Bloomington Amiga Users Group
joseph@valnet.UUCP                        ...!iuvax!valnet!joseph
  "Only Apple could slow down a 68030 chip." -Computer Shopper

davewt@NCoast.ORG (David Wright) (12/02/90)

In article <90334.151404DXB132@psuvm.psu.edu> <DXB132@psuvm.psu.edu> writes:
>To answer your question: Commodore's board is fancier than most, having its
>own CPU and so forth, but $350 is a bit much, considering that the components
>on the board are so darn cheap. FCC approval is expensive, but that shouldn't
>bother big companies like Commodore. Maybe they're trying to make a profit
	$350 for 7 ports is VERY reasonable when the board contains it's own
CPU. Perhaps you should check out the DigiBoard multi-port boards for
PC clones. They want about $350 for *4* ports when the board has it's own
CPU. Their 8 port board is significantly better.

	I would never use a board with more than 2 ports on it if it didn't
have it's own CPU. The only time a "dumb" board is worth the CPU overhead is
if you are running only low-speed devices, or you just want to be able to
attach 2 or three printers, and leave them attached rather than getting a
switch box. If you try to run 3 or 4 terminals at 9600 baud without a CPU
on the I/O board you will see significant speed loss.

		Dave

jms@vanth.UUCP (Jim Shaffer) (12/02/90)

In article <90334.151404DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:
>As mentioned in some recent postings, there is a public domain I/O board
>coming early next year that lets you add 8 ports (4 serial/4 parallel) to
>a 500/1000/2000. 'Public domain' means it's sold at-cost. Expect a typical
>4 port (2 serial/2 parallel) board fully populated to cost roughly $60.

Has anyone written any drivers for it yet?

--
paper :  James Shaffer Jr., 37 Brook Street, Montgomery, PA  17752
uucp  :  uunet!cbmvax!amix!vanth!jms  (or)  rutgers!cbmvax!amix!vanth!jms
domain:  jms%vanth@amix.commodore.com	    CompuServe: 72750,2335
quote :  ATTENTION ALL PLANETS OF THE SOLAR FEDERATION: WE HAVE ASSUMED CONTROL

edp367s@monu6.cc.monash.edu.au (Rik Harris) (12/03/90)

davewt@NCoast.ORG (David Wright) writes:

[commodore & IBM board details deleted]

>	I would never use a board with more than 2 ports on it if it didn't
>have it's own CPU. The only time a "dumb" board is worth the CPU overhead is
>if you are running only low-speed devices, or you just want to be able to
>attach 2 or three printers, and leave them attached rather than getting a
>switch box. If you try to run 3 or 4 terminals at 9600 baud without a CPU
>on the I/O board you will see significant speed loss.

>		Dave

[I have not used any of the multiple serial boards on any machine]

I dont know what level of hardware expertise you have, David, but your
comment is rather confusing.

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.

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

Now, I'm not saying that a product that doesn't have a CPU is _going_
to run much faster, just that there are more things to consider than
simply whether the product has a CPU on it or not.  Admittedly, the
product that can handle 3-4 terminals at 9600bps, that is on the
market first, would probably be one with the CPU, but it is still not
necessarily the best.

Rik. 
-- 
Rik Harris - edp367s@monu6.cc.monash.edu.au           | Build a system that
new address!  rik@sola.fcit.monash.edu.au             | even a fool can use,
Faculty of Computing and Information Technology,      | and only a fool will 
Monash University, Caulfield Campus, Australia        | want to use it.

Kevin Morwood <EETY1478@Ryerson.CA> (12/04/90)

Rik Harris writes:
>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.

This may be true but I wouldn't want to be working locally on the machine
that has 4 users dialed into it.  The main processor would be so busy with
all of the serial interrupts that you'd never get anything done.

>Now, I'm not saying that a product that doesn't have a CPU is _going_
>to run much faster, just that there are more things to consider than
>simply whether the product has a CPU on it or not.  Admittedly, the
>product that can handle 3-4 terminals at 9600bps, that is on the
>market first, would probably be one with the CPU, but it is still not
>necessarily the best.

But the product with a CPU (and other perfermance enhancements) will
undoubted spend less time on the dealer's shelf than it's unintelligent
counterpart.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Morwood
EETY1478@Ryerson.CA
kevin@lsimages.UUCP

DXB132@psuvm.psu.edu (12/04/90)

In article <jms.1922@vanth.UUCP>, jms@vanth.UUCP (Jim Shaffer) says:

>In article <90334.151404DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:
>>As mentioned in some recent postings, there is a public domain I/O board
>>coming early next year that lets you add 8 ports (4 serial/4 parallel) to
>>a 500/1000/2000. 'Public domain' means it's sold at-cost. Expect a typical
>>4 port (2 serial/2 parallel) board fully populated to cost roughly $60.

>Has anyone written any drivers for it yet?

Yes. A prototype of the hardware was done almost 2 years ago, but it wouldn't
do to release it without software. I wrote a serial driver, a parallel driver
by Paul Coward is on the way, and Jeff Lavin has written a plethora of excellen
t utilities including a serial preferences progra, a clock program, test progra
ms, and more. We also wrote a program that intercepts OpenDevice to permit use
with older programs that don't let you specify the driver name and unit. It
pops up a nice window asking you to select which unit you want to use.
Naturally we supply 100% source code for everything, and users are encouraged
to modify the code (hopefully sending the result back to us, eh? :-))

We also expect many users will write custom software for their applications
that use the parallel IO. We'll try to provide enough documentation and
examples to help you do so with a minimum of effort.

-- Dan Babcock

perley@trub (Donald P Perley) (12/04/90)

In article <wH3iT3w163w@valnet>, joseph@valnet (Joseph P. Hillenburg) writes:
>perley@galaxy (Donald P Perley) writes:
>
>> 
>> I want/need a second serial port for my 2000.  The local dealer
>> quoted ~$350 for the commodore 2 port board.  I figure for that much
>                                 ^ Thats 7 ports. Get your facts 
>                                   straight.

I have gotten numerous replies telling me that the commodore board has
7 ports.  You probably saw some of them if you scanned the current
articles before following up, unless you are in the electronic
boonies.  Is your "F" key tripping prematurely?  I would get it
checked out.

Nonetheless, my statement above still stands as correct.  If you 
read it again, you will see that I am merely reporting (accurately)
what the dealer offered me.

-don perley


--
perley@trub.crd.ge.com

davewt@NCoast.ORG (David Wright) (12/04/90)

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

drysdale@cbmvax.commodore.com (Scott Drysdale) (12/04/90)

In article <1990Dec3.053356.26826@monu6.cc.monash.edu.au> edp367s@monu6.cc.monash.edu.au (Rik Harris) writes:
>davewt@NCoast.ORG (David Wright) writes:
>
>[commodore & IBM board details deleted]
>
>>	I would never use a board with more than 2 ports on it if it didn't
>>have it's own CPU. The only time a "dumb" board is worth the CPU overhead is
>>if you are running only low-speed devices, or you just want to be able to
>>attach 2 or three printers, and leave them attached rather than getting a
>>switch box. If you try to run 3 or 4 terminals at 9600 baud without a CPU
>>on the I/O board you will see significant speed loss.
>
>>		Dave
>
>[I have not used any of the multiple serial boards on any machine]
>
>I dont know what level of hardware expertise you have, David, but your
>comment is rather confusing.
>
>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.
>
>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).
>
>Now, I'm not saying that a product that doesn't have a CPU is _going_
>to run much faster, just that there are more things to consider than
>simply whether the product has a CPU on it or not.  Admittedly, the
>product that can handle 3-4 terminals at 9600bps, that is on the
>market first, would probably be one with the CPU, but it is still not
>necessarily the best.

what you want a multiport serial card to do is annoy the host machine's CPU
as little as possible.  consider 8 ports sending and receiving at 19.2K baud
simultaneously with no hardware or local CPU assist, interrupting the host
CPU for each character.  that's close to 32,000 interrupts per second -
certainly not a desirable load on the host CPU.  put a CPU on the serial
card, however, and you can start trasferring large blocks of data between
the card and the host at lower rates, and have the card's CPU do all the
step'n'fetch to service the ports.  *extreme* reductions in host CPU overhead
are possible.

of course, the latency between a character completing assembly in one of the
UART's receive registers and when the host actually sees it is potentially much
greater than the direct interrupt approach, so this kind of thing wouldn't be
great for midi or other timing sensitive applications, but with a little more
code on the card's CPU, you could do decent timestamping and pass the data
to the host with the timestamps already there.

certainly a pure hardware approach without CPU intervention (intelligent
DMA, for instance) would be even faster, but this is only 8 ports we're
talking about, running at fairly low speeds.  i imagine your packet switch
has hundreds or thousands of "ports" to deal with.

>
>Rik. 
>-- 
>Rik Harris - edp367s@monu6.cc.monash.edu.au           | Build a system that
>new address!  rik@sola.fcit.monash.edu.au             | even a fool can use,
>Faculty of Computing and Information Technology,      | and only a fool will 
>Monash University, Caulfield Campus, Australia        | want to use it.

 --Scotty
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Scott Drysdale           Software Engineer
Commodore Amiga Inc.     UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!drysdale
		         PHONE (hopefully sometime this year)
"Have you hugged your hog today?"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

edp367s@monu6.cc.monash.edu.au (Rik Harris) (12/04/90)

I was going to reply to David in email, but since three people have
posted followups, I changed my mind.

davewt@NCoast.ORG (David Wright) writes:

>	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.
   This is where a CPU is the most useful: flexability.  If you have
an on-board CPU, then the software you run can easily be changed,
which can change the entire operation of the circuit.  No argument
here.


    Now, I obviously didn't explain myself very well when I first
posted the article (I have been working on the project mentioned for
too long :-).

>                                                                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.
    That is not quite what I meant.  The hardware that we have
designed does all the buffering *in hardware*.  It does not interrupt
the host CPU, because there is *no* host CPU.
>	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
which user programs would be run in the local CPU?  I can't think of
any at the moment (feel free to correct me :-)
>	b) Run the driver for the serial ports
done in hardware
>	c) Watch for flow control on all ports
done in hardware

>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.
As I said before there is no host CPU anyway.  I also mentioned orders
of magnitude speed increases (which does not lend itself to RS232
applications). These increases were over a node that handled 4 i/o
ports running at 9600bps each.

>	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).
Ahhh, but that's where the confusion lies.  I was not comparing those
dumb boards that run 4 9600 lines with a CPU driven board.  I was
talking about our hardware that runs 8 ports a 2Mb/s (hopefully
scaleable to 20Mb/s).
I think the problem is that I was not talking about multiple serial
ports for PC's in particular, I was talking about communications
equipment in general (and we're not talking about lots $$, either, its
an *educational* research project)

>	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.
If you are interested in the project I am talking about, I will
happily discuss it with you via mail.  It is not PD, and it is fast.
I might add that the project as a whole _does_ use a CPU, but it has
nothing to do with data transfer.

>                                                             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. :-)
ahhh, a man after my own heart :-) :-)

I'll just quickly mention the article from drysdale@cbmvax.commodore.com
(Scott Drysdale)
[no offence, Scott]

> what you want a multiport serial card to do is annoy the host machine's CPU
> as little as possible.
> [very good justification deleted]
couldn't agree more (see above)

> of course, the latency between a character completing assembly in one of the
> UART's receive registers and when the host actually sees it is potentially much
> greater than the direct interrupt approach, so this kind of thing wouldn't be
> great for midi or other timing sensitive applications, but with a little more
> code on the card's CPU, you could do decent timestamping and pass the data
> to the host with the timestamps already there.
Yes, this is the advantage of an on-board CPU, It is very flexible, so this
sort of thing can be done _very_ easily.  (ie, I agree)
> 
> certainly a pure hardware approach without CPU intervention (intelligent
> DMA, for instance) would be even faster, but this is only 8 ports we're
> talking about, running at fairly low speeds.  i imagine your packet switch
> has hundreds or thousands of "ports" to deal with.
no, It's only 8 ports, but we do want a very large throughput (well,
as much as we can).
The original network was based on nodes with a Z80 CPU (approx 1 MIP)
and four i/o ports.  It could run at 9600 bps fine, but we wanted more
speed.  If we put in a 10 MIP processor, we would get a 10x increase in
speed, but when we designed it with no processor, we could get
(theoretically, its not finished yet!) 2Mb/s easily, and hopefully
about 20Mb/s through each of 8 ports.
For the same reason we avoid using the host processor for character
interrupts, we removed the local processor so it would not need to be
interrupted, instead all the controlling, and buffering is done in
hardware.

Please mail me if you are interested in the project, I don't really
want to waste too much bandwith, for a fairly narrow (and non-amiga)
topic.


[sigh!   maybe I shouldn't have brought up such a theoretical topic :-) ]
>			Dave
>  --Scotty

Rik.
-- 
Rik Harris - edp367s@monu6.cc.monash.edu.au           | Build a system that
new address!  rik@sola.fcit.monash.edu.au             | even a fool can use,
Faculty of Computing and Information Technology,      | and only a fool will 
Monash University, Caulfield Campus, Australia        | want to use it.

p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (12/05/90)

In article <1990Dec3.053356.26826@monu6.cc.monash.edu.au> edp367s@monu6.cc.monash.edu.au (Rik Harris) writes:
>davewt@NCoast.ORG (David Wright) writes:
>>switch box. If you try to run 3 or 4 terminals at 9600 baud without a CPU
>>on the I/O board you will see significant speed loss.
>
>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.
>
>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.

It's true that a serial board with a CPU is limited to the speed of
that CPU but your "specialised curcuit" isn't a good comparison, maybe
the term CPU is a little confusing.

What was meant is that with the Amiga, there are two types of serial
boards. One uses plain UARTs while the other uses a dedicated CPU
to control these UARTs. The dedicated CPU makes this solution faster
since the "dumb" board has to be controlled by the main CPU whereas
the dedicated CPU can work in parallel and reduce overhead by buffering
requests.

So the difference is the "intelligence" of the board. This can be achieved
with a CPU or with some hardware with higher sophistication than a plain
UART.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."

joseph@valnet.UUCP (Joseph P. Hillenburg) (12/05/90)

perley@trub (Donald P Perley) writes:

> In article <wH3iT3w163w@valnet>, joseph@valnet (Joseph P. Hillenburg) writes:
> >perley@galaxy (Donald P Perley) writes:
> >
> >> 
> >> I want/need a second serial port for my 2000.  The local dealer
> >> quoted ~$350 for the commodore 2 port board.  I figure for that much
> >                                 ^ Thats 7 ports. Get your facts 
> >                                   straight.
> 

Yes. My UUCP site has a 24 hour netlag. I reply, and then see a flood of 
articles on the same subject the next day, after I reply.

> -don perley
> 
> 
> --
> perley@trub.crd.ge.com


                        Joseph Hillenburg
             Secretary, Bloomington Amiga Users Group
joseph@valnet.UUCP                        ...!iuvax!valnet!joseph
  "Only Apple could slow down a 68030 chip." -Computer Shopper

scot@amigash.UUCP (Scot L. Harris) (12/09/90)

>In article <jms.1922@vanth.UUCP> jms@vanth.UUCP (Jim Shaffer) writes:
>In article <90334.151404DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:
>>As mentioned in some recent postings, there is a public domain I/O board
>>coming early next year that lets you add 8 ports (4 serial/4 parallel) to
>>a 500/1000/2000. 'Public domain' means it's sold at-cost. Expect a typical
>>4 port (2 serial/2 parallel) board fully populated to cost roughly $60.
>
>Has anyone written any drivers for it yet?
>

More importantly, has anybody written/give thought to making the changes
in preferences so the added parallel ports can be selected?  The new
serial.device that comes with the A2232 allows selection of the default
serial port (1 through 8) so that those programs that don't allow 
selection of the serial port unit number will work just as before.

Something similar would need to be done for the parallel.device.  A new
version of parallel.device that understands how to talk with multiple
ports and a new preferences screen that allows selection of a default
parallel port so old programs will still work transparently with the new
ports.  

I asked a similar question some time ago and did not get much of an answer.
The few parallel port solutions available appear (IMHO) to be some what
kludgy at best.

>--
>paper :  James Shaffer Jr., 37 Brook Street, Montgomery, PA  17752
>uucp  :  uunet!cbmvax!amix!vanth!jms  (or)  rutgers!cbmvax!amix!vanth!jms
>domain:  jms%vanth@amix.commodore.com	    CompuServe: 72750,2335
>quote :  ATTENTION ALL PLANETS OF THE SOLAR FEDERATION: WE HAVE ASSUMED CONTROL

--
          _                                                                
    ///  /_\      Scot L. Harris ...!tarpit!bilver!amigash!scot 
  \XX/  /   \ M I G A                 Orlando, FL (407)273-1759 
[Prodigy censor messages?  Nah, they wou

mlknol@cs.vu.nl (Knol Marcel L) (03/12/91)

Hello outthere,

	I have an Amiga B2000 with a modem, connected to the 
serial port. Now I want to connect an IBM PS2/30 to a second 
serial port.  Can someone give me advice on a good board and 
its price. 
	Are  there  any limitations  or problems  that could 
occur? Can someone describe the null-modem cable I need?

Thanks in advance,

Marcel Knol
--
Marcel Knol,                           ...!mcsun!hp4nl!star.cs.vu.nl!mlknol
Vrije Universiteit Amsterdam,          <mlknol@cs.vu.nl>
Department of mathematics and computer science,
The Netherlands.

stevef@bug.UUCP (Steven R Fordyce) (03/14/91)

In article <9280@star.cs.vu.nl> mlknol@cs.vu.nl (Knol Marcel L) writes:
>	I have an Amiga B2000 with a modem, connected to the 
>serial port. Now I want to connect an IBM PS2/30 to a second 
>serial port.  Can someone give me advice on a good board and 
>its price. 

One option is the MultiPort board from DigiFeX.  The MultiPort board adds
the following to an Amiga 2000 or 3000:

		A printer port

		An RS232 port on a 9 pin DIN

		An RS422 port on an 8 pin mini DIN

		Optionally ($50 extra), a SCSI hard disk controller

The printer port is meant to free up the Amiga's parallel port for things
other than printers, like digitizers.  The RS232 port has the same pinout as
a standard AT serial port.  The RS422 port can be used as a serial port (it
has the same pinout as a Mac and takes the same cables) or with DigiFeX's
Interact software ($80) can be used to network Amiga's on an AppleTalk
compatible network.  The SCSI controller is one of the fastest 8 bit
transfer controllers available for the Amiga.  The MultiPort board costs
$250 (U.S.).

If it is not already obvious, yes I work for DigiFeX.

				     Steven R Fordyce
				 uunet!sequent!ether!stevef

DigiFeX, 610 Main Street, Oregon City, Oregon  97062, USA
For customer service or orders, call (503)656-8818, FAX (503)656-8903