Path: utzoo!mnetor!uunet!oddjob!hao!ames!sri-spam!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.dcom.modems
Subject: Re: Connecting a TrailBlazer to a Sun 3/280
Message-ID: <3249@cbmvax.UUCP>
Date: 2 Feb 88 05:35:22 GMT
References: <272@coherent.uucp>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Distribution: comp
Organization: Commodore Technology, West Chester, PA
Lines: 63
Keywords: Sun TrailBlazer BSD uucp flow control 19200

In article <272@coherent.uucp> dplatt@coherent.uucp (Dave Platt) writes:
> 
> Because we've set the modem's default configuration to "PEP mode only",
> we must arrange to re-enable automatic speed detection when we dial
> a V.22bis or 212 modem.  We do this by burying the appropriate S50
> command in the dialing sequence in the L.sys file;  it's an ugly hack,
> but it does work.  For example, one such sequence looks like:
> 
>    ibuki Any,9 ACUHAYES 19200 5551212;S50=0;d "" \d\r\c in:-""-ogin: foobar

Does this really work?  I tried using the semicolon after the number and
thought it dialed, answered and stayed the command mode, in other words
it was too late...

What worked for me was to user the L-dialcodes to hide the dirty stuff.
In my L.sys file have have ACU 19200 PEP5551212 .... and in the dialcodes
file (this is really gross)  PEP ^H^HS50=255S53=0DT

Note those ^H's are real live backspaces which are used to "erase" the
DT part of the ATDT the dialer code sends to the modem.  Works good
and keeps most of the scum out of the L.sys file.

WARNING: Ultrix UUCP translates ='s in the "phone" number to commas,
apparently as an attempt to provide a dialer independent "pause"
capability.  Easily patched, but kind of an obstacle for the innocent.

I've recently gotten Ultrix "shared modem" dial-in/out support to work
with the Trailblazer, on a DMF-32 no less!  The trick is to have the
default configuration have S53=2 so that the modem doesn't assert DSR
in command mode, which would make getty think that there is a call in
progress and refuse to give up the line.  The various +++ATHATZ stuff
the dialer code does is dialed "blind", since the interface is
hard-wired to ignore incoming data without carrier detect.  However in
the middle of the dialing sequence, the S53=0 switches to carrier and
DSR on so the dialer code can see the "CONNECT".

The remaining problem is that the modem doesn't seem real eager to
re-autobaud once it's decided on the transmission rate.  Dropping DTR
seems to make it more receptive, however when the modem is passed
from the "dial-in" mode in getty to "dial-out" mode in uucp, carrier
doesn't seem to get dropped.  Maybe I should try the "fixed interface
speed", but I thought standard hayes type autobauding seemed more
reasonable.  Maybe I'll try a biggie object patch to drop/raise DTR.

One might wonder why I'm messing with the built in "hayes" dialer code
in Ultrix instead of the "hayesq" or generic dialer support.  I guess
it's just a matter of building on what works...  I've tried hacking the
generic dialer support a couple of times and can't seem to get it to
do the same thing on two successive calls.  8-( 

BTW, anybody have any ideas on what's a good cheap interface to support
the Trailblazer on a Vax?  The DMF32 has a little baby FIFO that suggests
I don't want to share an interface with incoming 19200 baud lines with
users typing or laser printers with X-ON/X-OFF flow control.  I just
got a DHU11 to replace the old DZ clone for general dialup support, but
the defectoid thing has a screwed up architecture that limits output
data rate to 9600 bps.  I wonder if there's any legit way to enable the
"hardware" X-on/X-off support on the DMF32?

-- 
George Robbins - now working for,	uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)