Source Code 1994 March

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

/ Source Code 1994 March / Source_Code_CD-ROM_Walnut_Creek_March_1994.iso / compsrcs / misc / volume32 / ecu / part31 < prev next >

Wrap

Text File | 1992-09-13 | 57.0 KB | 1,355 lines

Newsgroups: comp.sources.misc From: wht@n4hgf.Mt-Park.GA.US (Warren Tucker) Subject: v32i066: ecu - ECU Asynchronous Communications v3.20, Part31/40 Message-ID: <1992Sep14.145112.22535@sparky.imd.sterling.com> X-Md4-Signature: 599cd78cb690e2022337adb7557a5a71 Date: Mon, 14 Sep 1992 14:51:12 GMT Approved: kent@sparky.imd.sterling.com Submitted-by: wht@n4hgf.Mt-Park.GA.US (Warren Tucker) Posting-number: Volume 32, Issue 66 Archive-name: ecu/part31 Environment: SCO,XENIX,ISC,SUNOS,SYSVR4,HDB,Curses Supersedes: ecu: Volume 21, Issue 53-89 ---- Cut Here and feed the following to sh ---- #!/bin/sh # this is ecu320.31 (part 31 of ecu320) # do not concatenate these parts, unpack them in order with /bin/sh # file fasi/Makefile continued # if test ! -r _shar_seq_.tmp; then echo 'Please unpack part 1 first!' exit 1 fi (read Scheck if test "$Scheck" != 31; then echo Please unpack part "$Scheck" next! exit 1 else exit 0 fi ) < _shar_seq_.tmp || exit 1 if test ! -f _shar_wnt_.tmp; then echo 'x - still skipping fasi/Makefile' else echo 'x - continuing file fasi/Makefile' sed 's/^X//' << 'SHAR_EOF' >> 'fasi/Makefile' && X -mkdir $(INCLLOC) >/dev/null 2>&1 X cp digi-pc8.h $(INCLLOC)/digi-pc8.h X Xclean: X rm -f fas.o Driver.o X Xclobber: clean X SHAR_EOF echo 'File fasi/Makefile is complete' && chmod 0644 fasi/Makefile || echo 'restore of fasi/Makefile failed' Wc_c="`wc -c < 'fasi/Makefile'`" test 1378 -eq "$Wc_c" || echo 'fasi/Makefile: original size 1378, current size' "$Wc_c" rm -f _shar_wnt_.tmp fi # ============= fasi/Master ============== if test -f 'fasi/Master' -a X"$1" != X"-c"; then echo 'x - skipping fasi/Master (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting fasi/Master (Text)' sed 's/^X//' << 'SHAR_EOF' > 'fasi/Master' && Xfas Iocrwi iHct fas 0 0 1 16 -1 SHAR_EOF chmod 0644 fasi/Master || echo 'restore of fasi/Master failed' Wc_c="`wc -c < 'fasi/Master'`" test 32 -eq "$Wc_c" || echo 'fasi/Master: original size 32, current size' "$Wc_c" rm -f _shar_wnt_.tmp fi # ============= fasi/Node ============== if test -f 'fasi/Node' -a X"$1" != X"-c"; then echo 'x - skipping fasi/Node (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting fasi/Node (Text)' sed 's/^X//' << 'SHAR_EOF' > 'fasi/Node' && Xfas tty1a c 80 Xfas tty1A c 208 Xfas tty2a c 81 Xfas tty2b c 82 Xfas tty2c c 83 Xfas tty2d c 84 Xfas tty2e c 85 Xfas tty2f c 86 Xfas tty2g c 87 Xfas tty2h c 88 Xfas tty2A c 209 Xfas tty2B c 210 Xfas tty2C c 211 Xfas tty2D c 212 Xfas tty2E c 213 Xfas tty2F c 214 Xfas tty2G c 215 Xfas tty2H c 216 SHAR_EOF chmod 0644 fasi/Node || echo 'restore of fasi/Node failed' Wc_c="`wc -c < 'fasi/Node'`" test 279 -eq "$Wc_c" || echo 'fasi/Node: original size 279, current size' "$Wc_c" rm -f _shar_wnt_.tmp fi # ============= fasi/PATCHLEVEL ============== if test -f 'fasi/PATCHLEVEL' -a X"$1" != X"-c"; then echo 'x - skipping fasi/PATCHLEVEL (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting fasi/PATCHLEVEL (Text)' sed 's/^X//' << 'SHAR_EOF' > 'fasi/PATCHLEVEL' && Xrelease 2.08 patchlevel b2 fasi x1.03 SHAR_EOF chmod 0644 fasi/PATCHLEVEL || echo 'restore of fasi/PATCHLEVEL failed' Wc_c="`wc -c < 'fasi/PATCHLEVEL'`" test 38 -eq "$Wc_c" || echo 'fasi/PATCHLEVEL: original size 38, current size' "$Wc_c" rm -f _shar_wnt_.tmp fi # ============= fasi/README ============== if test -f 'fasi/README' -a X"$1" != X"-c"; then echo 'x - skipping fasi/README (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting fasi/README (Text)' sed 's/^X//' << 'SHAR_EOF' > 'fasi/README' && XThis is the original README from FAS 2.08 for reference only. XRead README.FASI. DO NOT CONTACT UWE DOERING REGARDING THIS HACKED VERSION X ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ X 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 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 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 (NS16550) 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 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 An other 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 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 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 port 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 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 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. This usually X indicates a hardware problem in your computer which should be fixed X as soon as possible. Otherwise, you can't run this system unattended X because it is too 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 And there is a rare case which has to do with the number of available X CLISTs in the UNIX kernel. The CLIST 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 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-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-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-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-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-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 [BUT DON'T BOTHER HIM ABOUT FAS/i] 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------------------------------------------------------------------------------ XFor FAS/i inquiries: X Warren Tucker wht@n4hgf.GA.US, emory!n4hgf!wht X X ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ XSend your questions and bug reports to this address. SHAR_EOF chmod 0644 fasi/README || echo 'restore of fasi/README failed' Wc_c="`wc -c < 'fasi/README'`" test 27697 -eq "$Wc_c" || echo 'fasi/README: original size 27697, current size' "$Wc_c" rm -f _shar_wnt_.tmp fi # ============= fasi/README.FASI ============== if test -f 'fasi/README.FASI' -a X"$1" != X"-c"; then echo 'x - skipping fasi/README.FASI (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting fasi/README.FASI (Text)' sed 's/^X//' << 'SHAR_EOF' > 'fasi/README.FASI' && XFAS/i is a special-purpose, unsupported version of FAS 2.08 for Xthose who need to have non-portable, but extended access to their tty driver. X XReasons to use: X X1. You get cumulative statistics on such things as receievd and Xtransmitted characters, modem signals and device errors. As an Xexample of the information available, the ecu interactive 'fasi' Xcommand produces: X Xbase address: 0218 irq=3 device is 16550 XMSR=*CTS*DSR* MCR=*DTR*RTS*OUT2* XLCR=*8db*1sb*NOPAR* IER=*RDAV*TBMT*LS*MS* Xrecv ring cnt=0 xmit ring cnt=0 xmit fifo size=16 Xcharacters received = 3097 Xcharacters transmitted = 22407 Xmodem status events = 137 Xoverrun errors=0 framing errors=0 parity errors=0 Xrings detected=0 breaks detected=0 Xxmtr flow off XON/XOFF=0 RTS/CTS=31 Xrcvr flow off XON/XOFF=0 RTS/CTS=0 Xdriver: 'FAS/i 2.08.0' Xspace.c: 'FAS/i 2.08:{1,4,03f8-03ff,COM1},{8,3,0210-024f,DIGI-PC8}' X X2. There are no other reasons to use. X XReasons NOT to use: X X1. It is not supported. It is released configured for one COM1 (irq 4) Xand one 8-port Digiboard PC-8. I will help with any issue that I can, Xbut I will be very uninterested in answering questions like "How do I Xget FAS/i to work with my PacificRim ModemBlaster 4800?" X X2. It is less efficient than FAS. Statistics take CPU cycles to accumulate. XAlso, Uwe has done an indescribably superb job of optimizing the driver Xfor efficiency. I have not analyzed the effect my changes have made to Xthe micromanagment of emitted code Uwe did, but it cannot have but harmed. X X3. The driver is non-standard. It barks in the face of most of Xwhat I look for in well-produced software. X X4. Uwe will continue to work magic and this driver is unlikely to Xinherit it. X X5. FAS nor FAS/i appear to support DOS access to communications Xdevices through MERGE. X XNow, you say, why does that Tucker kid want to turn my tty driver Xinto a newt ("Well, [it] got better.")? Because it can be very useful Xif you are developing asychronous communications systems. I find Xit very useful to know how many times CTS fluctuated during a test Xsession. Like the 'ecufriend,' it isn't for everyone, but if you Xneed it, there it is. X X>Message-Id: <m0jXaOF-0000ElC@geminix.in-berlin.de> X>From: emory!geminix.in-berlin.de!gemini (Uwe Doering) X>Subject: Re: [Request permission to distribute FAS 2.08 instrumented version] X>To: wht@n4hgf.Mt-Park.GA.US (Warren Tucker) X>Date: Mon, 29 Apr 91 17:43:51 MES X> X>Hello Warren, X> X>>...I am writing is to ask your permission ... X>>to include with ecu a modified FAS 2.08 I am calling FAS/i (for X>>instrumentation) so you can have access to statistics X>> [some stuff deleted] X> X>You sent me the necessary patches some time ago. Since then I tried to X>make up my mind about this issue. I decided now that I won't have the X>patches in the official FAS release. There is a reason for that. I want X>to keep FAS as clean as possible from the application program standpoint. X> X[some stuff deleted] X> X>You have my permission to release your special FAS version, but please X>make it clear in the docs that _you_ do the support for it, and X>that it is no official FAS release. X> X> Uwe X>-- X>Uwe Doering | INET : gemini@geminix.in-berlin.de X>Berlin |---------------------------------------------------------------- X>Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini X XThe strength of my earlier comments is driven in part by Uwe's comments. XI will be very disasppointed and red-faced if Uwe gets ONE query or Xrequest in regard to this hack. I will be similarly dismayed if he Xgets one comment pro or con about folding these features into the Xofficial FAS. X XThis is a dead-end, special-purpose junkbox addition that just happens Xto be potentially useful. X XNow, with all that out of the way, here are a few useful tidbits: X X1. Configuration and installation are for the most part similar to Xthe standard FAS as of this writing. X X2. You will need to manually create a /usr/include/local directory Xbefore you begin any makes. X X3. The original FAS 2.08 functionality may be restored by turning Xoff #define FASI in several places. X X4. It has been used only on SCO. X X5. To use with ECU, you'll need to hack -DFASI_IN_USE into the Xecu Makefile. The other programs in ecu don't need to know about it. X(Hint: ecufriends can make good use of the features.) X X6. If you turn on FAS/i support in ecu, you get the undocumented Xfasi interactive and procedure commands and these %functions: X XInteger functions: X%fasi defined for all ecu versions; returns 1 if FAS/i X support included, else 0 if not. The other functions X will cause procedure termination with undefined function X errors "ifi %fasi==0". X%msr MSR current value X%lnerr accumulated FE+OE+PE count X%ridet accumulated RI count X%brdet accumulated BREAK count X XString functions: X%msrtext MSR current value in string form for easier (less efficient) X MSR inspecition. You can do something like X X $s20 = %msrtext X ifi %instr($s20,'CTS') X echo 'CTS present' X ifi %instr($s0,'RING') X echo 'We are receiving a RING this very instant') XThe returned string is one or more substrings separated by asterisks. XSo, you might get 'CTS*DSR*RING*'. The list of substrings, one for each Xbit in the canonized 8250 MSR: X XdCTS delta CTS <---+ XdDSR delta DSR | you are unlikely to see these XdRI delta RI | since the driver catches interrupts XdDCD delta DCD <---- XCTS XDSR XRING XDCD X X7. The fasiintf.c modules contains examples of each FAS/i-specific Xioctl. These are also the only 'documentation' ever likely to be Xproduced for them other than this list: X XFASIC_SIP get entire fas_info struct XFASIC_MSR get various registers XFASIC_LCR XFASIC_IER XFASIC_MCR XFASIC_DVR_IDENT get driver revision XFASIC_SPACE_IDENT get space.c revision XFASIC_RESET_STAT reset statistics X X8. This hacked 'release' is in the style of a purpose-specific Xdriver. If you have an SCO UNIX 3.2.x system with a standard COM1 Xport and a Digiboard PC-8 on COM2, man are you in luck. Otherwise, X X while(!bored && !fed_up && !success) X { X adopt(); X adapt(); X improve(); X } /* "... I always say." -- thanks to John Cleese */ X exit(!success); X SHAR_EOF chmod 0644 fasi/README.FASI || echo 'restore of fasi/README.FASI failed' Wc_c="`wc -c < 'fasi/README.FASI'`" test 6394 -eq "$Wc_c" || echo 'fasi/README.FASI: original size 6394, current size' "$Wc_c" rm -f _shar_wnt_.tmp fi # ============= fasi/RELEASENOTES ============== if test -f 'fasi/RELEASENOTES' -a X"$1" != X"-c"; then echo 'x - skipping fasi/RELEASENOTES (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting fasi/RELEASENOTES (Text)' sed 's/^X//' << 'SHAR_EOF' > 'fasi/RELEASENOTES' && XThis is the original RELEASENOTES from FAS 2.08 for reference only. XRead README.FASI. DO NOT CONTACT UWE DOERING REGARDING THIS HACKED VERSION X ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ X 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 X port. See description preceding the asyopen function in X asy.c. Changed the behavior of ttyxx, too. X X Added output hardware handshake support for DSR. Now you X can do handshake with CTS, DSR or both. Input hardware X handshake is on if you use at least one of the output X handshake signals. X X More flexible support of additional interrupt registers X on mux boards. This is fully configurable now. X X Added support for the CREAD flag. If not set, receiver X interrupts are still serviced, but the received characters X are simply thrown away. This is not as elegant as disabeling X the interrupts themselves, but with the already existing X driver it was the easiest way, and the most new-bugs-preventing, X too. X X Added a lot of comments to the source so that the curious X user can understand why and how things are done. X X X Bug Fixes: X X The hang-up-on-last-close flag (HUPCL) was ignored. DTR X was asserted regardless of this flag. X X Made the detection of CTS and DCD more bullet-proof. X Especially because between a close and the next open of X a line, where interrupts are ignored, the software copys of X CTS and DCD must be set up propperly in the asyopen function X or the tty line would be blocked under certain circum- X stances. For similar reasons, there is also a setup in the X asyparam function. X X Rewrote the input character processing function to work X according to the TERMIO(7) man page. X X Changed the behavior of BREAK generation to let the X transmitter drain before TX is set to low. X X Changed line hangup procedure so that the closing X process returns immediately and doesn't sleep during X the hangup delay/time. Instead, if an other process tries X to open the line while hangup is still in progress, this X process will sleep until hangup is competed. X X With DOS Merge, on MicroPort V/386 3.0e the linker was X missing the function `init8250'. Reengineered this from X a disassembler listing of MicroPort's original driver and X modified it to work with the NS16550A 16-byte FIFO. This X funktion was added simply to be able to link the kernel. X DOS Merge's virtual COM ports are still unusable with this X release, though. To include this function, add a `-DMERGE' X to the CFLAGS line in your makefile. X X Made a lot of other corrections and enhancements in both X speed and functionallity. As a result of all my effords X I think this driver is slightly faster, more versatile X and much more stable than the original release. X X ------------------------------------------------------------ X X release 1.1b Sat Nov 25, 1989 X X New Features: X X Changed the minor device number scheme again. X There are now two main groups: The unblocked open X and the blocked open. Every group has four sub-modes X and an additional hardware handshake flag. All this X is coded in the higher four bits of the minor device X number. Because of this, the maximum of 32 ports was X reduced to 16 ports so that the port number fits into X the remaining lower four bits of the minor device number. X 32 dumb ports in a single machine would have been overkill X anyway. For more details refer to the description in the X README file. X X ------------------------------------------------------------ X X release 2.00 Mon Nov 27, 1989 X X As this release differs so much from the original version I got, X I now declare this as independant from the original author X Jim Murray. This allows me to introduce new release levels X without wondering whether they will collide with Jim's releases. X Of course many credits to Jim for writing this software in the X first place. Without his driver as a base I never would have X been able to do such kernel driver development. X X Bug Fixes: X X If there were glitches on the hardware handshake lines X and the DCD line a getty on this port would sometimes X hang and become an immortal process. I think this was X because the output buffer wasn't flushed properly X on carrier loss. I hope I fixed this now. We'll see. X X ------------------------------------------------------------ X X release 2.01 Tue Nov 28, 1989 X X Did some cleanup in the source code. X X I splitted the driver into two parts: The driver itself and X the file `space.c'. X `space.c' contains all data structures necessary to configure X the driver and is compiled at kernel link time. Therefore if you X change your serial card configuration you simply change `space.c' X directly in the link kit directory and relink the kernel. No X driver recompilation or installation is necessary for this. X But note that whenever you use `make install' your setup in X the link kit directory is overwritten by the original `space.c' X file. Therefore you should copy your new `space.c' back to X the source directory when you are finished with the configuration. X X Renamed the package to `FAS Final Async Solution'. The following X files have been renamed: X asy.c -> fas.c X asy.h -> fas.h X asy_conf-xxxxx -> space-xxxxx X X ISC 386/ix is supported now. There are separate makefiles X for uPort and ISC to cope with the differences in link kit X installation. X X Bug Fixes: X X `getty' still hung sometimes on a line with hardware X handshake. Tried to fix it this time. X X ------------------------------------------------------------ X X release 2.02 Thu Nov 30, 1989 X X Abandoned the distinction between space-xxxxx files with X and without hardware flow control because this is selected X by the minor device number now. X X Bug Fixes: X X Set the high and low water marks for hardware input flow X control to higher values than software flow control. This X gives precedence to software flow control if both methods X are used. These marks are self-adjusting and don't need to X be changed if some flavor of UNIX has a different buffer X size than the standard 256 characters. Before this change X concurrent use of both flow controls could cause trouble X with some high-speed modems. This is fixed now. X X A flush read or write buffer request now also clears the X receiver or transmitter FIFO, respectively. An ioctl X call with a TCSETA* command clears the FIFOs, too. X X ------------------------------------------------------------ X X release 2.03 Fri Dec 01, 1989 X X Wrote an installation guide. The driver should be quite X easy to install now. X X Added tty node configuration files for ISC. X X Hardware input flow control is bound now to the level of the X receiver ring buffer instead of the UNIX input buffer. This X has the advantage that buffer size and trigger levels are X defined in the driver and therefore can be varied as needed. X X New Features: X X Added a boot time status message that shows the init X state of each port. This tells you immediately what X ports are found and initted by the driver. Useful to X determine hardware configuration problems. Look at X the description in the README file. Thanks to X Kritt Gierlewsen (kritt@einoed.UUCP) for this proposal. X X ------------------------------------------------------------ X X release 2.04 Thu Dec 07, 1989 X X Did some cleanup in the source. X X Removed the FIFO clear from the ioctl function. We don't want X to do things there that aren't in the book. X X An ioctl call that switches off the CLOCAL flag will create X a SIGHUP signal if the carrier is actually missing at this X time. X X Every device is tested now quite thoroughly during initialization. X If the test fails the corresponding device keeps unconfigured. X X ------------------------------------------------------------ X X release 2.05 Sat Jan 13, 1990 X X This is the first public release of the FAS driver. X X Special thanks to the sysops of my test sites, Axel Fischer X (fischer@utower.UUCP) and Kritt Gierlewsen (kritt@einoed.UUCP). X X FAS is now an independant driver with its own driver name (`fas'), X major device number, link kit directory and other things necessary X for a driver. The original asy driver may or may not be linked X with the kernel. You only need it if you want to access some X serial devices via the virtual COM ports of the DOS emulator X (DosMerge or VP/ix) because the FAS driver doesn't have this X (really vendor dependant) feature. X X The default prefix for tty device node names is `ttyF' now. X This prevents mix-ups with the device names of the original X asy driver. X X Dropped the SYSV/AT support. I couldn't test the driver X for several release generations on uPort SYSV/AT, and because X there are not very much systems left with that flavor of UNIX X it doesn't make sense to try to maintain compatibility with it. X If someone really wants to use this driver on a 286 he has X to port it himself. X X Improved the transmitter FIFO fill procedure. Now it will try X harder to fill the FIFO as much as possible to cut down on X transmitter interrupts. X X Software input flow control (XON/XOFF) is controlled by the driver now. X It is bound to the level of the receiver ring buffer (as is hardware X flow control). As usual, it can be switched on and off by the X IXOFF flag in the termio(7) structure. X X Changed and speeded up the ring buffer -> unix buffer processing. X X For ISC, the getty lines for the inittab file are installed X by the makefile now. X X The conditional compilation of the function `init8250' (for X DosMerge) is now controlled by a define in `fas.h'. The compiler X switch `-DMERGE' is not used any more. X X Improved the documentation. X X The signals used for modem control and hardware flow control are X fully configurable in the `space.c' file now. Look at `fas.h' for X possible macros and combinations. X X There are some new modes for hardware flow control, for instance X HO_CTS_ON_DSR. This means that CTS is only looked at if DSR is on. X If DSR is off output is possible regardless of CTS. The underlying X assumption here is that we can expect proper handshake handling X only from devices that are in the ready state (indicated by DSR). X As a spin-off the problem with the hanging getty on lines with X turned-off terminals (mentioned in earlier releases) should be X gone if you use this new mode. X X If the XCLUDE-Flag is availabe (SYSV 3.2 because of Xenix X compatibility) exclusive open of a device is possible. X X The default size of the input ring buffer is now 5000 bytes. X This makes streaming input more likely even on loaded systems. X X Bug Fixes: X X The task state busy flag wasn't reset in some rare cases. X This could cause processes to become immortal while waiting X for the busy flag. X X Under some special conditions an ioctl call with a TCSETA? X command could corrupt the last character in the transmitter X shift register. This is fixed now. X X More fixing of the busy flag handling was necessary. X Co-ordinating several delayed tasks controlling this flag X is kind of tricky. X X After a TCSETA* ioctl command we disable the transmitter X for 2 sec (measured from the last transmitted character) X if the character format and/or speed has changed. This X gives the receiving side some time to do the same changes. X This is kind of experimental. There may be applications that X suffer from this delay. You may change the #define ADAPT_TIME X in `fas.h' to a smaller value. X X ------------------------------------------------------------ X X release 2.06 Fri Mar 16, 1990 X X This should have been patch #3 for release 2.05, but there are X so many changes now that I decided to make it a new release. X Therefor some of the changes are described in the 2.05 release X notes above but were never released to the public. X X New Features: X X There is a transmitter ring buffer now to make the output X less system load dependent. This really speeds things up X because the transmitter FIFO gets filled with more characters X at once. The buffer size depends on the actual baud rate to X prevent long output buffer drains at low speeds. X X There are also bigger input buffers to make FAS more competitive X against "intelligent" cards. X X Lots of speed improvements and many small changes. X X Bug Fixes: X X Fixed input/output buffer flush on carrier loss while close X is waiting for the output to drain. X X ------------------------------------------------------------ X X release 2.07 Tue Sep 18, 1990 X X This is a major redesign of the previous release. I put most of the X time consuming tasks in one function that is invoked asynchronously X by timeout calls. Inside this function most of the code runs at X a lower system priority level (spl5) than the interrupts. That X means that during character processing tty interrupts are allowed. X This is the main key to operation at 38400 bps on multiple ports X at the same time which is possible now with this release. X X New Features: X X FAS supports the VP/ix DOS emulator! X Now you can throw out the vendor's original driver even X if you like to have a serial mouse or modem access in DOS. X Read the paragraph about VP/ix in the README file. X X The Intel i82510 port chip is supported. It has separate X 4-character FIFOs for input and output. Although the X NS16550A is much better this chip is your second choice X if you can't get your hands on the National chips. X Thanks to Christian Seyb (cs@gold.UUCP) for sending me X patches and the necessary documentation for the Intel X chips. X X There is an init sequence in `space.c'. You can put any X number of address-data pairs in a null terminated array X to program your serial card or other hardware before X FAS makes the first access to the ports. AST 4-port cards, X for instance, have an additional port that needs to be X written to with a certain bit pattern to allow shared X interrupts. If you need to read a port to achieve the X setting or resetting of flags as a side effect, this X is possible, too. X X ESIX is officially supported now. X X SCO UNIX is officially supported, too. FAS needs to be X compiled with the command line flag `-DSCO'. The makefile X for SCO takes care of that. Thanks to Walter Mecky X (walter@mecky.systemware.de) and Frank Simon X (terra@sol.north.de) for helping me in making the necessary X changes for SCO UNIX. X X SCO Xenix 386 is also officially supported. FAS needs to be X compiled with the command line flag `-DXENIX'. The makefile X for SCO Xenix takes care of that. Thanks to Andreas X Steinmetzler (andreas@oil.UUCP) for doing the port. X X If you have the RTSFLOW and CTSFLOW termio(7) flags, X hardware handshake can be controlled by them. X Note that enabling handware flow control via the X minor device number overrides these flags. If you X like to use them you need to create tty device nodes X with minor device numbers in which the bit for hardware X handshake is set to 0. Look at the description in the X README file for more details. X Note also that if you choose to use RTSFLOW and CTSFLOW X all your programs that do initial access to tty devices X (getty, uucico, cu, SLIP dialup program etc.) need to know X about these flags or hardware handshake will not be used. X X The `O_EXCL' flag for the open(2) call is honored now. X This allowes exclusive access to an FAS device without X suffering from race conditions which could occure with X the termio(7) XCLUDE flag method. X X The `fas_test_device' function returns a digit now that X indicates at which phase the test exited due to an error. X This error digit is displayed in the boot message. Thanks X to Brian Beattie (beattie@visenix.UUCP) for sending me X the necessary patches. X X Bug Fixes: X X Automatic input FIFO flush after unblocking the getty X open by the carrier or the unblock signal. This makes sure X that there is no chance that there are characters in the X FIFO that were received before the open got unblocked. X X The sdevice entry for the AST 4-port card had a wrong X I/O address range (`s_fas-mux4'). This didn't affect FAS SHAR_EOF true || echo 'restore of fasi/RELEASENOTES failed' fi echo 'End of ecu320 part 31' echo 'File fasi/RELEASENOTES is continued in part 32' echo 32 > _shar_seq_.tmp exit 0 exit 0 # Just in case...