Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!faatcrl!jprad
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: 19200 baud amiga
Message-ID: <978@faatcrl.UUCP>
Date: 12 Feb 91 13:29:35 GMT
References: <CSHORT.91Feb4171549@aiaia.nmsu.edu> <2587@tmiuv0.uucp>
Distribution: comp
Organization: FAA Technical Center, Atlantic City NJ
Lines: 60

rick@tmiuv0.uucp writes:

>The Amiga's serial hardware has problems at bauds greater than 9600, I
>think.  The 2000/2500's does.  I believe the CBMSpeak on it is, "It is
>not reliable."  I have ASDG's DSB board in my A2500/30.  It works fine
>at 19,200.  I've used it in my 3000, too, but I've not tried anything
>faster than 9600 (betwixt Amoeba III <the 3000> and XyClone <a Unix box>).

  The official blurb in the RKM on serial I/O is that anything above
19.2kbps is "optimistic".  In actuality, any Amiga can handle serial
output.  It's serial input that gets stickey depending on the confiuration
of the system being used.

  What I've found is that a baseline 7MHz Amiga can easily do 19.2kbps
serial I/O so long as a few things are taken into consideration.

  - Fast ram.  If the system only has chip ram or $C00000 ram available,
    the cpu can't run full tilt and may not be able to honor serial input
    interrrupt quickly enough to prevent data overruns.  Interestingly, the
    A1000 is less effected by this since it is running the system code in
    ram instead of the slower ROM of an A500 and A2000.  I think it's about
    9% faster, or so I remember someone else posting that figure.

  - 8 and 16 color screens shouldn't be used.  The extra chip DMA that these
    require can lead to data loss as well.  Flow control will help, but data
    can still be lost.  If large amounts of text are going to be displayed,
    a 2 color screen is recommended.

  - More than 2 floppy drives combined with a couple of HD partitions can
    cause AmigaDOS to disable the system long enough to cause data loss.
    It's due to the once-a-second disk changed checking that is done.

  - Certain types of HD controller can also lead to data loss, those that
    are hogging the bus for DMA transfers or have device drivers that run
    at excessively high priorities are the worst offenders.

  - Having other tasks/processes running that hog the cpu also contribute
    to serial data loss.

  Although these are by no means the *only* situations that can effect
serial I/O, they are the most common ones that I've found that can cause it.
It usually takes a combination of a few items to really cripple the system
at 19.2kbps.

  As for the A3000, I've been able to drive it at 38.4kbps without a burp.
Of course, it's a 25MHz beast with 80ns scram, so that may not be the case
with 16MHz flavors of the machine or without scram installed.

  I've been able to obtain close to 3550cps using ZMODEM via a direct
connect from an A1000 to an A3000 at 38.4kbps (using JR-Comm of course).
The reverse can't be checked since the A1000 totally dies at that rate.
I was surprized that the A1000 could even handle the handshake at the 
start of the transfer, but it did.  At 19.2kbps, the A1000 obtained 1910cps
in both directions without data loss.  All transfers were with text files,
compressed files cause ZMODEM character escaping to occur which slows down
the transfer accordingly.

  As you said, "your milage may very"...

  -jack-