Source Code 1992 March

home *** CD-ROM | disk | FTP | other *** search

/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 2 / 2656 < prev next >

Wrap

Internet Message Format | 1991-02-04 | 60.9 KB

From: gemini@geminix.in-berlin.de (Uwe Doering) Newsgroups: comp.unix.sysv386,comp.unix.xenix.sco,alt.sources Subject: FAS 2.08 async driver, part 1/4 Message-ID: <60TNCCE@geminix.in-berlin.de> Date: 3 Feb 91 22:16:01 GMT Submitted-by: gemini@geminix.in-berlin.de Archive-name: fas208/part01 Hello netlanders, here is the long awaited FAS 2.08 async driver for UNIX systems. ATTENTION: This release fixes two nasty bugs in FAS 2.07 that could lock up ports. Please pass a copy of this new release to everyone who uses FAS 2.07 and doesn't have access to the Netnews. Here is an excerpt from the README file: This is an async driver for 286/386 based unix systems that adds several features that are not supported by vendors drivers. It supports 1. the NS16550A and i82510 UART chips in full FIFO mode. 2. modem sharing for input and output. 3. shared interrupts. 4. multiplexed UART registers (HUB-6 card etc.). 5. full and half duplex hardware flow control. 6. VP/ix, the ISC DOS emulator. FAS was successfully tested under the following operating systems: Microport UNIX SYSV 3.0 ISC 386/ix 2.0.2 & 2.2 ESIX Rev. C & D Bell Tech/Intel UNIX 3.2 SCO UNIX 386 SCO XENIX 386 2.3.2 SCO XENIX 286 2.3.2 Enjoy! Uwe #!/bin/sh # This is fas208, a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 02/03/1991 20:57 UTC by gemini@geminix.in-berlin.de # Source directory /tmp/fas # # existing files will NOT be overwritten unless -c is specified # This format requires very little intelligence at unshar time. # "if test", "cat", "rm", "echo", "true", and "sed" may be needed. # # This is part 1 of a multipart archive # do not concatenate these parts, unpack them in order with /bin/sh # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 13596 -rw-r--r-- INSTALLATION # 1411 -rw-r--r-- Makefile.BELL # 1385 -rw-r--r-- Makefile.ESIX # 1394 -rw-r--r-- Makefile.ISC # 1406 -rw-r--r-- Makefile.SCO # 673 -rw-r--r-- Makefile.X286 # 581 -rw-r--r-- Makefile.X386 # 857 -rw-r--r-- Makefile.uPort # 26 -rw-r--r-- PATCHLEVEL # 31589 -rw-r--r-- README # 23278 -rw-r--r-- RELEASENOTES # 251 -rw-r--r-- config-ast4 # 255 -rw-r--r-- config-ast4c12 # 253 -rw-r--r-- config-c1-2 # 255 -rw-r--r-- config-c1-3 # 251 -rw-r--r-- config-hub6 # 76725 -rw-r--r-- fas.c # 20742 -rw-r--r-- fas.h # 136 -rw-r--r-- i_fas-ast4 # 204 -rw-r--r-- i_fas-ast4c12 # 68 -rw-r--r-- i_fas-c1-2 # 102 -rw-r--r-- i_fas-c1-3 # 204 -rw-r--r-- i_fas-hub6 # 136 -rw-r--r-- n_fas-ast4 # 204 -rw-r--r-- n_fas-ast4c12 # 68 -rw-r--r-- n_fas-c1-2 # 102 -rw-r--r-- n_fas-c1-3 # 204 -rw-r--r-- n_fas-hub6 # 26 -rw-r--r-- s_fas-ast4 # 78 -rw-r--r-- s_fas-ast4c12 # 52 -rw-r--r-- s_fas-c1-2 # 78 -rw-r--r-- s_fas-c1-3 # 26 -rw-r--r-- s_fas-hub6 # 6467 -rw-r--r-- space-ast4 # 6697 -rw-r--r-- space-ast4c12 # 6305 -rw-r--r-- space-c1-2 # 6420 -rw-r--r-- space-c1-3 # 6611 -rw-r--r-- space-hub6 # 174 -rwxr-xr-x update_desc # if test -r _shar_seq_.tmp; then echo 'Must unpack archives in sequence!' echo Please unpack part `cat _shar_seq_.tmp` next exit 1 fi # ============= INSTALLATION ============== if test -f 'INSTALLATION' -a X"$1" != X"-c"; then echo 'x - skipping INSTALLATION (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting INSTALLATION (Text)' sed 's/^X//' << 'SHAR_EOF' > 'INSTALLATION' && XInstallation guide for the FAS Final Async Solution driver X---------------------------------------------------------- X XTo install this driver you need the manual of your serial card, Xyour system manuals and a certain knowledge about what actually Xa serial driver is. X XYou have to be user root to compile and install the driver! X X XCompilation phase X================= X XFirst of all you should copy the makefile that matches your system Xto the file `Makefile'. Make sure that the makefile contains the Xproper compiler switches, paths and file names for your system. XYou may also look at `fas.c' and `fas.h' to find out what defines Xare possible for conditional compilation. In particular, if you Xdon't link in the original serial driver you might have to uncomment Xthe `NEED_PUT_GETCHAR' define in `fas.h'. You also may want to Xuncomment `HAVE_VPIX' in `fas.h' if you have VP/ix support in Xthe kernel. X XAfter that you choose one of the space-xxxxx configuration files Xthat matches your serial card and copy this to `space.c'. If you Xdon't find a matching space file you should copy the one that Xcomes closest to your card to `space.c'. X XIn any case you should check the entries in that file against your Xcard's manual and jumper settings. The space files contain explanations Xabout what data you have to enter. X XIf your `space.c' is filled in properly you simply type `make' to Xcompile the driver. If you don't get error messages you may begin Xwith the actual installation. Otherwise you have to find the cause of Xthe trouble. Some error reasons may be missing include files, macros Xthat are defined in different include files or missing at all, or you Xdon't use the standard UNIX 3.X/386 AT&T C compiler. Don't use any Xother compiler because this may break things. In particular, don't use Xthe GNU C compiler as it wants to link in some "helpful" routines that Xaren't in the kernel. X XFor SCO Xenix you have to use the Microsoft C compiler because Xenix Xdoesn't have the AT&T compiler. You will need the ANSI C version of Xthe Microsoft compiler because the preprocessor of the original XXenix distribution doesn't understand `#if defined(...)' statements Xin 386 mode. X X XInstallation phase X================== X XIf you want to have both the original asy (or sio) and the new FAS Xdriver in the kernel the only restriction is that ports and interrupt Xvectors can't be shared between the two drivers. Each driver controls Xits own separate set of ports and IRQs. X XuPort: Copy one of the config-xxxxx files to `config'. Check out X whether the interrupt vectors in this file reflect the X jumper settings on your serial card. Note that an IRQ2 on X your card is an interrupt vector of 9. All other IRQ numbers X correspond to the vector number, though. X X Next you have to tell the config program to include the new X driver at kernel link time. This is done by a line in the file X /etc/atconf/systems/system.std. Look for the line containing X `asy' followed by an asterisk (`*') and a comment. Create a X similar line where `asy' is substituted with `fas'. Add a X proper comment. If you don't want to use any ports under the X DOS emulator you should insert an asterisk at the beginning X of the line that contains the word `asy'. This excludes the X asy driver from the kernel. But if you want to have it in the X kernel you have to configure it to only use the ports you X need under DOS. The remaining ports should be controlled by X the FAS driver. X X Now type `make install' and after that you are ready to link X a new kernel. Refer to your system manuals on how to do that. X X Before you reboot the new kernel make sure that you create X the proper tty device nodes in /dev. But first you should X remove all device nodes belonging to the original asy driver X that you don't need any more. X X Now create your own tty device nodes that fit your needs. X The default device name prefix for the FAS driver is `ttyF'. X That is, ttyF00, ttyF01 ... and ttyFM00, ttyFM01 ... X You may choose another prefix, but note that some utilities X like uustat depend on tty-devices beginning with `tty'! X X The default value for the major device number is 4, and X sane values for the minor device numbers are 80 + device # X for the dialout node and 208 + device # for the dialin (getty) X node. Device # counts from 0 and reflects the actual port number. X Refer to the `README' file for a description of the possible minor X device numbers. X X Remember to change the inittab file to the new device names. X Other files that contain tty-names for some reason should be X updated, too (ttytype, Devices etc.). X X After you have booted the new kernel, provided your configuration X was correct, you should be able to use the serial devices. X X XISC: Copy one of the s_fas-xxxxx files to `s_fas'. Make sure X that you have a separate line in it for each block of contiguous X port addresses assigned to the same interrupt vector (check X the jumper settings on your serial card). Each line contains X the number of ports bound to that interrupt, the start and X end address of the first (lowest or only) port on this interrupt X line and other data. Refer to your ISC manuals if you need to X change this file. Note that an IRQ2 on your card is an interrupt X vector of 9. All other IRQ numbers correspond to the vector X number, though. X X Then you copy one of the n_fas-xxxxx files to `n_fas'. This X file contains data needed to automatically create tty device X nodes at installation time. Things you may want to change are X the tty node names and the minor device numbers (last field) for X these nodes. Make sure you have a node for every port on your X serial card in this file. X X Sane values for the minor device numbers are 80 + device # X for the dialout node and 208 + device # for the dialin (getty) X node. Device # counts from 0 and reflects the actual port number. X Refer to the `README' file for a description of the possible X minor device numbers. X X Now copy one of the i_fas-xxxxx files to `i_fas'. This file X contains the getty lines for the inittab file which is rebuild X every time a new kernel is installed. Make sure that you use the X same device names here as in the file `n_fas'. X X Next you have to modify the file /etc/conf/sdevice.d/asy in a way X that only those devices are enabled that you want to be controlled X by the original `asy' driver. This is done with an `N' in the second X column of the corresponding line to disable the port and a `Y' to X enable it. But usually you don't need the original driver any more. X Therefor, all lines in /etc/conf/sdevice.d/asy should be set to `N'. X X To tell the kernel config program how to link in the FAS driver X you have to add the following line to the file /etc/conf/cf.d/mdevice: X X fas Iocrwi iHct fas 0 4 1 16 -1 X X The 6th field contains the major device number of the driver. You X may change this if it collides with another driver. X X All this is in the ISC manuals. Read them carefully. X X Now type `make install' and after that you are ready to link X a new kernel. Refer to your system manuals on how to do that. X X You may have to change files that contain tty names to the new X device names (ttytype, Devices etc.). Take the names from `n_fas'. X X After you have booted the new kernel, provided your configuration X was correct, you should be able to use the serial devices. X X XESIX: Follow the description for ISC UNIX. X X XBELL: Follow the description for ISC UNIX. X X XSCO: Do the same steps as for ISC UNIX. Here are some additional X hints: X X The original SCO serial driver is called `sio' instead of X `asy'. You need to remove it because it won't coexist peacefully X with FAS. X X According to reports from some beta test sites it isn't enough X to disable the `sio' driver by setting all lines in X /etc/conf/sdevice.d/sio to `N'. Additionally, you have to X delete the `sio' entry in /etc/conf/cf.d/mdevice. X X In file `fas.h' you need to uncomment the `NEED_PUT_GETCHAR' X define before you compile the sources. X X For the device nodes you should use SCO's naming conventions because X there are some utilities that expect this tty name format. You need X to change the names in `i_fas' and `n_fas'. To prevent a collision X with the `sio' device node names you need to remove the file X `/etc/conf/node.d/sio'. X X You have to compile FAS with the AT&T standard C compiler (rcc, X don't use the Microsoft compiler !) and with the `-DSCO' X compiler command line flag. The makefile for SCO takes X care of this, though. X X After you made all the changes you need to run the X `configure' utility to get all the dependencies right. To convince X the configure program that it has work to do you should change some X parameter and put in the original value afterwards. Be prepared X that there may be more tinkering needed to remove `sio' completely X because there seem to be SCO UNIX releases where the kernel config X and build programs are broken (doesn't surprise me at all :-( ). X X XXENIX: The installation procedure for Xenix is completely different X from the other UNIX flavors. X X In file `fas.h' you need to uncomment the `NEED_PUT_GETCHAR' X define before you compile the sources. After compilation X the files `fas.o' and `space.o' have to be copied to the X directory `/usr/sys/io/fas'. X X As the `sio' driver won't coexist peacefully with FAS you have X to remove the `sio' line from the file `/usr/sys/conf/xenixconf'. X Create a new line for `fas' in this file. X X After this you have to modify the file `/usr/sys/conf/master'. X There is a line in it that looks like this: X X sio 4 0577 104 sio 0 0 5 1 7 3 4 33 34 X X You have to comment this out with an asterisk (`*') at the beginning X of the line. Directly after this line you need to insert a new line X with the following contents (for two ports, one on IRQ3 and one on X IRQ4): X X fas 2 0537 104 fas 0 0 5 1 7 3 4 0 0 X X The second column indicates how many interrupt vectors are used by X this driver (two vectors in this example). The last four columns X contain the corresponding IRQ numbers (in octal !). Unused vectors X are set to zero. X X Here is an example for three ports (on IRQ3, IRQ4 and IRQ5): X X fas 3 0537 104 fas 0 0 5 1 7 3 4 5 0 X X And this is for four ports (IRQ3, IRQ4, IRQ5 and IRQ2/9): X X fas 4 0537 104 fas 0 0 5 1 7 3 4 5 31 X X Note that the AT bus interrupts IRQ8 to IRQ15 are mapped to vector X 30 (octal) to 37 (octal). Therefor, IRQ9 (IRQ2 on the serial card) is X vector 31 (octal) in this example. X X Make sure that they match the interrupt vectors defined in `space.c'. X And take care that you don't use interrupt vectors that are already X assigned to other drivers. X X For further details refer to the master(F) man page. X X Now you have to insert the following line in `/usr/sys/conf/link_xenix' X (before the lines with the system libs): X X ../io/fas/fas.o ../io/fas/space.o \ X X After you made all the changes you might need to run the X `/usr/sys/conf/configure' utility to get all the dependencies right. X To convince the configure program that it has work to do you should X change some parameter and put in the original value afterwards. X X Go to the directory `/usr/sys/conf' and link the new kernel with X the `make' command. If all went well, copy the kernel to the X root directory. X X You need to create the FAS device nodes manually in the directory X `/dev' (with the command `mknod'). You should use SCO's naming X conventions because there are some utilities that expect this X tty name format. Here is an example how to make the device nodes: X X mknod tty1a c 5 80; mknod tty1A c 5 208 X mknod tty1b c 5 81; mknod tty1B c 5 209 X X Major device number is always `5' (that of the suspended `sio' X driver), the minor device numbers are calculated from the README file. X For full duplex hardware flow control tty1[a-z] gets the minor X device number 80 + device# (device# counted from 0) and tty1[A-Z] gets X 208 + device#. X X The last thing you have to do before you reboot your system is X to check whether you need to make changes to the files that contain X the device names for your original `sio' driver (for programs like X `getty', `cu' and `uucico'). X X After reboot you should remove all device nodes that belong X to the now suspended `sio' driver. X X XOther flavors of UNIX X===================== X XCheck out if one of the above installation schemes is similar to the Xone you need for your system. Make the appropriate changes and try Xout if it works. If your system is entirely different you have to Xfind out from your manuals how to install device drivers. But if Xyou use a UNIX SYSV/386 3.X you should get it to work eventually. X XGood luck. SHAR_EOF true || echo 'restore of INSTALLATION failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.BELL ============== if test -f 'Makefile.BELL' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.BELL (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.BELL (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.BELL' && X# Makefile for Bell Tech/Intel UNIX SYS V/386 X XSHELL = /bin/sh XINCLSYS = /usr/include/sys XLKDRVRDIR = /etc/conf/pack.d/fas XLKSCONFDIR = /etc/conf/sdevice.d XLKNCONFDIR = /etc/conf/node.d XLKICONFDIR = /etc/conf/init.d XLKKCONFDIR = /etc/conf/kconfig.d XDRVRNAME = Driver.o XCONFNAME = fas X XCC = cc XCFLAGS = -O -DINKERNEL X XOBJS = fas.o X Xfas.o: fas.c $(INCLSYS)/fas.h Makefile X Xinstall: fas.o space.c s_$(CONFNAME) n_$(CONFNAME) i_$(CONFNAME) X -mkdir $(LKDRVRDIR) 2> /dev/null X chmod 755 $(LKDRVRDIR) X cp fas.o $(LKDRVRDIR)/$(DRVRNAME) X chmod 644 $(LKDRVRDIR)/$(DRVRNAME) X cp space.c $(LKDRVRDIR)/space.c X chmod 644 $(LKDRVRDIR)/space.c X cp s_$(CONFNAME) $(LKSCONFDIR)/$(CONFNAME) X chmod 644 $(LKSCONFDIR)/$(CONFNAME) X cp n_$(CONFNAME) $(LKNCONFDIR)/$(CONFNAME) X chmod 644 $(LKNCONFDIR)/$(CONFNAME) X cp i_$(CONFNAME) $(LKICONFDIR)/$(CONFNAME) X chmod 644 $(LKICONFDIR)/$(CONFNAME) X $(SHELL) update_desc $(LKKCONFDIR)/description X Xspace.c: X @echo "You must copy the proper space-xxxxx file to \`space.c'" X @false X Xs_$(CONFNAME): X @echo "You must copy the proper s_$(CONFNAME)-xxxxx file to \`s_$(CONFNAME)'" X @false X Xn_$(CONFNAME): X @echo "You must copy the proper n_$(CONFNAME)-xxxxx file to \`n_$(CONFNAME)'" X @false X Xi_$(CONFNAME): X @echo "You must copy the proper i_$(CONFNAME)-xxxxx file to \`i_$(CONFNAME)'" X @false X X$(INCLSYS)/fas.h: fas.h X cp fas.h $(INCLSYS)/fas.h X Xclean: X rm -f fas.o X Xclobber: clean X SHAR_EOF true || echo 'restore of Makefile.BELL failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.ESIX ============== if test -f 'Makefile.ESIX' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.ESIX (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.ESIX (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.ESIX' && X# Makefile for ESIX X XSHELL = /bin/sh XINCLSYS = /usr/include/sys XLKDRVRDIR = /etc/conf/pack.d/fas XLKSCONFDIR = /etc/conf/sdevice.d XLKNCONFDIR = /etc/conf/node.d XLKICONFDIR = /etc/conf/init.d XLKKCONFDIR = /etc/conf/kconfig.d XDRVRNAME = Driver.o XCONFNAME = fas X XCC = cc XCFLAGS = -O -DINKERNEL X XOBJS = fas.o X Xfas.o: fas.c $(INCLSYS)/fas.h Makefile X Xinstall: fas.o space.c s_$(CONFNAME) n_$(CONFNAME) i_$(CONFNAME) X -mkdir $(LKDRVRDIR) 2> /dev/null X chmod 755 $(LKDRVRDIR) X cp fas.o $(LKDRVRDIR)/$(DRVRNAME) X chmod 644 $(LKDRVRDIR)/$(DRVRNAME) X cp space.c $(LKDRVRDIR)/space.c X chmod 644 $(LKDRVRDIR)/space.c X cp s_$(CONFNAME) $(LKSCONFDIR)/$(CONFNAME) X chmod 644 $(LKSCONFDIR)/$(CONFNAME) X cp n_$(CONFNAME) $(LKNCONFDIR)/$(CONFNAME) X chmod 644 $(LKNCONFDIR)/$(CONFNAME) X cp i_$(CONFNAME) $(LKICONFDIR)/$(CONFNAME) X chmod 644 $(LKICONFDIR)/$(CONFNAME) X $(SHELL) update_desc $(LKKCONFDIR)/description X Xspace.c: X @echo "You must copy the proper space-xxxxx file to \`space.c'" X @false X Xs_$(CONFNAME): X @echo "You must copy the proper s_$(CONFNAME)-xxxxx file to \`s_$(CONFNAME)'" X @false X Xn_$(CONFNAME): X @echo "You must copy the proper n_$(CONFNAME)-xxxxx file to \`n_$(CONFNAME)'" X @false X Xi_$(CONFNAME): X @echo "You must copy the proper i_$(CONFNAME)-xxxxx file to \`i_$(CONFNAME)'" X @false X X$(INCLSYS)/fas.h: fas.h X cp fas.h $(INCLSYS)/fas.h X Xclean: X rm -f fas.o X Xclobber: clean X SHAR_EOF true || echo 'restore of Makefile.ESIX failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.ISC ============== if test -f 'Makefile.ISC' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.ISC (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.ISC (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.ISC' && X# Makefile for ISC SYS V/386 X XSHELL = /bin/sh XINCLSYS = /usr/include/sys XLKDRVRDIR = /etc/conf/pack.d/fas XLKSCONFDIR = /etc/conf/sdevice.d XLKNCONFDIR = /etc/conf/node.d XLKICONFDIR = /etc/conf/init.d XLKKCONFDIR = /etc/conf/kconfig.d XDRVRNAME = Driver.o XCONFNAME = fas X XCC = cc XCFLAGS = -O -DINKERNEL X XOBJS = fas.o X Xfas.o: fas.c $(INCLSYS)/fas.h Makefile X Xinstall: fas.o space.c s_$(CONFNAME) n_$(CONFNAME) i_$(CONFNAME) X -mkdir $(LKDRVRDIR) 2> /dev/null X chmod 755 $(LKDRVRDIR) X cp fas.o $(LKDRVRDIR)/$(DRVRNAME) X chmod 644 $(LKDRVRDIR)/$(DRVRNAME) X cp space.c $(LKDRVRDIR)/space.c X chmod 644 $(LKDRVRDIR)/space.c X cp s_$(CONFNAME) $(LKSCONFDIR)/$(CONFNAME) X chmod 644 $(LKSCONFDIR)/$(CONFNAME) X cp n_$(CONFNAME) $(LKNCONFDIR)/$(CONFNAME) X chmod 644 $(LKNCONFDIR)/$(CONFNAME) X cp i_$(CONFNAME) $(LKICONFDIR)/$(CONFNAME) X chmod 644 $(LKICONFDIR)/$(CONFNAME) X $(SHELL) update_desc $(LKKCONFDIR)/description X Xspace.c: X @echo "You must copy the proper space-xxxxx file to \`space.c'" X @false X Xs_$(CONFNAME): X @echo "You must copy the proper s_$(CONFNAME)-xxxxx file to \`s_$(CONFNAME)'" X @false X Xn_$(CONFNAME): X @echo "You must copy the proper n_$(CONFNAME)-xxxxx file to \`n_$(CONFNAME)'" X @false X Xi_$(CONFNAME): X @echo "You must copy the proper i_$(CONFNAME)-xxxxx file to \`i_$(CONFNAME)'" X @false X X$(INCLSYS)/fas.h: fas.h X cp fas.h $(INCLSYS)/fas.h X Xclean: X rm -f fas.o X Xclobber: clean X SHAR_EOF true || echo 'restore of Makefile.ISC failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.SCO ============== if test -f 'Makefile.SCO' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.SCO (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.SCO (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.SCO' && X# Makefile for SCO UNIX SYS V/386 X XSHELL = /bin/sh XINCLSYS = /usr/include/sys XLKDRVRDIR = /etc/conf/pack.d/fas XLKSCONFDIR = /etc/conf/sdevice.d XLKNCONFDIR = /etc/conf/node.d XLKICONFDIR = /etc/conf/init.d XLKKCONFDIR = /etc/conf/kconfig.d XDRVRNAME = Driver.o XCONFNAME = fas X XCC = rcc XCFLAGS = -O -DINKERNEL -DSCO X XOBJS = fas.o X Xfas.o: fas.c $(INCLSYS)/fas.h Makefile X Xinstall: fas.o space.c s_$(CONFNAME) n_$(CONFNAME) i_$(CONFNAME) X -mkdir $(LKDRVRDIR) 2> /dev/null X chmod 755 $(LKDRVRDIR) X cp fas.o $(LKDRVRDIR)/$(DRVRNAME) X chmod 644 $(LKDRVRDIR)/$(DRVRNAME) X cp space.c $(LKDRVRDIR)/space.c X chmod 644 $(LKDRVRDIR)/space.c X cp s_$(CONFNAME) $(LKSCONFDIR)/$(CONFNAME) X chmod 644 $(LKSCONFDIR)/$(CONFNAME) X cp n_$(CONFNAME) $(LKNCONFDIR)/$(CONFNAME) X chmod 644 $(LKNCONFDIR)/$(CONFNAME) X cp i_$(CONFNAME) $(LKICONFDIR)/$(CONFNAME) X chmod 644 $(LKICONFDIR)/$(CONFNAME) X $(SHELL) update_desc $(LKKCONFDIR)/description X Xspace.c: X @echo "You must copy the proper space-xxxxx file to \`space.c'" X @false X Xs_$(CONFNAME): X @echo "You must copy the proper s_$(CONFNAME)-xxxxx file to \`s_$(CONFNAME)'" X @false X Xn_$(CONFNAME): X @echo "You must copy the proper n_$(CONFNAME)-xxxxx file to \`n_$(CONFNAME)'" X @false X Xi_$(CONFNAME): X @echo "You must copy the proper i_$(CONFNAME)-xxxxx file to \`i_$(CONFNAME)'" X @false X X$(INCLSYS)/fas.h: fas.h X cp fas.h $(INCLSYS)/fas.h X Xclean: X rm -f fas.o X Xclobber: clean X SHAR_EOF true || echo 'restore of Makefile.SCO failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.X286 ============== if test -f 'Makefile.X286' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.X286 (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.X286 (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.X286' && X# Makefile for SCO Xenix 286 X XSHELL = /bin/sh XLKDRVRDIR = /usr/sys/io/fas X XCC = cc XCFLAGS = -LARGE -O -K -M2em -DM_KERNEL -UM_I8086 -DSYSINFO -DXENIX XIOCFLAGS = -O -K -M2em -NT io_text -DM_KERNEL -UM_I8086 -DXENIX X XOBJS = fas.o space.o X Xall: $(OBJS) X Xfas.o: fas.c fas.h Makefile X $(CC) $(IOCFLAGS) -c fas.c X Xspace.o: space.c fas.h Makefile X $(CC) $(CFLAGS) -c space.c X Xinstall: all X -mkdir $(LKDRVRDIR) 2> /dev/null X chmod 755 $(LKDRVRDIR) X cp fas.o $(LKDRVRDIR) X chmod 644 $(LKDRVRDIR)/fas.o X cp space.o $(LKDRVRDIR) X chmod 644 $(LKDRVRDIR)/space.o X Xspace.c: X @echo "You must copy the proper space-xxxxx file to \`space.c'" X @false X Xclean: X rm -f $(OBJS) X Xclobber: clean X SHAR_EOF true || echo 'restore of Makefile.X286 failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.X386 ============== if test -f 'Makefile.X386' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.X386 (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.X386 (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.X386' && X# Makefile for SCO Xenix 386 X XSHELL = /bin/sh XLKDRVRDIR = /usr/sys/io/fas X XCC = cc XCFLAGS = -O -DXENIX -DM_KERNEL -M3e -Zp4 X XOBJS = fas.o space.o X Xall: $(OBJS) X Xfas.o: fas.c fas.h Makefile X $(CC) $(CFLAGS) -c fas.c X Xspace.o: space.c fas.h Makefile X $(CC) $(CFLAGS) -c space.c X Xinstall: all X -mkdir $(LKDRVRDIR) 2> /dev/null X chmod 755 $(LKDRVRDIR) X cp fas.o $(LKDRVRDIR) X chmod 644 $(LKDRVRDIR)/fas.o X cp space.o $(LKDRVRDIR) X chmod 644 $(LKDRVRDIR)/space.o X Xspace.c: X @echo "You must copy the proper space-xxxxx file to \`space.c'" X @false X Xclean: X rm -f $(OBJS) X Xclobber: clean X SHAR_EOF true || echo 'restore of Makefile.X386 failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.uPort ============== if test -f 'Makefile.uPort' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.uPort (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.uPort (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.uPort' && X# Makefile for uPort SYS V/386 X XSHELL = /bin/sh XINCLSYS = /usr/include/sys XLKDRVRDIR = /etc/atconf/modules/fas XLKCONFDIR = /etc/atconf/modules/fas XDRVRNAME = fas.o XCONFNAME = config X XCC = cc XCFLAGS = -O -DINKERNEL -DOPTIM X XOBJS = fas.o X Xfas.o: fas.c $(INCLSYS)/fas.h Makefile X Xinstall: fas.o space.c $(CONFNAME) X -mkdir $(LKDRVRDIR) 2> /dev/null X chmod 755 $(LKDRVRDIR) X cp fas.o $(LKDRVRDIR)/$(DRVRNAME) X chmod 644 $(LKDRVRDIR)/$(DRVRNAME) X cp space.c $(LKDRVRDIR)/space.c X chmod 644 $(LKDRVRDIR)/space.c X cp $(CONFNAME) $(LKCONFDIR)/$(CONFNAME) X chmod 644 $(LKCONFDIR)/$(CONFNAME) X Xspace.c: X @echo "You must copy the proper space-xxxxx file to \`space.c'" X @false X X$(CONFNAME): X @echo "You must copy the proper $(CONFNAME)-xxxxx file to \`$(CONFNAME)'" X @false X X$(INCLSYS)/fas.h: fas.h X cp fas.h $(INCLSYS)/fas.h X Xclean: X rm -f fas.o X Xclobber: clean X SHAR_EOF true || echo 'restore of Makefile.uPort failed' rm -f _shar_wnt_.tmp fi # ============= PATCHLEVEL ============== if test -f 'PATCHLEVEL' -a X"$1" != X"-c"; then echo 'x - skipping PATCHLEVEL (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting PATCHLEVEL (Text)' sed 's/^X//' << 'SHAR_EOF' > 'PATCHLEVEL' && Xrelease 2.08 patchlevel 0 SHAR_EOF true || echo 'restore of PATCHLEVEL failed' rm -f _shar_wnt_.tmp fi # ============= README ============== if test -f 'README' -a X"$1" != X"-c"; then echo 'x - skipping README (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting README (Text)' sed 's/^X//' << 'SHAR_EOF' > 'README' && XREADME file for the FAS Final Async Solution driver X--------------------------------------------------- X XWhat is this package: X X This is an async driver for 286/386 based unix systems that adds X several features that are not supported by vendors drivers. X It supports X X 1. the NS16550A and i82510 UART chips in full FIFO mode. X 2. modem sharing for input and output. X 3. shared interrupts. X 4. multiplexed UART registers (HUB-6 card etc.). X 5. full and half duplex hardware flow control. X 6. VP/ix, the ISC DOS emulator. X X X FAS was successfully tested under the following operating systems: X X Microport UNIX SYSV 3.0 X ISC 386/ix 2.0.2 & 2.2 X ESIX Rev. C & D X Bell Tech/Intel UNIX 3.2 X SCO UNIX 386 X SCO XENIX 386 2.3.2 X SCO XENIX 286 2.3.2 X X This driver should work with most of the UNIX SYS V/386 3.X ports X currently available. You can have both this and the original X vendor driver in the same kernel (if you really like to, but I X wouldn't know why). Each driver controls its own separate set of X serial ports. The only restriction here is that any int vector must X not be used by more than one of the drivers. The kernel config X program will complain otherwise. X X------------------------------------------------------------------------ X XHow it works: X X DIALIN/DIALOUT ON THE SAME PORT X ------------------------------- X X This driver supports shared line usage by having two logical X devices sharing one physical line. Each logical device has its X own name. For example for the first line the names are ttyF00 X (minor device 0) and ttyFM00 (minor device 192). The ttyF00 X is used for cu, kermit, and other programs that want to dial X out. It ignores the modem signals and just goes to it. The X ttyFM00 line is strictly for getty. When getty calls open on X ttyFM00 the driver hangs the open until the modem asserts the X carrier detect signal and then lets the open complete. If cu X opens ttyF00 while getty is waiting for the open to complete X the device is given to cu and the getty open must wait for cu X to finish and then will again wait for the carrier. If cu X tries to open the ttyF00 line while getty has ttyFM00 open cu X will get an error. If getty tries to open ttyFM00 while cu has X ttyF00 open the getty open will just hang and wait for cu to X close the line and then wait for the carrier. To put it simply X you should put up a getty on ttyFM00 with a -t 60 and use ttyF00 X for cu and uucico. X X In the example above ttyF00 had a minor device number of 0 and X ttyFM00 one of 192. But there are several other possible minor X device numbers for each port. X X The higher bits of the minor device number control the operating X mode of the device. The port can't be opened by two or more X different minor devices at the same time. X X Minor device numbers are built according to the following X description: X X Bitmap: m m f f x x x x X X `m m' are the mode bits as follows: X X 0 0 The carrier signal is totally ignored. With carrier high->low X *no* SIGHUP signal is generated. The device does *not* block X on open if there is no carrier. X 0 1 After an initial open, the carrier signal is ignored. X Although, carrier high->low generates a SIGHUP signal. From X thereon the device is carrier controlled until the last X process has closed the device. An ioctl call with a TCSETA* X command resets the device to ignore carrier again until the X next carrier high->low. The device does *not* block on open X if there is no carrier. X 1 0 The device is carrier controlled. It blocks on open if X there is no carrier. X 1 1 Same as mode `1 0', but a parallel non-blocking open X is possible while waiting for carrier. X X `f f' are the hardware flow control bits as follows: X X 0 0 The RTSFLOW/CTSFLOW termio(7) flags (if available) enable X half duplex hardware flow control (for output direction, X only) according to SCO's specifications. If these flags X are not available no hardware flow control is used by X this device. X 0 1 The device uses full duplex hardware flow control (for X input and output direction). X 1 0 The device uses half duplex hardware flow control (for X output direction, only). X 1 1 Same as mode `1 0', but additionally the output buffer X state is signaled to the connected device. X X Refer to the `space.c' file to determine which port X signals are actually used for that purpose. X X `x x x x' X This is the physical port number. This driver supports X up to 16 ports. If you need more, you should use an X intelligent serial card because more than 16 devices X will eat up to much CPU time with this dumb-port approach. X X - Note: If a device is carrier controlled, this implies the generation X of a SIGHUP signal with every carrier high->low. This is of X course only true if the CLOCAL flag is *not* set. X X On my own system I prefer a minor device number of `0101xxxx' X (80 + device #) for the non-blocking tty node and `1101xxxx' X (208 + device #) for the blocking tty node. This gives me X the SIGHUP signal on carrier loss and full duplex hardware X flow control with both logical devices. Dialout while a dialin X open is waiting for the carrier is also possible with this X setup. X X X HARDWARE FLOW CONTROL X --------------------- X X FAS supports both full and half duplex hardware flow control, using X the RS232C RTS/CTS control lines (by default). X X Full duplex flow control is a method to control character flow in X both input and output directions while in half duplex flow control X mode only the output direction is controlled. X X You can select between full and half duplex flow control via the X minor device number of the device. In full duplex mode the RTS line X controls the input direction and the CTS line is responsible for the X output direction. In half duplex mode RTS tells the connected device X whether there is data in the output buffer (optional), and the CTS X line has the same function as in full duplex mode. X X Full duplex mode: X X As long as the FAS input buffer hasn't reached a certain X threshold the RTS line is set high to signal the connected X device that it may send characters. If the input buffer level X rises beyond this threshold RTS will go low and the device X is supposed to stop sending characters. As soon as there is X sufficient space in the input buffer RTS will go high again X and the character flow may continue. X X The CTS line works the other way round. If the connected device X sets CTS to high the FAS character output is enabled. If CTS is X low, the output is stopped. There is a special feature for the X CTS part of the handshake. CTS is only looked at if the DSR X line is high. If DSR is low or not connected hardware output X handshake is disabled, that is, FAS sends characters X regardless of the state of CTS. X X This has two advantages. At first, if you switch off a serial X device connected to an FAS port with hardware flow control X CTS will go low and therefor the output gets blocked. If at X this time there are still characters in the output buffer the X last process closing this port can't terminate until the X buffer has drained. X X But as DSR will also go low if you switch off the device X this blocking of the output will be prevented. In short: X Hardware output handshake is only used if the connected X device sets DSR high, that is, the device is switched on X and is ready. So make sure that you keep this in mind when X you make serial cables and when you configure your serial X devices. DSR must be on if you want CTS handshake. X X The other advantage of this CTS/DSR mechanismn is that you X can still connect dumb serial devices to an FAS hardware X handshake port using a minimal 3-wire cable. As an unconnected X DSR line is automatically low hardware output handshake is X disabled, which is just what you wanted in this case. X X Half duplex mode: X X There are actually three half duplex modes selected by X the minor device number: X X First mode: X If the RTSFLOW termio(7) flag is set _and_ the CLOCAL X flag is _not_ set the RTS line is used to signal the X connected device that there is data in the output buffer. X As long as there is output data to come the RTS line stays X high. If the output buffer has drained RTS drops to low X until there is more data to be sent to the connected device. X X If the CTSFLOW termio(7) flag is set _and_ the CLOCAL X flag is _not_ set the CTS line used to control the output X character flow. This works as in full duplex mode. X X Second mode: X This mode overrides the RTSFLOW/CTSFLOW flags and works X as if the CTSFLOW flag is set permanently. The CLOCAL flag X doesn't affect this mode. X X Third mode: X This mode overrides the RTSFLOW/CTSFLOW flags and works X as if both the RTSFLOW and CTSFLOW flags are set permanently. X The CLOCAL flag doesn't affect this mode. X X X VP/ix SUPPORT X ------------- X X FAS allows DOS programs running under VP/ix to access serial X ports. You simply need to modify your personal VP/ix configuration X file (`vpix.cnf') to tell the DOS emulator which FAS devices to X use for COM1 (or COM1MOUSE) and COM2. Note that VP/ix opens X these devices at startup time, so you better make sure that X the desired devices aren't used by other processes when you X start VP/ix as VP/ix wants to use them exclusively. X X There are some special features with the handling of the RTS and X DTR lines you should know about. If your DOS program asserts X the DTR line this will actually cause action on the modem X enable line you configured in `space.c'. Likewise, RTS asserts X the half duplex hardware handshake line configured in `space.c'. X X If the used FAS device has full duplex hardware handshake enabled, X asserting RTS from DOS actually stops the character flow from FAS X to VP/ix. This prevents input buffers of interrupt driven DOS X programs from overflowing. FAS, on the other hand, uses its hardware X handshake to prevent an overflow of its own input buffer. Therefor, X you can use DOS telecommunication programs even at high baud rates X without losing characters, provided your DOS programs are X configured to use full duplex RTS/CTS flow control. X X All this virtual handling has the advantage that the DOS program X doesn't need to know certain details about your actual port setup. X Reading the modem status register, on the other hand, doesn't cause X any translation of the register value. X X To enable VP/ix support, you have to uncomment the `HAVE_VPIX' X define in `fas.h'. X X X WHICH SERIAL CARDS ARE SUPPORTED ? X ---------------------------------- X X The driver supports and has been tested on many serial async X dumb port cards. It supports most combinations of shared X interrupts. The current driver supports NS16450, NS16550A, X um82450 and i82510. 8250 chips are not supported due to various X bugs and speed problems in these parts. They have no place in any X 286/386 or other high performance system. Replace them with one of X the supported chips. They are pin-to-pin compatible. X X ATTENTION: Don't use NS16550 (without the trailing `A') or X WD16550 chips! They are buggy and won't work with X FAS. Some aren't even recognized by the FIFO auto- X detect code in FAS. Therefor, even if they are X cheaper, don't buy them. X X Take a look at the various samples of space-xxxx for details X of how to set up for various devices. X X At boot time you will see a status message on the screen with X symbols that show the init state of each port. The symbols X are as follows: X X - not defined in the fas_port array X > int vector greater than limit X ? can't initialize port X 1-6 error during test phase indicated by number X * port is initialized (NS16450) X + port is initialized and has FIFOs forced off X f port is initialized and has FIFOs (i82510) X F port is initialized and has FIFOs (NS16550A) X X This is convenient to check whether you have entered the proper port X base addresses in `space.c'. X X X WHICH CARD WILL SUPPORT SHARED INTERRUPTS ? X ------------------------------------------- X X Many multi-port cards have jumpers or dip switches that let you X assign more than one port to the same interrupt (IRQ) line. This alone X is _no_ guaranty that they really support shared interrupts! These X cards may be designed for the DOS world where you may want two or more X serial ports but don't need to run them concurrently, that is, no more X than one of those ports assigned to the same IRQ line is allowed to be X in use at a time. For DOS this is sufficient as DOS is no multitasking X operating system. For UNIX this won't work because in the worst case X all serial ports may be in use at the same time. X X The basic problem is that the PC (and AT) I/O bus can't handle shared X interrupts itself. This is due to a brain-dead hardware design. Therefor, X there must be some special logic on the serial card to provide shared X interrupts. And those cards are quite rare (and usually more expensive). X X Therefor, you have the choice to give every port on the card its own X IRQ line or to buy a multi-port card that really has shared interrupts. X But in the latter case you better ask your vendor twice to make shure X that it has this functionality because from the card's manuals it often X isn't obvious which type of card it is. One well-known shared interrupts X card is the AST 4-port card. There are many compatible clones available X that are usually much cheaper than the original. You can even buy X AST compatible 8-port cards where two AST 4-port blocks are on the X same board. X X X CABLING X ------- X X Don't leave unused input lines (CTS, DCD, DSR, RING) open! Due X to crosstalking from other lines these input lines might change X their logic level rapidly, resulting in excessive modem status X interrupts that could bring your machine down to its knees. X Therefor, you should connect any unused input line to GND (pin 7 X on the D-Sub 25 RS232C connector). X X To prevent the machine from locking up in a case like described X above the port causing the modem status interrupts will be shut X down for 30 seconds after the last close on that port. Any attempt X to use an open(), read(), write() or ioctl() call to this port X during the time until the last close and then 30 seconds from X there will result in an ENXIO error. X X The port shutdown will be indicated on the system console by a X warning message containing the unit number of the offending port. X X But even if this protection mechanismn isn't triggered on your X computer you might have this problem. This is usually indicated X by a bad system performance during high speed serial data transfers. X Use your system's performance measurement tools to check the X number of modem interrupts. If it is unusual high, or even X higher than the number of transmit/receive interrupts, you X certainly have a problem with your cabling. Of course, another X reason could be a bad UART chip. X X ATTENTION: If you want to connect two UNIX systems (both using X FAS) via a null modem cable, and if you want to run a getty X on both ends you need to modify the `space.c' file to prevent X both gettys talking to each other, wasting valuable CPU time. X Remove the `EI_DTR' (or `EI_RTS', depending on your setup) macro X for the desired port from the initializer part of the `fas_modem' X array. This will cause DTR (or RTS) to be asserted only on X dialout. Therefor, the getty at the other end will become alive X only if a dialout is in progress. X X Another caveat is connecting a mouse or other pointer device to an X FAS port. There are many mice on the market that don't handle the X modem and flow control lines in a proper way. Therefor, they should X be connected to a port with a minor device number of 0 + device #. X This disables any modem or flow control and prevents the device from X locking up under certain circumstances. X X X A WORD ABOUT CHARACTER LOSSES X ----------------------------- X X If you've experienced character losses with your vendor async X driver at high baud rates you shouldn't blame the vendor for X that. The real reason for this problem lies in the ancient port X devices used in most 286/386 systems: The 8250 (not supported by X FAS) and the NS16450. X X They have only one receiver character buffer. This implies that X the operating system must read a character from this buffer before X the next one arrives from the port's shift register. For the old X IBM PC with DOS this was sufficient. But for UNIX and with baud X rates up to 38400 this is simply a joke. X X UNIX is not a real-time operating system. That means that it's X kernel isn't optimized for fast interrupt responses. With the X proper hardware this is no problem. But because the vendors have X to adapt UNIX to the standard hardware found in 286/386 systems they X also have to cope with the NS16450 ports which are in there simply X to be compatible with IBM PCs, XTs and ATs. X X It is impossible to make it work at high baud rates without a X major redesign of the AT&T supplied UNIX kernel. But then it X wouldn't be UNIX SYSV any more. X X Luckily, there is a pin-to-pin replacement available from X National Semiconductors: The NS16550A. X X This device has separate 16 character FIFOs for the receiver and X the transmitter. With these FIFOs the interrupt latency of the X kernel can be quiet high without losing any characters. X Additionally, because with most interrupts many characters are X processed at once the system is loaded much less. X X As you see, the necessary hardware is available. Therefor, if you X have to blame the UNIX vendor then blame him for not telling you X that you should buy some NS16550A and/or for not supplying you X with a serial driver that supports these port devices. X X But as you have the FAS driver now and if you use the NS16550A X devices you shouldn't have this kind of trouble any more. This is X the philosophy behind the driver's name `Final Async Solution'. X X Enjoy! X X PS: If for some reason you can't get the NS16550A chips you X could use the i82510 chips from Intel. Although they are X much less efficient they are still better than the NS16450. X X PPS: Some kernel functions may disable interrupts long enough X that even the input FIFO can't prevent character loss. X One culprit is the disk cache flush function. If you X configure your kernel with too many cache buffers (NBUF X parameter for AT&T derived UNIX) you may still lose X characters (at least at 38400 bps). X X Another candidate is VP/ix, or rather the kernel functions X to support VP/ix. This may also lead to lost characters X at very high input speed. X X And there are some bus mastering disk controllers (like the X Adaptec 1540/1542 SCSI controller) on the market that slow X down the CPU so much during data transfer that it isn't fast X enough to process characters coming in at high baud rates. X Therefor, if you can configure your disk controller, don't X use values that will bring the CPU down to its knees. X Otherwise, FAS will lose input characters during disk I/O. X X X DEVICE LOCKUPS X -------------- X X There are certain conditions under which a device can lock up, X that is, at least one process that uses this device waits for X a tty I/O related event that obviously doesn't occure. X X The most common case is that there are still characters in the X output buffer, but the output is disabled for some reason. Then X the last process that closes the tty device hangs in the close() X function until the output buffer has drained. X X Tty output may be stopped by the software (XON/XOFF) or hardware X (RTS/CTS, by default) flow control. In this case something X seems to be wrong with the cabling or the connected device. X Please check this first out before you blame FAS. Sometimes X it helps to switch the device off and on a few times to unblock X the tty output. X X Another reason could be a lost transmitter interrupt. If this isn't X caused by a configuration error this usually indicates a hardware X problem in your computer which should be fixed as soon as possible. X Otherwise, you can't run this system unattended because it is too X unreliable. X X In the cases described above the last resort is entering `kill -9 <pid>' X once or twice. This should unblock and terminate the hanging process. X X If interrupts are lost on IRQ2 this might have to do with an EGA or X VGA card using this IRQ line for the vertical retrace interrupt. X This interrupt isn't used at all these days, neither under DOS nor X UNIX. It's simply there for compatibility. X X On some video cards (the more expensive ones) there is a jumper or X dip switch to disable the vertical retrace interrupt. On the rest X you have to cut the trace to the bus contact B4 with a sharp knife. X This contact is on the solder side of the video card, the fourth bus X contact counted from the side where the 9 or 15 pin D-SUB connector X to the monitor is located. Cutting this trace has the same effect as X pulling the IRQ2 jumper on other cards. Note that cutting the trace X will void your video card's warranty. X X Now IRQ2 should be available for use with FAS. Look at the INSTALLATION X file for details on how to configure FAS for IRQ2. This is operating X system dependent. X X And there is a rare case which has to do with the number of available X CLISTs in the UNIX kernel. The UNIX output and input buffers are X 256 bytes each (by default). If for some reason the output of a X tty device is stopped but a process continues to send data one X character at a time this uses up one CLIST for every charcacter. X If the number of CLISTs in the kernel is less than 256 all CLISTs X will be busy eventually. X X The dangerous part here is that the pool of CLISTs is used by all X tty devices. Therefor, if one single tty device manages to eat up X all available CLISTs all tty in- and output comes to a halt. If this X happens you can't access your machine any more, not even from the X operator console. Although, the system is still alive internally. X X Unfortunately, many UNIX vendors have put a dangerously low number-of- X CLISTs parameter into their kernel tune files. You should increase X it to a value that makes it impossible that one device alone can X occupy all CLISTs (it's the NCLIST parameter under AT&T derived X UNIX SysVr3.x). A value of 400 should be sufficient. X X X COPYRIGHT X --------- X X Although FAS is frequently refered to as a public domain driver, X FAS was never released to the public domain (this is true for X all releases of FAS). FAS is freeware, and the author has the X full copyright. X X Here are the conditions under which you may copy and distribute X FAS. The goal of these terms is to spread FAS as wide as possible X and, on the other hand, to prevent anyone from making money out X of it, and to prevent any restrictions of the availability of X FAS. X X 1. You can freely copy FAS, and you may give copies of FAS to X everyone. X 2. FAS has to be distributed as the complete package posted X to Usenet by its author. X 3. Vendors may bundle FAS with their products as long as they X a) tell their customers (somewhere in the written documentation) X that FAS is freeware, wasn't developed by the vendor, and the X vendor doesn't have the copyright for FAS. X b) provide the complete original package in addition to their X customized version. Customization means modification of X the configuration files. No changes to the actual source X file (fas.c) are allowed. X c) tell their customers (somewhere in the written documentation) X where the original package is located on the distribution X media. X 4. Changes to the sources are allowed X a) for private use. X b) to develop another freeware package with similar restrictions. X This new package has to have a different name. X 5. The author isn't liable for any damage or loss of data caused X by FAS. X X------------------------------------------------------------------------ X XWhat's in this package: X X README This file. X X INSTALLATION A description about how to install the driver X on your system. X X PATCHLEVEL Just a reference file for future updates. X X RELEASENOTES Notes about the present FAS releases. X X fas.h The header file for the driver. X X fas.c The driver itself. X X space-xxxxx These are samples of what `space.c' must look X like. You can either copy one of these to X `space.c' or use it as a template to create your X own `space.c'. X X space-c1-2 For com1 and com2. X X space-c1-3 For com1, com2 and com3. X X space-ast4 For the AST 4-port card. X X space-ast4c12 For the AST 4-port card plus com1 and com2. X X space-hub6 For the Bell Tech HUB-6 card. X X config-xxxxx This is for uPort SYS V/386 only. X Kernel configuaration file. You should pick the one X that matches your configuration and copy it to `config'. X X config-c1-2 For com1 and com2. X X config-c1-3 For com1, com2 and com3. X X config-ast4 For the AST 4-port card. X X config-ast4c12 For the AST 4-port card plus com1 and com2. X X config-hub6 For the Bell Tech HUB-6 card. X X s_fas-xxxxx This is for ISC 386/ix, ESIX, Bell Tech/Intel UNIX 3.2 X and SCO UNIX 386. X Kernel configuration file. You should pick the one X that matches your configuration and copy it to `s_fas'. X X s_fas-c1-2 For com1 and com2. X X s_fas-c1-3 For com1, com2 and com3. X X s_fas-ast4 For the AST 4-port card. X X s_fas-ast4c12 For the AST 4-port card plus com1 and com2. X X s_fas-hub6 For the Bell Tech HUB-6 card. X X n_fas-xxxxx This is for ISC 386/ix, ESIX, Bell Tech/Intel UNIX 3.2 X and SCO UNIX 386. X Tty device nodes file. You should pick the one X that matches your configuration and copy it to `n_fas'. X X n_fas-c1-2 For com1 and com2. X X n_fas-c1-3 For com1, com2 and com3. X X n_fas-ast4 For the AST 4-port card. X X n_fas-ast4c12 For the AST 4-port card plus com1 and com2. X X n_fas-hub6 For the Bell Tech HUB-6 card. X X i_fas-xxxxx This is for ISC 386/ix, ESIX, Bell Tech/Intel UNIX 3.2 X and SCO UNIX 386. X Inittab getty lines file. You should pick the one X that matches your configuration and copy it to `i_fas'. X X i_fas-c1-2 For com1 and com2. X X i_fas-c1-3 For com1, com2 and com3. X X i_fas-ast4 For the AST 4-port card. X X i_fas-ast4c12 For the AST 4-port card plus com1 and com2. X X i_fas-hub6 For the Bell Tech HUB-6 card. X X Makefile.uPort A makefile for uPort SYS V/386 systems. This is generic X and should work for all configurations of lines X and interrupts. X X Makefile.ISC A makefile for ISC 386/ix systems. This is generic X and should work for all configurations of lines X and interrupts. X X Makefile.ESIX A makefile for ESIX systems. This is generic X and should work for all configurations of lines X and interrupts. X X Makefile.BELL A makefile for Bell Tech/Intel UNIX 3.2 systems. This X is generic and should work for all configurations of X lines and interrupts. X X Makefile.SCO A makefile for SCO UNIX 386 systems. This is generic X and should work for all configurations of lines X and interrupts. X X Makefile.X386 A makefile for SCO Xenix 386 systems. This is generic X and should work for all configurations of lines X and interrupts. X X Makefile.X286 A makefile for SCO Xenix 286 systems. This is generic X and should work for all configurations of lines X and interrupts. X X------------------------------------------------------------------------ X XWhat you will need to use this package: X X You will need one of the above mentioned UNIX systems with the X kernel link kit and the software development package. X X------------------------------------------------------------------------ X XThe original asy replacement driver for Microport UNIX/386 (FAS' predecessor) Xwas developed by X XJim Murray INET jjm%jjmhome@m2c.m2c.org X2 Mohawk Circle UUCP harvard!m2c!jjmhome!jjm XWestboro Mass 01581 XUSA voice (508) 366-2813 X XCredits to him for releasing this great driver to the Usenet community. XBut if you have problems with FAS please don't contact him because he Xwasn't involved in the developement of FAS. X XFAS was developed by X XUwe Doering INET : gemini@geminix.in-berlin.de XBillstedter Pfad 17 b UUCP : ...!unido!fub!geminix.in-berlin.de!gemini X1000 Berlin 20 XGermany X X ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ XSend your questions and bug reports to this address. SHAR_EOF true || echo 'restore of README failed' rm -f _shar_wnt_.tmp fi # ============= RELEASENOTES ============== if test -f 'RELEASENOTES' -a X"$1" != X"-c"; then echo 'x - skipping RELEASENOTES (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting RELEASENOTES (Text)' sed 's/^X//' << 'SHAR_EOF' > 'RELEASENOTES' && X release 1.1a Sat Nov 11, 1989 X X This is an unofficial release as I'm not the original author X of this async driver. X X Uwe Doering INET : gemini@geminix.in-berlin.de X Billstedter Pfad 17 b UUCP : ...!unido!fub!geminix.in-berlin.de!gemini X 1000 Berlin 20 X Germany X X New Features: X X Added a third minor tty device number for every physical SHAR_EOF true || echo 'restore of RELEASENOTES failed' fi echo 'End of fas208 part 1' echo 'File RELEASENOTES is continued in part 2' echo 2 > _shar_seq_.tmp exit 0 -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini