XLink Remote PC Control Program              by KHAN Software  V1.04 C021897
XLinkTSR Terminate and Stay Resident Program by KHAN Software  V1.04 C021897

                          XLink User Documentation
                          copyright Korey O'Dell 1997


>  About XLink:

   XLink was written to allow one to control a remote PC from another
   PC via a null modem connection. XLink allows one to redirect keyboard
   input to the remote PC. The remote PC in turn redirects a copy of its text
   video memory back to the controlling PC.


   Some features are:

    1. Ease of use.  Simple installation of an 65K TSR is required on the
    remote PC. Using QEMM or any other memory manager, the TSR can be loaded
    high leaving 635K of conventional memory for use. 

    2. Usability with multiple video pages, and VGA80x50 and EGA80x43 modes.
    Of course, VGA80x25 and EGA80x25 modes are supported also.

    3. Capability to run in /Mono mode. Only the text output (no attributes)
    are sent to XLink. Speed and response improvements are gained with 
    the use of this mode.

    4. Serial ports 1 - 4 are supported on PC, AT and PS/2 compatibles.
    Transmission speeds of 9600 to 115200 baud are available.

    5. Detection and utilization of hardware buffered UARTs 16550
    found in some machines is automatic.

    Registration entitles the user
    to any future enhancements or upgrades which may be released.
    Registration also includes technical support as far as can be provided
    via mail or electronic messaging.  To register XLink,
    send a check or money order for $20.00 to:

         Korey O'Dell
         101 B Paisley Court
         Bozeman MT 59715

    Registration will remove all shareware annoyance screens. Registration
    is possible via an author-supplied codeword.

    The author may be contacted by mail at the above address or via EMAIL
    at 
			impala@cs.montana.edu


    The author of XLink makes no expressed or implied warranty of any
    kind with regard to the software or accompanying documentation.  In no
    event shall the author be held liable for incidental or consequential
    damages in connection or arising out of performance or use of any part
    of this software.

    The distribution should include the following files:

        XLinkTSR.exe  - Terminate and Stay Resident Serial Driver
        XLink.exe     - Control program 
        XLink.cfg     - simple configuration file 	  
        XLink.doc     - This document file.
        Readme.txt    - The same file as XLink.doc.

>   Why use XLink?

    I happen to have 3 IBM PCs at home. Many times I have felt the need
    to be able to control the other PCs remotely. Sharing of devices such
    as modems is now possible. When used in combination with MICROSOFT's
    MS-DOS 6.x INTERLNK.EXE and INTERSVR.EXE, file sharing can be had also.


>   How to use XLink:

    All that is required to use XLink is to load XLinkTSR on the remote
    machine. As mentioned above, by using a memory manager, XLinkTSR
    can be loaded high, thus saving precious conventional memory.
    Once the remote PC is up and running with XLinkTSR, the controlling
    PC then can execute XLink.exe and establish a connection with the
    remote PC.

	 Preparing for use:

	 Unzip the XLink###.zip file into it's own directory.
	 Example:

	   pkunzip xlink104 xlink

	 Last, but crucial step, connect the two or more PCs with a null-modem
	 type serial cable.


	 Typical usage:

	 On controlling PC, command line could read:

	 	xlink	/com2 

	 Use the com port that your serial cable is connected to.

	 On remote PC, command line could read:

	 	xlinktsr	/com2 

	 Use the com port that your serial cable is connected to.

