Monster Media 1994 #1/monster.zip/monster/DRIVERS/FX550107.ZIP/FIX16550.DOC

Text File | 1994-03-14 | 15KB | 276 lines

FIX16550 Device Driver v01.07.00  14 MAR 1994 (94073) 20:39:03
Copyright (c) 1993-94 Professional Software Engineering, Ltd.
All rights reserved.


This is the documentation file for the FIX16550 program.

This program has a pretty narrow function -- to fix problems with AMI BIOSes
and 16550 ("hi-speed/buffered") UARTS.  As an added benefit, the program also
happens to permit (usually much older) computers which only recognize COM1: and
COM2: to automatically recognize COM3: and COM4: if they are present.

If you can power-off your computer and power it back on and all of your serial
ports get recognized, but they don't if you simply reboot the computer using
the keyboard, then this program is probably what you're looking for.

While this document makes a number of references to the AMI BIOS, this program
is not dependant IN ANY WAY on the presence of an AMI BIOS -- there may very
well be other BIOSes out there that exibit this or a similar problem.  When
using this program to extend older BIOSes to COM3: and COM4: capability, the
BIOSes will certainly vary in manufacturer.


Operation is simple:  Simply add the line:

DEVICE=C:\PATH\FIX16550.SYS [8514] [NO8514] [ARCNET] [NOBEEP] [BRIEF]

(where "C:\PATH\" is replaced by where you really put the file.) into your
CONFIG.SYS file.  Near the top is best (before any other programs initialize,
so they too will know how many ports your machine has, if they care).

Normally, there is no need for any parameters at all.  The exceptions being:

  *    You have an 8514/A video controller (see v01.06.00 - v01.07.00 release
    notes below), and for some reason it is not automatically detected by
    the program, in which case you'd specify "8514" on the commandline.
  *    You do not have have an 8514/A video controller, and for some reason
    the program claims it found one.  BE CAREFUL WITH THIS -- IF YOU USE
    THIS OPTION AND YOUR VIDEO DISPLAY BLINKS OUT WHEN THIS PROGRAM IS RUN,
    THEN YOU HAVE AN 8514/A ADAPTER, WHETHER YOU THOUGHT YOU DID OR NOT.
    The "NO8514" switch is provided strictly for compatibility purposes in
    the event that somehow a system is incorrectly identified as having an
    8514/A.
  *    You have an ARCNET board configured which conflicts with COM4:.  No
    autodetect is done for these boards, so if you have one, you may wish
    to include the optional switch "ARCNET".  Better yet, reconfigure the
    ARCNET board to not clash with the COM4: device.
  *    You don't like the warning tones the program generates to inform you
    that it is doing it's job (when it detects a port the BIOS didn't, or
    detects a conflict with COM4: and the 8514/A), in which case you would
    want to add "NOBEEP" to disable the beep tones from being emitted when
    these error/warning conditions occur.
  *    You don't really want to see all the port information each time your
    computer boots, in which case you would specify "BRIEF" to disable all
    the port status messages from being displayed, keeping your boot screen
    a bit less cluttered.  Since BRIEF also inhibits status messages
    indicating automatic port additions and removal (such as a COM4: with
    the 8514/A), it also happens to inhibit the beep tones which are part
    of the messages being displayed under those circumstances.

Commandline options are not case-sensitive, but also DO NOT REQUIRE dashes or
slashes (in other words, don't use slashes or dashes in front of the arguments).

Since this driver is an initialization-only driver (it does it's job and quits,
much like a word processor would -- it doesn't remain in memory to do
anything), there is no purpose to loading it high (although the program will
operate fine if loaded high to run), and it will not affect memory use in a
computer.  If you loaded it at the top of your CONFIG.SYS, loading high
wouldn't be an option anyway -- your upper memory driver (QEMM, EMM386,
NetRoom, 386MAX, etc.) wouldn't be loaded yet.


When the program is executed, it displays a version/copyright banner, and
(unless BRIEF is specified on the commandline), four lines in the format:
COM[n]:  BIOS [Y/N]  SCAN:  [type of UART found / conflict message]

