X.00 Low Level Communications Driver X.00 Copyright (c) 1987 by Raymond L. Gwinn 12469 Cavalier Drive Woodbridge, Virginia 22192 All rights reserved You are granted a conditional license to use X00.SYS in conjunction with the Opus Computer-Based Conversation System, by Wynn Wagner III. The user of X00.SYS must meet the conditions of both the legitimate use of Opus and the intended legitimate use of Opus. Further, the author reserves the right to revoke the license and/or prohibit the use of X00.SYS by anyone for any reason at any time. The latest version of X00.SYS is available for down-loading from The Renex BBS (FidoNet 109/639), 703-494-8331 or 703-690-7950. Unlike most software developers, I make Beta/test versions of X00.SYS readily available. This has caused some confusion among various users. That is, they are using beta versions of X00.SYS and think they are using a fully tested (if there is such a thing) versions. Starting with version 1.02 of X00.SYS I am going to use the following method in numbering the versions. If the version number ends with an odd number, then it is a beta version. If it ends with an even number, then it is a tested version that is (relatively) safe for general use. Then, versions 1.01, 2.15 and 1.07 would be beta versions. Versions 1.00, 1.02, 2.00 and 2.14 would not be beta versions. The beta versions will always have (and always have had) a lower case letter appended to the version number. For example, 1.01f is one way that you will see beta versions identified. If you find a problem in a beta/test version, let me know about it by direct mail. X00.SYS comes with no guarantees or warranties. Use it at your own risk. X00.SYS is provided to enable Opus to work under the multi- tasking system MultiLink (by Software Link). X00.SYS does not contain any special code to accommodate MultiLink. Thus, its FOSSIL functions should work on any IBM PC/CLONE. If zero is specified as the number of COM ports, X00.SYS basic functions should work on any MS-DOS system. X00.SYS provides enhanced/extended support of INT 14H functions. Documentation of the enhanced/extended functions can be found in the included file FOSSIL.DOC by Vincent E. Perriello. DoubleDOS. Since writing X.00 I have learned more about DDos than I ever wanted to know. A few rules for DDos users that I know are: 1 - Do not assign the comm ports in DDCONFIG.SYS, 2- Be sure to execute CAPTURE after you execute DOUBLEDO. To be safe, execute CAPTURE in both partitions. 3 - If you have problems with your clock, try the Defer option. 4 - Be sure to replace ANSI.SYS with DBLDANSI.SYS. For some reason, I had problems if the TOP partition was not delayed. That is, the BOTTOM partition must initialize before the TOP partition does. The semi-formal syntax for the statement to be placed in the CONFIG.SYS file is as follows: DEVICE=X00.SYS ::= | ::= ::= E{LIMINATE} ::= D{EFER} ::= B,, ::= R= T= ::= ::= ::= 256 | 512 | 1024 | 2048 | 4096 | 8192 | 16384 | 32768 ::= 300 | 1200 | 2400 | 4800 | 9600 | 19200 ::= | ::= 0 | 1 | 2 | 3 | 4 ::= = ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 ::= | ::= {, } ::= | | | ::= | ........ ::= , ::= Any hex number 0 through 0FFFF. The first character must be 0 through 9. The simplest statement for the CONFIG.SYS file is as follows: DEVICE=X00.SYS This statement will be all that is required on the vast majority of Opus systems. It says that you wish to support one comm port and comm port is as specified in the Opus CTL (really PRM) file. DEFER - DO NOT USE THIS OPTION UNLESS YOU UNDERSTAND ITS PURPOSE AND YOU NEED TO USE IT. IF YOUR SYSTEM WORKS WITHOUT THIS OPTION, THEN DO NOT USE IT. If you needed to use this option with past versions of X00.SYS then try this version without it. Do not automatically assume that you still need it. At least half of the reported problems with X00 have resulted from the casual use of this option. This option specifies that X00.SYS is not to take any DOS interrupt vectors during the boot process. If DEFER is specified then CAPTURE must be executed prior to executing OPUS. Your AUTOEXEC.BAT file is the best place to execute CAPTURE. With MultiLink, CAPTURE should be executed before multi-tasking is started. However, as with 99% of all systems, MultiLink systems should work correctly (and better) without the DEFER option. Unless you are using some strange software, you should not need to use the DEFER option. If your system does not boot correctly with X00.SYS then try the DEFER option followed by CAPTURE in your AUTOEXEC.BAT file. X00.SYS only checks for the D in DEFER. ELIMINATE will eliminate the 5 second commercial at boot time (which is a direct screen memory write). Number of ports. When you wish to use the default IBM/Opus communication port addresses and IRQs, you should simply specify the number of ports that you wish to support (the default is 1). Although X00 V1.00 and up can support up to 8 ports, you can only specify 0 through 4 supported ports. The reason is that there is only 4 defined ports (COM1, COM2, COM3, COM4) that X00 can default to. If you use the absolute method (described later) you can specify up to 8 devices. X00 assumes that COM1 and COM2 are addressed as originally defined by IBM. The default hardware characteristics of COM3 and COM4 are 03E8H, IRQ4 and 02E8H, IRQ3 respectively. This seems to be a defacto standard, although no real standard exists that I know of. With the software that uses FOSSIL drivers today, 2 ports is all that can reasonably be used. However, X00 allows you to make one or both of those ports COM3 and/or COM4 or non-standard hardware. The T and R options (or help, the sky is falling). Trying to be all comm drivers to all protocols on all computers (especially betas) is not easy. The T and R options allow you to specify the size of the transmit and receive buffers. The buffer size must be a power of 2. The sum total, in bytes, of all buffers can not exceed 48k bytes. For example, DEVICE=X00.SYS T=32768 R=16384 is valid (only one port). However, DEVICE=X00.SYS 2 T=16384 R=16384 is not valid (2 ports each with a 16k transmit and receive buffer = 32k per port or 64k). In the second example the total buffer size exceeds the maximum of 48k. X00 SHOULD (but not necessarily) beep the bell and display an error message at boot time if you attempt to define too much buffer space. Also with this option, the default buffer size has been increased to 4k (it was 1k) for both the transmit and receive buffers. The option allows you to lock the baud rate from the computer to the modem. When this option is specified for a port, the baud rate from the computer to the modem will remain constant regardless of what the application program (such as Opus) requests the baud rate to be. This option is to accommodate the higher speed modems like the Telebit TrailBlazer and USR HST modems. When this option is used, RTS/CTS handshaking is implied (forced) even if the application program has not requested RTC/CTS handshaking. Both Telebit and USR recommend in their manuals that the computer to modem baud rate be constant. My personal experience has show that both modem types operate better when the computer to modem baud rate is faster than the actual phone line baud rate. You may specify 0 as the number of FOSSIL comm ports. In this case, all FOSSIL code is released to DOS during booting and X00.SYS will occupy only about 1K of memory. The 0 comm port option is primarily for non IBM systems (such as DEC and Tandy) that must use other FOSSIL drivers. These systems can then use OUTER without carrying the overhead of the unusable FOSSIL code. If you are using Opus and you specify 0 FOSSIL comm ports to X00.SYS, you must have another FOSSIL driver, such as OPUSCOMM loaded into memory for Opus to use. The required communications buffers are allocated dynamically. All code used for initialization is overlaid by the buffers or released to DOS by X00 when it completes initialization at boot time. IRQs. The AT's additional 8 IRQs are supported. X00 can support multiple ports on a single interrupt. When multiple ports are assigned to a single interrupt, X00 will poll each of the ports to find the interrupting device(s). If you plan to reassign the port(s) to a non-standard configuration or use some strange hardware, it is best to think in port numbers instead of COMn. The Opus documentation refers to COM1 and COM2. However, when Opus communicates with a FOSSIL driver, it calls COM1 device/port 0 and COM2 is device/port 1. So if you want to keep your head in order, you can edit the CTL files and (except where you can't) change all occurrences of COM1 to PORT 0 and COM2 to PORT 1. Some examples of CONFIG.SYS statements are as follows: DEVICE = X00.SYS E Which means one port, no commercial. DEVICE = X00.SYS 2 Allocate space for buffers (at the default size of 4k) and provide support for COM1 and COM2. DEVICE = X00.SYS T=1024 R=4096 One port supported, the transmit buffer is to be 1k and the receive buffer is to be 4k. DEVICE = X00.SYS 2 B,1,19200 Same as the above except COM2 will always operate at 19200 baud. COM1 will operate at the baud rate set by the application program. DEVICE = X00.SYS 2 B,0,19200 Same as the above except COM1 is fixed at 19200. COM2 will operate at the baud rate set by the application program. DEVICE = X00.SYS 2 B,0,19200 B,1,9600 In this example the baud rate for COM1 is locked at 19200 baud and COM2 is locked at 9600 baud. DEVICE = X00.SYS 0=COM3 One port supported but, use COM3 on IRQ4 (the default). Opus will think (and must be told in the CTL file) that it is using COM1 in this case. DEVICE = X00.SYS 0=COM3,IRQ4 Exactly the same as above. DEVICE = X00.SYS 0=COM3,4 Exactly the same as above. DEVICE = X00.SYS 0=COM3,IRQ1 Same as above except IRQ1 is to be used. DEVICE = X00.SYS 0=COM4 1=COM3 Two ports supported, Opus thinks COM4 is COM1 and that COM3 is COM2. Use the default IRQs for COM4 and COM3. Now some absolute assignment examples. When hex port addresses are used, the IRQ must be specified. DEVICE = X00.SYS 0=0FE8,IRQ4 Support one serial (8250) device with a base port address of 0FE8H and use IRQ4 DEVICE = X00.SYS 0=3F8,IRQ4 1=2F8,IRQ4 Support 2 serial devices at the given hex port address and both will interrupt on IRQ4. etc, etc, etc. If you are not confused by now, I am, so I'm giving up. REVISION HISTORY V0.01 A problem with transmit interrupts, unique to some systems, was corrected. The supporting program CAPTURE.EXE was added. V0.02 The previously unsupported carrier detect watchdog code was debugged. A new supporting program, WATCHCD.COM, was added. CAPTURE.EXE was changed to a COM program, now CAPTURE.COM V0.03 Added 2 additional functions to maintain compatibility with OPUSCOMM. V0.04 This version was kind of rushed out because I found a dumb error and corrected it. New FOSSIL functions, BOOT, TIMER TICK, and WATCHDOG were added. The new FOSSIL function were not tested to my satisfaction however, the corrected problem warranted a new version now. If Opus said "OPUS!COMM not responding" with X00.SYS loaded, try again. V0.05 This revision corrected some problems and represents a major restructuring of the code. The 0 comm port, DEFER and ELIMINATE options were added. V0.06 Added one line of code to correct a problem in one of the enhanced INT 14H functions. Function 8 incorrectly returned prior to the transmit buffer being empty. V0.07 Henk Weavers (500/1) reported a problem with FOSSIL function 13 which this version corrects. This is probably the one that gave SEAdog problems. I have not been able to get a SEAdog version that uses FOSSIL drivers, so I am not able to test X00.SYS with SEAdog. V0.08 This version corrects no problems (that I know of). I did do some re-structuring and general cleanup. I may have unknowingly corrected problem(s). However, I now have SEAdog V4.0 running on my system (109/639) under MultiLink (V4.0 also) using this version of X00.SYS. I have been running SEAdog in 2 partitions for 2 days and all (including mail events) seems to be as it should be. I have also crashed mail all over the world (literally) and entered messages in one partition while the other was sending mail. You will most likely have to use the *x option in your BBS statement in CONFIG.DOG. Read the SEAdog manual for *x information. I will document and make available my control files when time permits. V0.09n This version was never released for general use. All versions of 0.09n were/are Beta test versions for the generic (absolute port assignments) features. These features have not been widely used and probably still have problems. If you are the type that likes some excitement in your life, try this: DEVICE=X00.SYS 0=COM2 or if you are running 2 ports DEVICE=X00.SYS 0=COM2 1=COM1 These statements effectively reverse the normal Opus assignments. Don't forget to consider the effect on your CTTY, IBMAUX and WATCHDOG statements. If you doubt that Murphy lives, reversing the defaults will change your mind. As a side note, I used a ConnectCom 4 from Software Link (the same people that sell MultiLink) to do all of my testing of the generic functions. The Software Link is located in Atlanta Ga. their phone number is 404-998-0700 V1.00 I think X00.SYS is now solid enough to be called version one. At least on my system, the glitches, crashes, strange conditions and problems have been corrected or explained as not an X00 problem. The major enhancements in V1.00 is the addition of the ability to specify comm ports in hardware as well as conventional terms. On the minor side, the code has been streamlined for faster execution in anticipation of the faster modems that are starting to appear in the net. Also, some problems in the interrupt service routines have been corrected. These problems would cause lock ups under certain conditions. NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE The command line to invoke WATCHCD V1.00 is changed with this release of X00.SYS. Read the WATCHCD docs. V1.02 Added some wierd things the keep SEAlink from getting locked up. If you have seen "too many errors" or otherwise had problems with SEAlink transfers, this version of X00.SYS may clear it up. The problem really showed up when using high speed modems with high speed computers. Added the locked baud rate option. Cleaned up some problems in the parsing of the options line. Previous versions did not like it if you tried to specify more than 2 ports. X00 will now leave DTR alone when a program exits. V1.04 This is fix up version. No new features have been added. This version simply corrects problems introduced with "new features" of previous versions. All additions/changes to help some SEAlink implementations have been removed from X00. They caused as many problems as they fixed. Don't forget that you can turn X00's FOSSIL (comm) functions on and off by using CAPTURE ON and CAPTURE OFF. Corrected a problem in the modem handshaking that occurred when a fixed computer-to-modem baud rate was specified. Due to an incorrect assumption on my part the RTS/CTS handshaking was not always forced on (as it should have been). Corrected a problem of slow output when a disconnect occurred. Increased the transmit buffer size from 512 bytes to 1024 bytes. The increased buffer size hides an error in some windowed protocol implementations. V1.06 The DEFER option now (again) implies ELIMINATE. Added an internal stack for the driver initialization call. This is necessary for DOS V2.0 and V2.1. Added support for Opus definitions of 19200 and 38400 baud. Added an internal stack for communications interrupt processing. Corrected a problem with DTR being turned on incorrectly when Opus is invoked from the keyboard. Corrected a problem in command line parsing with DOS V2.xx. Added the ability to specify the size of the transmit and receive buffers. See the specs and examples above. Default buffer size was changed to 4k bytes. X00 now beeps the bell if it displays an error message at boot time. Added some defensive code to detect the loss of transmitter interrupts. This problem showed up a lot on systems running DDos. V1.08 Corrected a problem with the timer tick processing when the DEFER was specified. Added functions to meet draft 4 of the FOSSIL specification. Added FOSSIL as a driver name. Added all of the draft 4 specification changes except the dispatcher functions (7E and up). Inserted code to attempt to fix a watchdog problem on the 386's. Added code to work around a DDos bug. NOTICE - If you use CAPTURE or WATCHCD, you must have v1.08 or above to work with this version of X00. Corrected problems in Status function (27). Added Quiet mode call to function 4 (init). Added bit 3 (enable sending of XON/XOFF) to function 15 (0FH). Corrected a problem in the RTS/CTS flow control. On slower computers RTS may not have been turned off soon enough. Computers running less that 6 MHz should not lock the baud rate any higher than 9600 baud Function 4 now returns information in BX as specified by Draft 4 of the FOSSIL spec. Prior to 1.07j, it did not. Corrected a problem where X-ON was being sent at random when the sending of X-ON and X-OFF is enabled. Made changes to speed a few things up a little. Changed functions 22, 24, 25, and 27. Parameters that were passed in DS are now passed in ES. If a second parameter was passed with DS in SI, it now must be passed in DI. See FOSSIL.DOC for the new calling sequence for the above listed functions. This time, the FOSSIL specification is being changed to reflect the new calling sequences. Added code to work around an apparent problem with SEAdog. SEAdog should work faster with this version. Worked over the interrupt service routine. Corrected a problem in the hardware handshaking. Disabled the sending X-OFF. Corrected a problem with 2000h and 4000h bit returned by function three. X00 will not initialize the baud rate on a function 4 call. This will allow outside type functions to use X00 at the same baud rate as set by the program that loaded it. V1.08a Function 22 (16h) does not work correctly in V1.08. This release corrects the problem. V1.09a Can you believe it, another beta. Anyhow, this version attempts to correct a problem that some have reported with lockups (mostly with TrailBlazers). V1.09b Added the best anti-locking system conceived by man. This, of course means it will lock up every other time that it is called. V1.09c Hopefully X00 now completely meets the Draft 5 FOSSIL specification. The external function dispatcher was added. Bit 3 is always turned on in AL as returned by the status call (function 3). The baud rate is no longer set in the init call (function 4). PROGRAMMERS NOTE THE FOLLOWING FOR V1.09c With this version (1.09c) and the introduction of the external function dispatcher, interrupt enable is handled differently by X00. Prior to this version, X00 would always enable interrupts during the processing of INT 14H (FOSSSIL) functions. Starting with this version, interrupts are enabled only if they were enabled when the INT 14H is issued. Otherwise, the interrupts will remain masked throughout the processing of the INT 14H (FOSSIL) function. When external routines are entered via the dispatcher all registers and status bits (including interrupt enable) are as they were when the INT 14H is issued. This means parameters may be passed in any register(s). Additionally, parameters may be passed on the stack (if you dare) and the stack appears as though the routine were entered via a FAR call and thus, a FAR return should be issued. When the FAR return is issued, the return is to the instruction following the original INT 14H in the application program and NOT to X00. This means results can be returned in any registrer(s). V1.09d - Added transmitter disable/enable to transmitter unlocking code. ------------------------------ Time permitting, I will respond to messages pertaining to X00.SYS. Please do not get upset if I am slow. Ray Gwinn