[comp.unix.xenix.sco] ctsflow solution for xenix cu/uucico and fas question

klarich@d.cs.okstate.edu (KLARICH TERRY JAME) (06/26/91)

I have a solution to the ctsflow problem under sco xenix using uucico and cu.
I have been trying to make my mnp5 modem work properly in this environment for
several weeks.  Being as that I would like to keep the speed between the modem
and computer at 9600 baud, I need to have the ctsflow flag set so the computer
won't overrun the modem.  When dialing, my dialer will set the ctsflow flag
properly.  However, cu and uucico turn it back off when the dialer exits.  So,
this dialer forks a process from the clean_up function which waits until
ctsflow is turned off.  At this time, the forked process turns it back on and
exits.  Works fine.  If you would like the details, let me know and I'll email
you my changes to the original dialHA24 program.

I would rather use fas as my serial driver; but, I can't.  My needs require
that I use the parameter 'SYSTTY=SIO' in my /etc/default/boot file.  In the
documentation for fas, it says that fas and sio can't exist in the same
kermell.  Why is this?  Also, If someone using fas and xenix knows what would
happen if I install fas and try to use  com1 as the systty, please let me
know.  If fas and sio could be installed in the same kernell, this would solve
all my modem and console problems.

Thanks for any help

Terry Klarich
-- 
--------------------------------------------------------------------------------
Terry Klarich <klarich@d.cs.okstate.edu> n5hts

gemini@geminix.in-berlin.de (Uwe Doering) (06/28/91)

klarich@d.cs.okstate.edu (KLARICH TERRY JAME) writes:

>I would rather use fas as my serial driver; but, I can't.  My needs require
>that I use the parameter 'SYSTTY=SIO' in my /etc/default/boot file.  In the
>documentation for fas, it says that fas and sio can't exist in the same
>kermell.  Why is this?  Also, If someone using fas and xenix knows what would
>happen if I install fas and try to use  com1 as the systty, please let me
>know.  If fas and sio could be installed in the same kernell, this would solve
>all my modem and console problems.

The problem with sio is that it tries to be smart in that it looks at
several I/O addresses whether it can find a UART at that location, and
then tries to determine what type of card it is, and how many cards are
available. After sio decided that it found a card of a known type, it
attaches all UARTs on this card to itself, even if they belong to FAS.
The result of this conflict usually is that you can't boot with this
kernel. It will simply hang until you press the red button.

Until now, I don't know of any way to tell sio that it shouldn't do
that card guessing. So you either find a way to throw sio out, or
you can't use FAS. Sorry, but complain to SCO. Obviously, they
never thought of the possibility that there might be a second
serial dumb port driver in the kernel.

     Uwe
-- 
Uwe Doering  |  INET : gemini@geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini

chip@chinacat.unicom.com (Chip Rosenthal) (06/29/91)

In article <T60RHJQ@geminix.in-berlin.de>
	gemini@geminix.in-berlin.de (Uwe Doering) writes:
>The problem with sio is that it tries to be smart in that it looks at
>several I/O addresses whether it can find a UART at that location

That's all controlled by sioconf.c.  For example, I've had to comment
stuff out of it to keep the system from thinking it stumbled upon a
Quadram serial card when in fact it was an Ethernet card.  If you
comment out COM2 then sioinit() will never find it.

-- 
Chip Rosenthal  512-482-8260  |  Closed user interfaces for open systems?
Unicom Systems Development    |  No, thank you.
<chip@chinacat.Unicom.COM>    |  Boycott Lotus Development Corp.

stu@jpusa1.chi.il.us (Stu Heiss) (06/30/91)

I've been using fas with a trailblazer+ since 2.07 but just recently
got flow control set up (hopefully correctly).  Perhaps this will help
someone else and/or if this seems incorrect, I would apreciate email as
to why.  It does seem to work properly for me.  I have locked the trailblazer+
at 19200 and set rts and cts flow for full duplex by doing the following:
	s51=5	(interface speed 19200)
	s66=1	(lock interface, use flow control)
	s58=2	(use dte rts flow control)
	s68=2	(use dce cts flow control)
