Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!news.arc.nasa.gov!haven.umd.edu!umbc3.umbc.edu!umbc4.umbc.edu!brian
From: brian@umbc4.umbc.edu (Brian Cuthie)
Newsgroups: comp.sys.next
Subject: Re: RTS/CTS flow control only oneway?
Keywords: modem flow RTS/CTS cufa 19200
Message-ID: <1991Jun23.023945.2896@umbc3.umbc.edu>
Date: 23 Jun 91 02:39:45 GMT
References: <4975@gmdzi.gmd.de>
Sender: newspost@umbc3.umbc.edu (News  posting account)
Organization: Univ. of Maryland Baltimore County, Academic Computing Services
Lines: 39

In article <4975@gmdzi.gmd.de> kloppen@gmdzi.gmd.de (Jelske Kloppenburg) writes:
>Hello,
>Since I had problems with XON/XOFF flow control, I finally tried RTS/CTS
>(System Release 2.0 / 68040). After making the correct cable (man zs(4))
>I tried my modem connection with cufa. To be sure, I inserted a breakout
>box and interrupted CTS. Now no data should be send by the NeXT, but I could
>type and got echo from the remote host.
>Have I to set special flags in Kermit or Tip or is the handling of RTS/CTS
>done by the hardware or driver ?
>And what does the following note mean:
>

Well, you may want to actually assert the signal to the desired state.  Since
you don't know what state it floats at, you can't be sure that simply
interrupting it actually causes the host to see loss of CTS.

My guess is that it floats in the "let the data go" state.  That way, if 
you use the cuf[n] device, and CTS is not wired, it will still pass data.

><nextdev/zsreg.h>
>
> * NOTE: the sense of CTS is dependent on the cpu board rev
>

Wow! I didn't know that.  Are you sure?  That's certainly not a feature.

>?
>
>Are there different 68040 boards?
>
>j.k.
>
>  Jelske Kloppenburg, kloppen@gmdzi.gmd.de, (++49 2241) 14-2433
>  German National Research Center for Computer Science (GMD)


Let me know if this works.

-brian