> "Greg A. Woods" <woods@weird.com> wrote:
> [ On Saturday, May 4, 2002 at 20:40:38 (-0700), Don Yuniskis wrote: ]
> > Subject: Re: SparcStation ipx versus Sparc Classic
> >
> > > "Greg A. Woods" <woods@weird.com> wrote:
> > >
> > > > (ie. and how do we mimic the behavior)
> > >
> > > replace the RS-232 drivers on your motherboard and use only "approved"
> > > terminal devices....
> >
> > I suspect folks doing this will note no change in results.  For those
> > using PC's/laptops, I imagine the "solution" would be a pulldown
> > on the input to the driver -- since it is undoubtedly being driven
> > from a Combo and floats until the Combo is configured by the
> > BIOS.
>
> That's what that resistor is designed to do....  Are you sure you
> experimented with various values?

No.  The resistor on teh RS232 "connector" biases the input of the
*receiver* to a MARK state.

The Combo chip inside most (modern) PC/laptops implements
"COM1, COM2, LPT", the RTC (in some cases), floppy controller,
[E]IDE controller (in some cases), ATX power supply control
(in some cases), etc.  The transmit *outputs* from the Combo
feed the inputs to the "RS232" transmitters/drivers *on* the
"motherboard".  The output of those drivers then leaves the machine
and ultimately ties to the *inputs* of the receivers (RxD in this case)
in the Sun.

Returning, once again, to the laptop/pc...

When the input to the "RS232" driver on the MB is at a "low" (0V)
level, the output of the driver is at the SPACE condition (> +3V).
When the input to the driver is "high" (5V), the driver outputs a
MARK condition (< -3V).

[N.B. My previous comments were exactly backwards... (sigh)
A consequence of just hammering out replies without spending
the time on them they deserve!  <:-(  I'll *hope* I got it right
this time... too early in the morning  :<  ]

Now, the pins on the Combo chip (remember, we are still
"inside" teh motherboard... nowhere near the RS232 connectors,
yet...) typically have several potential uses (alternate functions).
How they are used is determined by the designer and enforced
by teh BIOS writer.

The pin that is used as the "transmit data" for a paticular UART
("COM port") may also have an alternate use as an *input* for,
perhaps, some power management function (??), spare interrupt, etc.
The actual role/use of the pin is determined by writing a (set of)
configuration register(s) within the Combo chip.

Now, when the machine first powers up, the Combo chip has to
assume some default state.  If the configuration register(s) assume
this particular pin should be an *output* (e.g., the transmit data
line for a UART inside teh Combo chip), then the pin will be
actively driven as soon as the power supply comes up.  But,
if the board designer wanted, instead, to use the *alternate*
function for this pin -- that of a power management *input* - -then
elsewhere on the board, there is some logic trying to actively
*drive* this pin... to force this "power management" signal *into*
the Combo chip.

Combo chip trying to force the transmit data for the UART *out*
that pin; power management circuitry (for example) trying to
force something *into* that pin.

Bad kharma.

Of course, htis "short circuit" will be "fixed" whenever the BIOS
gets around to reconfiguring the Combo chip -- assuming it
doesn't crash or deliberately lock up testing memory, etc.

A safer design (of the Combo chip) is to have all pins that
could be input *or* output signals (depending on the way the
BIOS eventually configures it) default to an "input" state.  In this
case, if external circuitry is trying to drive a signal *into* the
pin, there will be no conflict (no "short circuit") -- even if the
BIOS crashes (think about the development debugging for the
motherboard/BIOS).

The problem with this default behaviour is when the signal *is*
used as an output -- until the Combo chip is reconfigured to
convert this signal into it's intended output function (e.g., as transmit
data from the UART), there is nothing driving the signal!  it's state
is ndeterminate -- "floating".

