Xref: utzoo alt.msdos.programmer:26 comp.sys.ibm.pc:28633
Path: utzoo!attcan!uunet!shelby!agate!ucbvax!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!eecea!gordon
From: gordon@eecea.eece.ksu.edu (Dwight Gordon)
Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc
Subject: Re: Switching COM: Ports
Message-ID: <643@eecea.eece.ksu.edu>
Date: 11 May 89 16:28:19 GMT
References: <412@carroll1.UUCP> <542@megatek.UUCP> <1989May10.111641.8831@gpu.utcs.utoronto.ca>
Reply-To: gordon@eecea.UUCP (Dwight Gordon)
Organization: Kansas State University, Manhattan, KS
Lines: 19

In article <1989May10.111641.8831@gpu.utcs.utoronto.ca> tj@gpu.utcs.UUCP (Terry Jones) writes:
>Even programs that go directly to hardware may work with the "switched"
>com ports. There is an area in memory that stores the hardware addresses
>of installed ports (40:0) and software that actually looks there to find the
>address of com1 or 2 should switch properly. . . .

  The problem comes if your software uses interrupts.  Normally COM1 is
hard-wired to INT4 and COM2 is hard-wired to INT3.  Swapping the pointers
will fool the bios into believing that the hardware COM1 is really COM2
and visa-versa, however the interrupts will remain the other way around.
This will cause any (well, almost any :-) software to be confused.  
Theoretically, the software could look for standard port assignments, and
make some assumptions if they are not so, but this is a lot to expect of
any programmer :-) (no flames please, I program too!).

Dwight W. Gordon         |   913-532-5600    |   gordon@eecea.eece.ksu.edu
Electrical & Computer Engineering Department |     dwgordon@ksuvm.bitnet
Kansas State University - Durland Hall       | rutgers!ksuvax1!eecea!gordon
Manhattan, KS 66506      | {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!gordon