>  Notes:

        If any software that you are running on the remote PC uses multiple video
   pages in VGA80x50 or EGA80x43 modes, you need to reconfigure the software
   to use only one page of video memory (page 0).
   Multiple video pages are supported in VGA80x25 and EGA80x25 modes.

        Setting of XLinkTSR's screen refresh parameter to match your machines 
   speed is critical to the performance of XLink and XLinkTSR. The two machines that
   I used for development were a 486DX4-100 with 16550 UART and a 486SX-33
   with a 8250 UART. On these two machines, a refresh setting of 6 performed 
   the best. Setting to 3 or 4 worked only when running in /Mono mode.
        Otherwise, XLinkTSR's transmit buffer overflows because XLinkTSR is
        filling the buffer faster than the serial I/O can empty it.
     
        The best way to determine the appropriate setting is to
   start XLinkTSR with the /debug command-line parameter. In the
   upper left corner of your screen will be a number that should hover 
   around 16384. Run XlinkTSR and XLink through some full, differing 
   character screens and watch the number closely. If it ever goes on a steady
   decline and stays declining (this number should normally fluctuate between
   10000 and 16384), then you must raise the refresh parameter ie 6 => 9 OR
   run XLink and XLinkTSR in /Mono mode.
   
   On my machines the following refresh rates were possible:

        VGA25 mode with    the /Mono switch => /Ref3 was possible.
	VGA25 mode without the /Mono switch => /Ref6 was possible.
	VGA50 mode with    the /Mono switch => /Ref6 was possible.
	VGA50 mode without the /Mono switch => /Ref9 was possible.
	VGA50 mode with 3 PCs (686-150 as center node, 386dx-40 and 484-dx100
              as end nodes) without the /Mono switch => /Ref9 was possible.

	Higher settings are possible but if a full, differing character
	screen is encountered AND left on screen for any amount of time,
	XLinkTSR's transmit buffer will eventually overflow.
	If a full screen is encountered and the user does not leave it on 
	screen for a long time (10 seconds), everything is fine. 	
	
   The refresh parameter works this way:
   
   if((Timer_Ticks % Refresh)==0) then Send Screen to XLink for Redrawing

   where Timer_Ticks ranges from 0 to 18.

   What's happening when the number steadily declines is that XLinkTSR
   is filling it's output buffer faster than the serial I/O can empty it.

	9600 baud, even with a refresh setting of 18, overflowed XLinkTSR's
	buffer, so beware. I am leaving 9600 baud in only for completeness.
   

>  Improvements

   03/28/96 Version number went to 1.02.
      Changes Involved:
			Fixed buffer overruns while shelled to dos. This fixed the problem
         of poor keyboard response.
         Improved keyboard response rate.
         Added the /debug command-line parameter.
         Eliminated an unnecessary screen redraw when a key was pressed,
         thus improving keyboard response.
         Added support for CTRL-C. Meaning if you press CTRL-C on the 
         controlling PC, 0x03 gets sent to the remote PC and XLinkTSR 
         triggers interrupt 0x23.
   02/09/97 Version number went to 1.04.
      Changes Involved:
         Added default parameters. Both EXEs can now be started with
         no parameters passed.
         Added support for VGA50 and EGA43 modes.
         Added /N, /Quiet parameters.
         Added XLINK.CFG file. Enables changing the quit to O/S key
         to user preference.
         Added additional info to be displayed at startup.
         Changed the help screens tremendously.
		
   02/10/97 Version number stays at 1.04.
      Changes Involved:
			If user specifies VGA50 or EGA43 mode, both EXEs now switch
			to that mode automatically.
			Optimized transmit and receive routines.
			Fixed /debug bug.
         Added yet more additional info to be displayed at startup.
			

   02/11/97 Version number stays at 1.04.
      Changes Involved:
			Added /Mono mode. Allows XLink and XLinkTSR to run in mono mode.

   02/18/97 Version number stays at 1.04.
      Changes Involved:
			Added Sync Up code.
			Fixed bug in EGA43 mode.
			Added registration annoyance screens.
         Added the capability to redefine the XLink help key to
         user preference in XLINK.CFG.

>  Testing
	
	02/09/97 
      Tested with Windows 95. Installed TSR in an MS-DOS box.
      Worked perfectly. Even works with TSR minimized although
      slow and useless.
      Successfully tested 3 PCs chained together. Nodes on ends were 
      able to control opposite end nodes. Basically, every combination
      of nodes were tested. Machines used:


       386DX-40		     686-150			 484DX-100
			
          O------------------O------------------O
		  
         com1				com1 / com2				  com4
        8250 UART		   16550 UARTS			  16550 UART
                     115,200 baud rate			
	02/10/97 
		Discovered that 9600 baud is useless. Overflows transmit buffer.

	02/18/97 
		Tested further with Windows 95. Every test successful.


>  Possible future enhancements

   02/09/97
      Ethernet? Mouse simulation also? DPMI useability? 
      Graphic screen transfers?


>  Released

	02/18/97
      Version 1.04