I also set noecho, dtr low disconect and reset, dcd assert on carrier true,
dsr toggle on lost carrier, instant break, autoreliable mnp.  To make
fas mimic xenix port minor convention, I changed the macro GET_OPEN_MODE.
With this setup, you can drop fas into xenix and use the standard devices.
Included below is an intialization script for the trailblazer+ and patch
to fas.c.  Disable the login on the modem port before running the script
and edit the 'dev=tty2a' if your telebit is on a different port.

Stu

#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
#	fas.c.diff
#	inittb.sh
# This archive created: Sat Jun 29 11:50:50 1991
# By:	stu (JPUSA - Chicago, IL)
export PATH; PATH=/bin:/usr/bin:$PATH
echo shar: "x - 'fas.c.diff'"
if test -f 'fas.c.diff'
then
	echo shar: "will not over-write existing file 'fas.c.diff'"
else
cat << \SHAR_EOFfas.c.diff > 'fas.c.diff'
===================================================================
RCS file: RCS/fas.c,v
retrieving revision 1.1
diff -u -r1.1 fas.c
--- 1.1	1991/06/25 16:36:44
+++ fas.c	1991/06/25 16:53:14
@@ -1,3 +1,14 @@
+#ifndef lint
+static char *RCSid = "$Header: /usr/sys/fas/src/RCS/fas.c,v 1.2 1991/06/25 16:50:58 stu Exp $";
+#endif
+
+/*
+ * $Log: fas.c,v $
+ * Revision 1.2  1991/06/25  16:50:58  stu
+ * swap dev minor bits 5 and 6 for xenix convention
+ *
+ */
+
 /* FAS Final Async Solution driver for 286/386 versions of system V UNIX */
 
 /* FAS was developed by
@@ -7,9 +18,11 @@
 Germany
 */
 
+#ifndef M_XENIX
 #if !defined (M_I286)
 #ident	"@(#)fas.c	2.09"
 #endif
+#endif
 
 /* Note: This source code was quite heavily optimized for speed. You
          may wonder that register variables aren't used everywhere.
@@ -350,7 +363,12 @@
 
 /* The following defines are used to take apart the minor device numbers. */
 #define GET_UNIT(dev)		((dev) & 0x0f)
+#ifndef M_XENIX
 #define GET_OPEN_MODE(dev)	(fas_open_modes [((dev) >> 4) & 0x0f])
+#else
+/* to swap bits 0101xxxx <=> 0000xxxx and 1101xxxx <=> 1000xxxx - ie. swap bits 5, 7 */
+#define GET_OPEN_MODE(dev)	(fas_open_modes [(((dev) >> 4) & 0x0f)^0x5])
+#endif
 
 /* lock device against concurrent use */
 #define get_device_lock(fip,prio) \
SHAR_EOFfas.c.diff
fi
echo shar: "x - 'inittb.sh'"
if test -f 'inittb.sh'
then
	echo shar: "will not over-write existing file 'inittb.sh'"
else
cat << \SHAR_EOFinittb.sh > 'inittb.sh'
:
# initialize telebit trailblazer+
# Fri Jun 28 16:33:30 CDT 1991
# use full duplex rts/cts flow with fas driver
PATH=/usr/lib/uucp:/bin:/usr/bin export PATH

xflg=-x9
dev=tty2a

# try 19200 and 9600 baud, recall factory default and lock baudrate at 19200
for br in 19200 9600;do
	uuchat $xflg $dev $br '' at OK 'at&f' OK ats51=5 OK
done

#       noecho          19200      lock/flow  rtsflow    ctsflow
#       dtrreset   dcddsr     instbreak  autorelmnp  writeconfig
uuchat $xflg $dev 19200 '' at OK \
	ate0 OK atq4 OK ats51=5 OK ats66=1 OK ats58=2 OK ats68=2 OK \
	ats52=2 OK ats53=4 OK ats54=2 OK ats95=2 OK 'at&w1' OK 'at&w2' OK

# dump registers
uuchat $xflg $dev 19200 '' at OK 'at&n' OK
SHAR_EOFinittb.sh
fi
exit 0
#	End of shell archive
-- 
Stu Heiss - stu@jpusa1.chi.il.us