Subject: Re: Correct modem signalling for SE/30?
To: None <davagatw@mars.utm.edu>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 08/13/1996 12:54:11
> 
> On Mon, 12 Aug 1996, Michael L. Kornegay wrote:
> 
> > serial cable was removed from the port on the computer.
> >
> > Any suggestions here?
> 
> Well, that means that the computer thinks the SE/30 isn't ready to receive
> data.  Since that pin is ttl high (+5 v) normally and drops low when the
> receiving unit is ready to receive, (judging by the symptoms, I'd say the
> power source is generated by the receiving system), unplugging the cable
> would kill the power to the pin, dropping it low, to an effective ground
> state when you unplug it.

Maybe. It depends upon the chip (and possably on the particular chip).
when you unplug the pin, you float the input and get indeterminate
results. It sounds like, for this case, the input driver (which is between
the plug and the serial chip) will treat the float as a logical 0,
asserting CTS (which is active low).

> A couple possible solutions:
> 
> 1.	Try another cable.

Good check!

> 2.	Try XON/XOFF, assuming that's supported (don't remember)

NetBSD supports it, but it's not good for binary transfers. :-)

> 3.	Try the printer ports on _both_ systems.
> 
> I've used my PowerMac as a serial console for my PB145 for a long time
> with no troubles, but when I tried it with a Classic II, the only
> configuration that worked was connecting the _printer_ port of each
> together.  If I used the modem port on either system or both systems, I
> got the same symptoms as you mention above.  Very strange.

This problem is REALLY WEIRD. The software driver for each port (on the
NetBSD side) is exactly the same. Also, AFAIK, there's no hardware
difference between the two, other than the fact that the Modem port can
accept an external clock signal on the GPi (DCD) pin (both accept clocks
on the HSKi (CTS) pin).

Hmmm.

Idea 4: Don't worry as much about flow control. Set NetBSD to use
crtscts flow control, and MacOS to use DTR flow control. In this case,
MacOS can tell NetBSD to shut up, but NetBSD can't tell MacOS to shut
up. Also, MacOS won't worry about the input flow line.

I'll be interested to see if this works at 57600. If there are breaks in
the data coming to NetBSD, it should. If the data comes non-stop, there
MIGHT be a problem, I'm not sure. People (including me) have gotten
ppp working between NetBSD boxes at 57600 w/o problem. :-)

Take care,

Bill

> Hope those help,
> 
>  /---------------------------------------------------------------------\
> |David A. Gatwood             And Richard Cory, one calm summer night,  |
> |davagatw@mars              Went home and put a bullet through his head.|
> |dgatwood@nyx.cs.du.edu              --Edwin Arlington Robinson         |
> |http://mars.utm.edu/~davagatw -or- http://nox.cs.du.edu:8001/~dgatwood |
>  \---------------------------------------------------------------------/
> 
> 
> 
>