The Pier Shareware 6/The_Pier_Shareware_Number_6_(The_Pier_Exchange)_(1995).iso/035/lr11d.zip/README.TXT

Text File | 1994-11-18 | 8KB | 162 lines

LinkRight 1.1D Patch

Users who have had trouble establishing a reliable parallel
port connection with LinkRight should get and use this patch.
This patch should work much better on those systems.

The zip file should unzip to 3 files: LR11D.EXE, LRPAR.SYS
and this file, README.TXT.  Unzip it to your LINKRT11 directory
and then run LR11D.EXE.  This is a patch to LinkRight 1.1, so
if you have the A, B, or C patches already applied, you'll have
to get your original 1.1 diskette, put the LR.EXE and
LRCLONER.EXE from your 1.1 diskette into your LINKRT11
directory before running LR11D.EXE.  You may have to change
the settings of the LinkRight 1.1 object on your desktop to
make sure it executes LR.EXE rather than LRBAK.EXE.
LinkRight 1.1D will be displayed as the version when you get
the first window with the options of Local or Remote so be
sure to check for it.  Also, LRCLONER displays the version
when started, so be sure to check it.  When the LRPAR.SYS
driver installs, it now displays the version.

****IMPORTANT******
LinkRight 1.1D requires the 1.1D driver.  Don't try to use it
with the LRPAR from 1.1 or 1.1C, it won't work.  Also, a system
running 1.1D can only connect to another system that is also
running 1.1D.  In other words, make sure you update all your
executables and all your machines to 1.1D.

I assume you can figure out where to place the included
LRPAR.SYS.

Turbomode (in the Options menu of LinkRight when in Local mode)
should be turned off initially.  Also, Turbomode is read and
set once when you establish a connection.  To change Turbomode,
change the option, disconnect if you are currently connected,
and do a re-connect.  If you have no trouble with Turbomode
off, you can try Turbomode on and get a speed boost.

The LinkRight parallel port driver can now be used in interupt
driven mode or polled mode.  The default is polled, which matches
the default of PRINT01.SYS in OS/2 Warp 3.0 (or so I've been told).

Interupt driven mode has some problems.  I've had some of my test
systems lock up completely when used in Turbomode with interupt mode.
The same system does not lock up when Turbomode is off.  None of my
test systems have any problems when using polled mode.  Many
gigabytes transferred successfully!!

For LRCLONER, you no longer need EAUTIL.EXE and CMD.EXE in the
C:\TEMP directory.  This should make cloning easier.  You still
need the temp directoy and LRCLONER.EXE should be started from
this directory.  Although I said this for 1.1C it turned out not
to be true.  I really mean it this time!!

The complete list of options for LRPAR.SYS are

DEVICE=LRPAR.SYS /Q:7 /P /A:3BC /M

where:
 /Q:7 uses IRQ7 or /Q:5 uses IRQ5.  These are the only IRQs supported.
 Interupt driven mode can only be used if PRINT01.SYS or PRINT02.SYS
 also uses the same interupt.  If no /Q option is selected, polled is
 assumed.

 /P is for polled.  This is a useless option, since it is the default.

 /A:3BC or /A:378 or /A:278 select the address of the LPT port for
 LinkRight to use.  If this parameter is used, only one address can
 be specified.  Then, when you select Connect from the LinkRight
 menu, no matter which LPT port you select, either LPT1, LPT2 or
 LPT3, LinkRight will use the address specified.  If this parameter
 is not included, LinkRight reads the BIOS info at bootup time to
 get the LPT addresses.

 /M is to specify MicroChannel machines.  For some MicroChannel systems
 when booted from bootable floppies, LinkRight would not see that it
 was MicroChannel and would assume an ISA bus.  This caused the
 driver to fail.  So if you boot your MicroChannel system from floppies
 and the LinkRight driver displays a message at bootup time saying
 an ISA bus was found, use this parameter to fix the problem.

 The preferred and suggested mode of use is no parameters on the
 LRPAR.SYS line in CONFIG.SYS.  You can add parameters if there are
 any problems.

 I'm interested in hearing speed test results on various systems.  A
 quick note would be appreciated.  A good test is a 1 megabyte file.
 Note that a group of files with a total size of 1 megabyte will be
 significantly slower since there is a lot of overhead for each
 individual file.

 For the 1 megabyte file on various systems you should expect these
 kinds of times.  Note that the processor mentioned is for the receiving
 system and as long as the sending system is close to the speed of the
 receiving system, the receiving system will be the bottleneck.
 Please let me know if you get significantly different numbers.

 386 SX 16 Mhz 50 seconds
 486 SLC 25 Mhz 25 seconds
 486 DX 33 Mhz 15 seconds
 Pentium 60 Mhz 10 seconds

 These numbers assume 8 bit mode (look at the Remote system when you
 establish a connection and it will tell you if it is using 8 bit
 mode or 4 bit mode; LinkRight figures out fastest mode it can use
 automatically).  Expect 30% slower for 4 bit transfers.

 Also assuming 1024 packet size and Turbomode.

 Serial mice and slow systems are a problem when using the parallel
 port.  Bump the packet size down to 128 bytes and turn Idle time
 transfers on and it may improve response with the mouse.  PS/2 style
 mice are not a problem.  If you find responsiveness is a problem and
 you are willing to work with me, I'll create a special driver for
 your particular systems to improve mouse responsiveness.  It may take
 a few tries to get it right, so patience would be required.  Obviously,
 when I get it working well on your systems, I'll incorporate it into
 the full LinkRight product.

 Bump up the Retry Warning Delay option to 9 and you will not get any
 of those annoying Retry Warnings.  LinkRight will try forever if this
 value is 9.  Of course, you won't know if there is a problem either.

 Major bugs fixed with this version!!  There is a bug with the C Set
 compiler and Toolkit (I think) that caused previous versions of
 LinkRight to sometimes not copy files or make the receiving file
 zero bytes.  I've worked around this compiler bug and now that I have
 it fixed for LinkRight, I'll be reporting it to IBM.  For the record,
 IBM may already have a fix for this compiler bug (or I may not be
 using the API call correctly), so I can't really complain too loudly
 until I check into this.  If you're interested in the details,
 check the OS2DF1 forum where you'll see a complete report.

 I used a different API and it seems to work OK now.  My thanks to
 Alan McClean in Vermont and Hans Joachim Lippke in Germany for pointing
 this bug out to me.  Also, my apologies to  any users who were bitten
 by this bug.  It was not an easy bug to find (some users may disagree,
 but they probably just automatically find any bugs) and I had to
 transfer over 50 Megs at a time to get it to fail.

 One user complained about updating the Remote system screen just to
 display a "dot".  I didn't see any problem on my systems, and it looked
 like a minor nit.  But during final testing of this version, I grabbed
 my slowest system, turned the hardware turbo switch off on it, and
 watched for about a second for it to refresh the screen.  Very annoying.
 There is a workaround available, though.  From an OS/2 command prompt,
 run LRCLONER T LPT1 on the Remote system.  You won't lose any
 functionality and won't be annoyed by the slow screen refresh.

 For cloning systems, there is an alternative method that should be used
 in some cases.  Boot both systems from bootable floppies and run
 LRCLONER T LPT1 from one system and LRCLONER S C: LPT1 from the other
 system.  Run LRCLONER with no parameters to check the proper usage.
 Since both systems are booted from floppies, you don't have to worry
 about locked files.  I've been told you have to do this way if you're
 using COMM manager or Extended Services.

 Good luck and happy computing!!

 Jeff Tremble
 President Rightware Inc.