home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Current Shareware 1994 January
/
SHAR194.ISO
/
modem
/
tx321fix.zip
/
PATCH.DOC
< prev
next >
Wrap
Text File
|
1993-10-13
|
3KB
|
59 lines
---------------------------------------------------------------------------
deltaComm Development, PO Box 1185, Cary, NC 27512 USA
(919)-460-4556 voice, (919)-460-4531 FAX, (919)-481-9399 BBS
Telix Copyright (C) 1986,87,88,89,90,91,92,93 by deltaComm Development
---------------------------------------------------------------------------
October 13th, 1993 -- Notes on Telix 3.21 patch:
This patch fixes a minor problem with regard to Telix sometimes not
being able to turn off the 16550 FIFO, which can cause problems with
other ill-behaved software such as Prodigy's software and certain fax
software. This patch does NOT correct the problem in which a warm
boot on certain AMI BIOS's can cause the comm port not to be seen or
recognized at all. Only a BIOS replacement can correct this problem.
Thanks to our German distributors (Elsa GmbH, Aachen), specifically
Elsa's software engineers led by Svan Geuer, who discovered an
undocumented (and highly illogical) dependency with regard to the
order in which certain serial port registers are restored when
closing the comm port. This patch corrects the problem, enabling
Telix to correctly restore the state of the 16550 FIFO under all
known circumstances.
To apply this patch:
1) This patch must be applied to the UNBRANDED, REGISTERED copy of
Telix. It cannot be applied to branded copies, or to the
shareware version of Telix. The unbranded TELIX.EXE file can be
found on the distribution diskette in the file TLX321-1.ZIP and
is exactly 274,078 bytes, dated 02-05-93.
2) Place the files PATCH.EXE and PATCH.RTP in the same directory as
the unbranded TELIX.EXE, and run the program PATCH.EXE from that
subdirectory.
3) The resultant copy of TELIX.EXE may then be branded and used.
For those inclined to ask, Telix restored the comm registers in the
inverse order of which they were initialized. This included
restoring the Interrupt ID (IID) register prior to the Line Control
Register (LCR). It was found that (although it shouldn't matter), on
some systems the restoration of the LCR register after the IID
register would sometimes reactivate the FIFO (or possibly the
contents of the initialized LCR would prevent the FIFO from being
deactivated at all -- we're really not sure). By restoring the LCR
to the original state before restoring the IID register, tests have
confirmed that the 16550 FIFO is always thus restored. Don't ask
why, since we don't know -- this behaviour isn't documented in the
National Semiconductor specs *or* their sample code (their sample
code also restores the IID before the LCR).
Jeff Woods
October 13th, 1993