Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ll-xn!singer
From: singer@ll-xn.UUCP
Newsgroups: comp.sys.atari.st
Subject: RTS/CTS
Message-ID: <454@ll-xn.ARPA>
Date: Thu, 12-Mar-87 08:55:40 EST
Article-I.D.: ll-xn.454
Posted: Thu Mar 12 08:55:40 1987
Date-Received: Fri, 13-Mar-87 06:44:44 EST
Organization: MIT Lincoln Laboratory
Lines: 34
Keywords: RS232 bug


>From sansom@trwrb.UUCP (Richard Sansom) Wed Mar 11 11:44:24 1987
>Newsgroups: comp.sys.atari.st
>Subject: Re: TOS RS232 bug?
>
>In article <453@ll-xn.ARPA> singer@ll-xn.ARPA (Matthew R. Singer) writes:
>>...Since the ST can not keep up at 9600bps...

>The terminal program you're using is probably using the (small) system rs232
>buffer, which would certainly account for the problem.  The answer?  Get a
>program which establishes its own (large) rs232 buffer.  Simon Poole's
>Uniterm _must_ be doing this, since I've had no problem at all using it at
>9600bps.
>
>-Rich
>

You miss the point... The US Robotics HST modem is designed to use
CTS/RTS flow control.  If you were to say dump a 300K file to
the ST, youd need a BIG buffer if you didnt use flow control and
XON-XOFF just wont do it for binary transfers.

Having a big buffer does not compensate for the "STANDARD PORT"
not being usable with "STANDARD PROTOCOLS".

What about output? The HST modem can be setup so it ALWAYS takes
data from the computer at 9600, but may be sending it out at some
other rate depending on line conditions.  It needs to be able to
drop CTS to stop the ST from sending.  How is a big buffer going 
to help this???   


Matt Singer
Commnet Systems