Where 'n' is the port number (1-4), "BIOS Y" indicates that the BIOS table
showed the presence of this port, and "BIOS N" indicates that the BIOS table
did not have the port listed.  The text following "SCAN:" indicates the type of
chip found, or lack thereof.  When BIOS shows 'N', and SCAN shows a port was
found (or when BIOS shows 'Y', and SCAN reports an 8514/A conflict) is when
FIX16550 has done something for you.

                *-------------*

I don't know how widespread the AMI BIOS problem with 16550 FIFOs is, but it
appears to exist in the (as of this original writing in late 1993) "current"
version of the AMI BIOS dated DEC 1991.  The problem manifests itself when you
have a high-speed UART installed (something which is advised if you use a high
speed modem -- most internal high speed modems are equipped with a 16550
equivalent), and use a program which enables the FIFO (the special feature of
the 16550 UART chip), but which either does not disable it on exit, or is
rebooted while running (which is a valid thing to do, say if the computer is
running a BBS, and a user shells to DOS and drops carrier).  When the AMI BIOS
goes looking for serial ports on startup, it fails to see the port (because it
doesn't appear normal, since the FIFO is enabled), and the computer boots up
without that port in the list of available ports.  Then other software cannot
"see" the port as being present, and won't work (such as attempting to run your
comm program or the BBS after the reboot).  A hard reboot (power cycle, or that
red button on the front of the case) will reset the UART at the hardware level,
and thus the AMI BIOS will recognize it.  This program simply looks for the
hardware in a better way than the AMI BIOS does, and adds the ports
automatically for you.

I've heard that some people have thought that this problem was something wrong
with their system board (since it doesn't show up if you hard reboot the
machine).  Take another look -- you may have an AMI BIOS.

Don't get me wrong -- I like AMI BIOSes very much (I could be using a different
one if I wanted).  They have a lot of great features, and aside from this one
problem, appear quite bug free (unlike the old DTK/Erso).


As for systems that don't recognize COM3: and COM4:, they are fairly
widespread, and include PC, 286, and 386 machines, though I don't know about
486 boxes (most companies should have it straight by now).  Name brand
manufacturers known to have this problem, at least in some models, include
Compaq and AST.

After a lengthly discussion with a user, it was determined that QMODEM (at
least certain versions of it, and I suspect other comm programs as well) may
require a base port address in order to operate (i.e. "COM4" might be a
configuration option, but you need to tell it that "COM4" is 0x02E8 elsewhere
in the configuration).  Telix is similar (v3.10 - v3.22 I know), but has all
the base addresses pre-initialized, although it allows you to change them.

For reference, the standard assignments of ports and their base addresses and
IRQs are:

    COM1:    03F8    IRQ4
    COM2:    02F8    IRQ3
    COM3:    03E8    IRQ4
    COM4:    02E8    IRQ3


This program will not enable support for a serial port that a specific software
program cannot otherwise recognize (some games, for instance allow modem or
direct serial connection, but usually only through COM1: or COM2:).  Microsoft
Windows, for instance (v3.0-v3.11, though it might be fixed in v4.0) will only
recognize a Microsoft mouse on COM1: or COM2:, even though you can use the DOS
Microsoft mouse driver on COM1-COM4 (other mouse drivers may differ).

Some BIOS manufacturers also have the very bad habit of providing BIOS services
for the serial ports based on the position number they occupy rather than the
port value -- that is if you have COM1:(3F8) and COM4:(2E8), the BIOS will
provide services for serial port 1 and serial port 2 (NOT serial port 4).  This
should not be an issue with most systems, and certainly not most high-speed
serial communications programs, which don't use the BIOS to manipulate the
serial port anyway.


I originally wrote this utility strictly to deal with my experiences with the
AMI BIOS problem.  When I called AMI, they told me I needed to get in touch
with the system board manufacturer -- which in all likelyhood is some offshore
company, and they wouldn't even give me a company name!  The AMI BIOS is
mentioned in the Microsoft Windows Resource Kit as having serial problems --
and my BIOS is for a 486DX2 machine -- not exactly old technology.

                *-------------*

v01.00.00
v01.01.00
v01.02.00 unreleased versions, used internally before finding that AMI had no
interest in being given code to correct a problem in their BIOSes, since they
wouldn't admit they even had a problem.

v01.03.00 incorporates a detection for the 8514/A video adapter, which
conflicts with the use of a COM4: port.  With all the port addresses they use
for the 8514/A, you'd think they could have left 2E8h alone!  First public
release.