Recall that this *output* feed the *input* of the RS232
driver/transmitter (we're still on the motherboard... the RS232
connector is on the *other*/output side of this driver).  So, the
driver -- whose output is connected, via cable, to the RxD
*input* of the SPARC ("Remember SPARC?  This is a song
about SPARC...") -- doesn't know what "level" to drive the
output signal to.  If the input to the driver "floats" high (due to
leakage current or a pullup (to +5V) on the signal, then
the output of the driver will assume the MARK level (-3V).
If, on the other hand, the input hovers close to GND, then
the driver will put a SPACEing level on it's output (to the
SPARC).

Eventually, the Combo chip will get "programmed" and that
particular pin will assume it's role as an output and the RS232
driver will then be "told" to drive the line to a MARK.  But,
when this happens in the BIOS startup sequence is up to the
writer of that BIOS...

By contrast, teh resistor added to the RS232 connector tries to
bias teh *input* to the SPARC's *receiver* to the MARK level.
But, if the input to the RS232 *driver* inside the pc/laptop is
"telling" the driver to put a SPACE level on that wire, then the
resistor will have no effect.  It is as if the laptop was intentionally
driving the line to SPACE... intentionally trying to BREAK...

> Of course there's not much you can do if a device generates an
> intentional BREAK condition when it comes online, or has line drivers so
> poorly designed that they simulate a real-looking BREAK condition one
> one power transition or both.....  Only a really good RS-232 analyzer
> might stand a chance of differentiating between these two too....
>
> > > (and at least make sure if your machine is a model with selectable
> > > signal levels that you've selected true RS-232 levels....)
> >
> > Done when I first prepped the box for service...  give me *some*
> > credit!  :>
>
> Just checking!  ;-)
>
> My little RS232 bible (*) is old enough to be rather out-of-date w.r.t.
> available technology for even Sun-3s, but it's new enough to decry IBMs
> stupid use of the 75154 instead of the "industry standard" MC1489.  If

I suspect a consequence of TI pushing the device in their Linear & Interface
Applications book -- *they* didn't have a 1489 at the time, IIRC.

> Sun did anything similar on their older machines than they've definitely
> made the situation worse (by more than doubling the sensitivity of
> (IIRC IBM's mistake was so widely copied it became a standard: RS-423-B,
> well maybe that's a bit of an exaggeration, but...)

The '154 can be used successfuly (I've used '152's -- a "dual" version of
the
"quad" '154) -- just as the '1489 can be used *unsuccessfully*.  Actually,
I t hink you can "bend" the switching thresholds of the '15x to more
accurately reflect the levels specified in EIA232x (as well as the amount
of hysteresis).  The problem is, most folks don't bother with those
"little details" (I've even seen designs use +5 & -5 for the drivers
instead of +/- 12V).

> I trust you have by now encoutered "The Greater Scroll of Console
> Knowledge":
>
> http://www.conserver.com/consoles/

No.  Getting the consoles to "work properly" hasn't been a priority
for me (the Classics will be retired in the next few months... they
are too big/noisey/expensive to serve as 'appliances').  But, I'll
chase down the URL just to see what it says...

> And also Celeste Stokely's Unix Serial Port Resources:
>
> http://www.stokely.com/unix.serial.port.resources/
>
> On the latter page you'll find a lind to Sun-specific details which
> mention that in at least some models of Sun systems there's a little
> jumper to select between them:
>
>    Port voltage:  Many Sun cpu serial ports can be configured as either
>    RS-232 (+/- 12V) or RS-423 (+/- 5V).  Defaults vary.  See the
>    hardware documentation for your machine to locate the jumper to
>    configure this, if it exists.  Most implementations do not have to
>    worry about the voltage on the serial port.

Yes, I had already sorted that out when I put the boxes into service
(and rewired the BBSRAMs to support external batteries... "Remember
the BBSRAMs?  This is a song about the BBSRAMs..."  :>)

> Of course in many environments the incorrect choice (i.e. 423) will lead
> to more unintended "BREAK" conditions being sensed.....
>
> (*) "RS-232 Simplified:  Everything you need to know about connecting
> and interfacing and troubleshooting peripheral devices", by Byron
> W. Putman, 1987, Prentice Hall, ISBN 0-13-783499-3.