v01.04.00
v01.04.01 debugging versions, not released.

v01.05.00 incorporates a fix for an odd bug which caused some ports not to be
properly added back to the port table (although they were detected and reset).
8514/A support has been disabled until better documentation is available.

v01.06.00 adds a commandline switch (which I'd like to have avoided the need
for, but still I cannot locate good docs on the 8514/A) for dealing with 8514/A
based video systems.  The switch is simply "8514" (no slash, dash, or anything,
example:  "DEVICE=FIX16550.SYS 8514").  This will flag the program to not
initialize the COM4: device (which would usually cause an 8514/A system to
blank it's screen), and to REMOVE any occurrence of COM4: (02E8h) from the BIOS
data table if it is found, and alert you in the process.  If you have a COM4:
and specify this switch, FIX16550 will beep at you each time it is run (you
have a hardware conflict that should be resolved).  A specific example of a
board with 8514/A capability is the ATI Ultra (a VLB Windows accelerator using
ATIs MACH-32 chipset).  The ATI Ultra does not support having the 8514/A mode
disabled -- which means (as is stated in it's documentation), you cannot have a
COM4: in a machine with an ATI Ultra.  I had one of these, and discarded it in
favour of the Diamond Viper VLB (no 8514/A crud, MUCH faster, and less buggy
Windows drivers).  If that sounds like a plug for the Viper, it is.
Also with this release, the official formatting of the distribution archive
name changes to something a bit more version-identifiable:
    FX550106 ( F(i)X (16)550 (v)1(.)06 )
Not released.

v01.06.01 added two other options: NOBEEP and BRIEF, described above in the
usage section.  Added comments to the documentation about some comm programs
requiring additional configuration to see a port properly.

v01.06.02 was strictly a text change in the program, accompanied by a
FILE_ID.DIZ with an updated format.

v01.07.00 Introduced improved 8514/A passive auto-detection code.  Also added
the NO8514 option (to force checking for an 8514A off).  If 8514 is specified
on the commandline, the autodetect will NOT take place, since the user has
specified that one is present.  Similarly, NO8514 will cause the program not to
perform the check, and claim that one is not present.  This is done so that in
the event that for some reason the 8514/A detection code mis-identifies a
system as having an 8514/A when in fact there is not one, the program can be
configured around the checking.  Also, having found that evidently some ARCNET
boards (when configured in a certain way) have a similar compatibility issue
with COM4:, I have added the "ARCNET" switch, which will also disable COM4:
operations and will kick in the compatibility removal of COM4: if the BIOS
claims it is present.

                *-------------*

The archive this program was distributed in was originally a PKZIP v2.x
authenticated archive with only 4 files in it: this document, the program, and
two types of BBS description files (FILE_ID.DIZ and DESC.SDI).  Nothing else
should have been in the archive, and at completion of extraction of the
archive, you should have seen the following message, with an "-AV" after each
and every file in the archive:

Authentic files Verified!   # DQP160
Professional Software Engineering

If not, then you did not recieve an original of the archive as produced by the
author.


This program is ShareWare.  A fee is requested for it's use.  If you use it
(and the only reason you should be using it is if it addresses a problem you do
have), a registration of US$10.00 PER COPY USED is required.  The grief and
annoyance this program can save you over time will be well worth the small
registration, especially if you are a BBS operator.  Please make the cheque or
money order (drafted ib a U.S. bank) payable to: "Sean B. Straw", and send it
to the address below.

You will recieve notifications of major updates to the program for a period of
one year from the date of registration (although you will not get a disk each
time), and you are entitled to use any subsequent versions of FIX16550 without
re-registering.

Comments, suggestions, and corrections are invited.


About the author:
=================

Professional Software Engineering is a developer of system enhancement
utilities and a variety of anti-virus tools.  We also provide custom systems
programming services in assembler and C, and perform password recovery for
files in PKZIP files which have been encrypted.


Professional Software Engineering
Post Box 2395
San Rafael, CA  94912-2395

[phone]


If calling, and you get an answering device, please be sure to start your
message with your complete phone number (including area code), and the name and
version of the program you are calling about ("Your program" is not descriptive
enough).  Then describe the problem you are having, and end the message with
your phone number repeated a second time, just for good measure -- if I can't
make out your number, I cannot very well get back to you to help you with your
problem.