Using Serial Ports from Microsoft Windows

...that is, the COM1 and COM2 devices.  Things have improved since the
trouble-prone days of Windows 3.1 and 8550 UARTs, but there are still
some quirks to overcome.

The first step is to swear the oath of fealty to Bill Gates, but then....


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.os.ms-windows.setup
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net
      !noc.near.net!uunet!walter!qualcom.qualcomm.com!jafar!smiller
Sender: news@qualcomm.com
Nntp-Posting-Host: jafar.qualcomm.com
Organization: Qualcomm, Inc., San Diego, CA
Date: Sat, 8 May 1993 21:47:14 GMT
Message-ID: <smiller.736897634@jafar>
From: smiller@jafar (Scott Miller)
Subject: COM ports 3/4


I've installed Windows NT March and am trying to get it to recognize
an AST CC-832 4-port serial card.  COM1 and 2 are working fine (in
compatability mode on IRQ's 3 and 4), but not COM 3 and 4.  It is 
configured to use IRQ 2 for COM's 3 & 4 using 0x2b0-0x2b7 and 0x2b8-
0x2be IO ports respecitivly.  The manual goes on to explain that IO Port
0x2bf must be checked after receiving IRQ2 to find out which port
(3 or 4) has data pending.  If bit 3 is 0, then port 4 has data, if
bit 2 is 0, port 3 has data.  By default, the entire register is all
1's.

Pages 46-49 ("Notes on Multiport Serial Adapters") of the Win32 SDK
Release Notes talk about using the registry editor to add support
for additional serial ports.  I am uncertain which Value Names are
required.  Below are the current settings for COM3 and 4:

 Serial 2
	PortAddress	REG_DWORD	0x2b0
	Interrupt	REG_DWORD	2
	DosDevices	REG_SZ		COM3
	PortIndex	REG_DWORD	1
	InterruptStatus	REG_DWORD	0x2bf
 Serial 3
	PortAddress	REG_DWORD	0x2b8
	Interrupt	REG_DWORD	2
	DosDevices	REG_SZ		COM4
	PortIndex	REG_DWORD	2
	InterruptStatus	REG_DWORD	0x2bf

The support lines (DTR, RTS) function correctly with the configuration
above.  The process locks when it receives any data and must be
killed.  (I've been using the Terminal program to talk to a Hayes-
compatible modem.)

As a side note (and shouldn't really matter?), the 4 brain-dead
16540 UART's have been replaced with 16550's.

Any clues or hints would be greatly appreciated.

Cheers,
Scott Miller
<smiller@Qualcomm.com>


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



Newsgroups: comp.dcom.telecom
Path: cs.utk.edu!ornl!rsg1.er.usgs.gov!darwin.sura.net!math.ohio-state.edu
     !sdd.hp.com!spool.mu.edu!telecom-request
Message-ID: <telecom13.379.11@eecs.nwu.edu>
Organization: College of Computing
Sender: telecom@eecs.nwu.edu
Approved: telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 13, Issue 379, Message 11 of 11
Date: Sun, 6 Jun 1993 20:37:20 GMT
From: duggan@cc.gatech.edu (Rick Duggan)
Subject: Re: New Rockwell V.32bis Chip Set

In article <telecom13.368.5@eecs.nwu.edu> todd@friend.kastle.com writes:

> moswald@cwis.unomaha.edu (Mike Oswald) writes:

>> Where would I need to make changes in Windows if I have 9600 v.32/v.42
>> external modem and I was wondering about how to help my COMM programs
>> performance?

> In all seriousness, though, insure that you have a 16550 UART on
> board.  Most UARTs these days are socketted, so you can pull the old
> (16450 or 8250) and pop in a 16550.  Also available are improved COM
> drivers for Windows its self, such as TurboComm.  These are all
> commercial apps, though.

Well, they're not all commercial.  I've just started using a shareware
comm driver replacement for Windows called chcomb.  It's available on
Compuserve; the registration fee is $10 or a really tacky postcard.

It's very simple to install.  Drop in the 16550, then replace a single
line in your system.ini file (device=*combuff becomes
device=chcomb.386).  If you also set COM1Buffer=10000 and COM1FIFO=1,
you should get very good performance.  Before installing chcomb, I
could not download and do anything else at the same time.  Now,
downloads go fine in the background (at 1600 cps on .zip files) and
other windows are usable.


rick


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

Newsgroups: comp.dcom.telecom
Path: cs.utk.edu!gatech!howland.reston.ans.net!spool.mu.edu!telecom-request
Message-ID: <telecom13.369.2@eecs.nwu.edu>
Organization: TELECOM Digest
Sender: telecom@eecs.nwu.edu
Approved: telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 13, Issue 369, Message 2 of 9
Date: Mon, 31 May 93 10:37:12 -0400
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Lines: 66
Subject: Windows and the 16550 UART

The following is the text accompanying the WFXCOMM software driver
downloaded from the Supra BBS (503.967.2444). Incidently the p/n of
the original UART (Universal Asynchronous Receiver/Transmitter) was
8250 not 8450. Seems my memory was faulty as usual.


Warmly,

Padgett 

WinFax PRO 3.0   Windows COMM Driver Readme Notes   March 31, 1993
==================================================================

Using updated Windows communications driver (WFXCOMM.DRV)

The WFXCOMM.DRV file should be copied to the Windows\System directory.
When enabled, this driver should permit WinFax and all other
communication programs using the same COM port to operate at 14,400
bps.

The updated Windows communications driver is named:

WFXCOMM.DRV

To enable this driver, edit your SYSTEM.INI file, and change the
COMM.DRV= line as follows:

comm.drv=WFXCOMM.DRV

The driver tests for the presence of a 16550 UART, and will not enable
the FIFOs if the UART is not of the correct type.

Advanced settings for this driver are also available. The settings for
both transmit and receive FIFO thresholds are adjustable via
SYSTEM.INI entries in the [386 Enh] section.

To define the number of bytes loaded into the transmit FIFO on each
interrupt, edit:

ComxTXSize=y

where

x is the COM port number
y is a number between 1 and 16

The default value is 8 bytes, but 16 bytes provides a reduction in
interrupt overhead, with no change in fax transmission reliability.
If you use a transmit FIFO setting of 1, the driver cannot stream at
maximum throughput.

To define the interrupt threshold for the receive FIFO, edit:

ComxRXSize=y

where:

x is the COM port number
y is one of: 1, 4, 8, or 14

The default value is 14 bytes, which matches the setting in the
original Windows 3.1 commmunications driver. Setting the receive
threshold to a lower value increases receive reliability. A setting of
8 is recommended for most systems.


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.mail.uucp,comp.bbs.waffle
Path: cs.utk.edu!emory!swrinde!cs.utexas.edu!uunet!nwnexus!fnkytwn!chrisw
Message-ID: <wunHsAOEBh107h@fnkytwn.wa.com>
References: <930530.160532.1K2.rusnews.w164w@alpha3.ersys.edmonton.ab.ca> <1trglh$s6a@colin.muc.de> <1993Jun14.205012.10345@nntpd.lkg.dec.com>
Organization: FunkyTown Creations
Date: Tue, 15 Jun 93 21:47:28 -0800
From: chrisw@fnkytwn.wa.com (Chris Wilson)
Lines: 18
Subject: Re: UUPC's uucico from Windows?

In <1993Jun14.205012.10345@nntpd.lkg.dec.com> guineau@star.enet.dec.com writes:
>
>Has anyone run UUPC's uucico from Windows?  I tried once and at one
>point (before I got my site running properly with my feed) it
>hosed my disk.

>I noticed 'uucico.ico' in the archive, so I assume it must work
>under windows somehow...

I don't see why this should be a problem. :-)  I'm running Waffle
under Windows and do all of my UUCICO operations thru a DOS window with
no problems.  UUPC's version should work as well.

-- 
*----------------------------------------------------------------*
Chris Wilson - Bellevue, WA           |          Life 
Internet:   chrisw@fnkytwn.wa.com     |   would be much easier
Compuserve: 76660.1226@compuserve.com | if I had the source code
*----------------------------------------------------------------*


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.ibm.pc.hardware.comm,comp.dcom.modems
Path: cs.utk.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!postman+
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 36
Message-ID: <Igwv7v6SMUI35Rb5cp@transarc.com>
References: <CGyGxz.A8H@fc.hp.com>
NNTP-Posting-Host: po2.andrew.cmu.edu
In-Reply-To: <CGyGxz.A8H@fc.hp.com>
Date: Wed, 24 Nov 1993 14:11:55 -0500
From: Graeme_Dixon@transarc.com
Subject: Re: MS-Windows COM and Ns16550A UART FAQ

rjn@fc.hp.com (Bob Niland) writes:

> The TurboCom Drivers
> 
> You can get replacement drivers that solve all of the above problems, for
> all ordinary Windows COM apps, by buying a copy of "TurboCom", current
> version 1.2, from:
> 
> Bio-Engineering Research
> Pacific CommWare Division
> 180 Beacon Hill Lane
> Ashland  OR   97520-9701
> (503) 482-2744 voice
> (503) 482-2627 FAX
> (503) 482-2633 BBS
> MCImail:    344-5374
> CompuServe: 71521,760
> 
> Price was around $50 as I recall.  Bio-Eng is not set up to accept credit
> cards, so I had to send a check.  Egghead and 1-800-Software list TurboCom
> but as far as I know, they don't stock it.  Bio is not a software company

People may be interested to know that Charles Schwab's "Street Smart"
(an application for accessing accounts with Schwab, placing trades
etc) comes with the TurboCom drivers. Street Smart costs $59, so if you
are thinking about buying it and also want a faster serial driver then
Street Smart is a good deal.

Graeme

-------------------------------------------------------
Graeme N. Dixon                    graeme@transarc.com
Senior Member Technical Staff      412/338-4454 (voice)
Transarc Corporation               412/338-4404 (fax)
707 Grant Street
Pittsburgh, PA 15219





Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu
 !nigel.msen.com!ilium!rcsuna.gmr.com!csid.gmeds.com!csid.gmeds.com!not-for-mail
Organization: EDS Corporation
Message-ID: <2fce4g$3vm@pascal.csid.gmeds.com>
References: <2f7ov6$a2v@pascal.csid.gmeds.com>
NNTP-Posting-Host: pascal152.csid.gmeds.com
X-Newsreader: Tin 1.1 PL4
From: camou@csid.gmeds.com (Mario Camou)
Date: 23 Dec 1993 10:40:00 -0500
Lines: 20
Subject: Re: 16550 pin-compatible with 8250?

camou@csid.gmeds.com (Mario Camou) writes:
: Hi all,
: My PC has its serial interface on the motherboard. It's equipped with
: *GASP* a 8250 UART (this is a 486DX/33, for chrissakes). I want to
: upgrade to a 16550. What I'm wondering is, is the 16550 pin-compatible
: with the 8250? (I seem to recall hearing it is, but I want to be sure).
: I'd like to replace it.

Thanks to all who responded. As it came out, the 16550 *IS*
pin-compatible with the 8250. According to some of the people who
responded, the price for a 16550 is about US$11, so I guess I'll soon
pull out that 8250 and change it for a REAL UART. For those of you who
are still running with 8250's, dont wait! Upgrade!

Thanx and Happy Holidays,
-- 
Mario Camou / EDS Mexico Client-Server Integration Team
From Mexico City, the smog capital of the world
------------------------------------------------------------------------------
My opinions are only mine, mine, MINE!


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!swrinde!sgiblab
      !pacbell.com!amdahl!kla!mikem
Message-ID: <yP2wHc5w165w@pid.kla.com>
References: <Feb.16.22.10.22.1994.22675@paul.rutgers.edu>
Reply-To: mikem@pid.kla.com (Mike Morris)
Organization: KLA Instruments Corp.
Date: Thu, 17 Feb 1994 15:57:09 PST
From: mikem@pid.kla.com (Mike Morris)
Subject: Re: 16550 aware version of Win 3.1 'comm.drv'

alvin@paul.rutgers.edu (Alvin Garcia) writes:

> edleslie@elearn.edu.yorku.ca (Ed  Leslie) writes:
> 
> >Mike Morris (mikem@pid.kla.com) wrote:
> >: Can anyone recommend a driver that will take full advantage of a
> >: 16550 UART under Windows?
> 
> >: This must be a driver, not a terminal application. I'm running an 
> >: X-Server application over SLIP. I've added a 16550 and can see some
> >: marginal improvements but am hoping for more!
> 
> Check out a product "TurboCom/2" on page 44 of the February 22, 1994 issue of
> PC Magazine.  I'm not a Windows user, but this sounds like what you might be 
> looking for.  Hope this helps.
> 
> -Alvin

It was exactly what I'm looking for -- I now own two copies! 

This is a great package; installed easily, instantly showed great
throughput/performance improvements, and only cost $30.


Thanks,

Mike Morris
===================================    =====================
Internet: MikeM@pid.kla.com            Phone: (408) 456-6091
CI$:      70142,1653                   Voice: Hey, Mike!


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!howland.reston.ans.net!pipex!uunet!news.crd.ge.com!sixhub!davidsen
Reply-To: davidsen@tmr.com (bill davidsen)
Organization: TMR Associates, Schenectady NY
Distribution: usa
Message-ID: <CLEGt7.4D6@sixhub.tmr.com>
References: <761107686.2544.0@windsor.math.cmu.edu> <mejCL774n.Csw@netcom.com>
Date: Fri, 18 Feb 1994 03:10:19 GMT
From: davidsen@sixhub.tmr.com (Bill Davidsen)
Lines: 16
Subject: Re: 16550A UART serial card -- how many clams?

In article <mejCL774n.Csw@netcom.com> mej@netcom.com (Mark E Jensen) writes:
| Christopher Dalton (cd27+@andrew.cmu.edu) wrote:
| : What's a good price for a card with a single 16550A serial port?  The local
| : compusa has some for $40 but this seems a bit high.  Is it? 

No. I pay a little more for them, although <$50. The chips are about
$10-12 each, so $15-20 for the card and shipping seems fair.

I get mine from ELKCO (1-800-24ELKCO) and have installed several in
client's machines as well. You can do a few bucks better locally if you
don't have sales tax.
-- 
Bill Davidsen, davidsen@tmr.com      |  C programming, PC based UNIX, data
    TMR Associates, +1 518-370-5654  |  acquisition, device drivers.
_____________________________________|______________________________________
New England Winter 93-94: Many are cold but few are frozen


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!darwin.sura.net!howland.reston.ans.net!pipex!sunic!news.chalmers.se!cd.chalmers.se!tl
Message-ID: <CLL927.wA@news.chalmers.se>
Sender: news@news.chalmers.se
Nntp-Posting-Host: wagner.cd.chalmers.se
Organization: Chalmers Computer Society
References: <S> <jtara.35.0017E735@crash.cts.com> <CLA4tw.FsC@news.chalmers.se> <CLG37u.9ws@sixhub.tmr.com>
Date: Mon, 21 Feb 1994 19:06:07 GMT
From: tl@cd.chalmers.se (Torbj|rn Lindgren)
Lines: 24
Subject: Re:  16550 aware version of Win 3.1 'comm.drv'

In article <CLG37u.9ws@sixhub.tmr.com>, Bill Davidsen <davidsen@tmr.com> wrote:
>In article <CLA4tw.FsC@news.chalmers.se> tl@cd.chalmers.se (Torbj|rn Lindgren) writes:
>| It does take SOME advantage, but not much. It sets the interrupt
>| trigger-level for incoming characters to 14 (out of 16!) and doesn't
>| output multiple characters to the UART.
>
>1) that's correct for a system with slow response to interrupts. It
>   gives you 12 char times to respond.

Setting the trigger-level to 14 characters means that the UART doesn't
send an interrupt until it has 14 characters in the FIFO! This means
that you have 3 (!), not 12 character times to respond.

The best setting for slow systems is probably either 4 or 8
characters, since 1 far more interrupts.

>2) how can it not send multiple chars to the UART? The TxR signal stays
>   on until the FIFO is loaded, so you should send bursts. To avoid this
>   you would have to check TBE instead. If you mean it checks that the
>   UART is ready between chars, it only takes a few cycles.

When it senses that TxR is on it sends a single character and then
returns if I remember the code right (it was a while since I looked in
the DDK).


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!darwin.sura.net!howland.reston.ans.net!EU.net!ub4b
      !rc1.vub.ac.be!rc1.vub.ac.be!waverheu
Organization: Institute Molecular Biology, Brussels Free University
Lines: 19
Distribution: world
Message-ID: <waverheu.411.2D6CDEAB@rc1.vub.ac.be>
References: <5a.11659.312.0N1C9D55@ase.com>
NNTP-Posting-Host: imolpc1.vub.ac.be
X-Newsreader: Trumpet for Windows [Version 1.0 Rev B]
Date: Thu, 24 Feb 1994 17:06:51 GMT
From: waverheu@rc1.vub.ac.be (Willy A Verheulpen)
Subject: Re: 16550 serial and AMI BIOS

In <5a.11659.312.0N1C9D55@ase.com> paul.hough@ase.com (Paul Hough) writes:
>
>Subject: 16550 serial and AMI BIOS
>From: paul.hough@ase.com (Paul Hough)
>Date: Wed, 23 Feb 94 16:59:00 -0500

 >Has anybody heard of the AMI bios having problems with the 16550 serial port?
 >I seem to be having intermitant problems where my keyboard goes into caps
 >across the board to include the numbers and nothing but a reboot seems to fix
 >it.  Any help would be appriciated.  Thank You.

 >Paul Hough  
 >---
 >  ATP/DJgcc 1.42  Beverly can turn Data off but only Tasha can turn him on.
 
I am not concerned but I read that there are AMI BIOS problems.
There seems to be a fix file at oak.oakland.edu in modems called 
16550fix.zip
Hope this gets you out of problems, good luck


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.ibm.pc.hardware.comm
Path: cs.utk.edu!ornl!stc06r.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu
      !vixen.cso.uiuc.edu!howland.reston.ans.net!EU.net!news.funet.fi
      !news.eunet.fi!dkuug!login.dkuug.dk!odin
Organization: DKnet
Message-ID: <odin.762113258@login.dkuug.dk>
References: <2kg7vc$n3u@spool.cs.wisc.edu>
NNTP-Posting-Host: login.dkuug.dk
Date: 24 Feb 1994 18:07:38 GMT
From: odin@login.dkuug.dk (Michael Larsen)
Lines: 27
Subject: Re: Anyone know anything about Winbond chips?

lorenzo@picard.cs.wisc.edu () writes:

>I've been looking into serial ports for Doom serial play.  Anyway, I have
>a Winbond chip set on my com ports and the guy who sold it to me tells
>me that it is "16550 compatible".  I'm not sure, but you should be able
>to lock the port speed to 19200 if you have a 16550.  MSD identifies the
>chip as an 8250 UART and if I try to set the port speed to 19200 it replies
>that my computer does not have that capability.  

>Anyone have any comments, criticisms and/or remarks??

>Terry

I've been through 3 multi IO boards with Winboad chips on them... every
one didn't FULLY work (i.e. a dead serial port, dead floppy or dead
printer)... so I wouldn't recomend them...

If MSD says 8250 I am afraid it is... if you REALLY want to be sure get
modem doctor or a Natioal Semi check program for 16550s and see what they
say... 


I finally took the last of these multi io boards back and replaced it with
a VLbus card

(I use a zoom with an on board 16550 to dial out, it generally works!)


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.isdn
Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!uunet!vnet.IBM.COM
Message-ID: <19940304.134329.62@almaden.ibm.com>
Organization: IBM Corp.(Research Triangle Park, NC)
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.1
References: <2l6k4u$a3q@darkstar.UCSC.EDU>
Lines: 54
Date: Fri, 4 Mar 94 16:43:30 EST
From: lmarks@vnet.IBM.COM (Laurence V. Marks)
Subject: Re: Remote access for database apps

In <2l6k4u$a3q@darkstar.UCSC.EDU> Joseph Everett Bentley writes:
>Remote Access Problem with Paradox for Windows:
>
>Currently we are developing a Paradox for Windows application
>for a company that needs remote access for their sales reps in
>the field.  They need the data to be as live as possible.  We
>have found two possible solutions but we are looking for any
>ideas and inputs to solve this problem.
>
>Solution A:  Remote Modem software.
>        The company has used PC-AnyWhere in the past but decided
>it was too slow.  Currently they are using Norton-Lambert's Close-Up
>which is much faster in the Windows environment, but when they use it
>with any Paradox for Windows forms, it becomes so slow that it is
>almost unusable.  We are looking for any recommendations on any Remote
>Modem software.
>
> .
> .
> .
>have heard there is Novell solution and we are also looking in Network
>Modem hardware/software, and ISDN.  If you have any experiences in the
>area or know of any product which could help us, we would greatly
>appreciate it.
>
>If you send information about a product, please inform us how to
>obtain a copy or contact the manufacture.  Thank You in advance!
>
>--
>       ___                ___  ___
>      /  /                \  \/  /        Joseph Bentley - joe@limax.com
>     /  /     o        __  \  \ /      Limax Computing - Paradox Questions?
>    /  /___  / /\/\   /_|  / \  \              E-mail: info@limax.com
>   /______/ / /    \ /  | /__/\__\      Ph:(408)425-7455  Fx:(408)425-7516
>

It's not clear from the description where the the slowdown is--in
data communication or interaction with Windows.  If the slowdown is
data communication, an easy solution is at hand.

Just replace the serial cards and modems with IBM WaveRunner cards,
and use Solution A.  WaveRunner was tested with PC Anywhere under
Windows--I don't think CloseUp was tested, but expect that it will
also work.

Using bitmapped screens remotely is quite feasible with WaveRunner at
56 kb/s  or 64 kb/s.  (In fact, remote X-windows works quite well.)

WaveRunner cards are $545 (ISA bus) and $575 (MicroChannel).  For more
information, call the WaveRunner Hot Line at (919) 254-ISDN.  To order
call 1-800-IBM-2YOU  (1-800-426-2968).

Laurence V. Marks
IBM Corp. - Research Triangle Park, NC


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

Article 55187 of comp.dcom.modems:
Path: cs.utk.edu!emory!swrinde!hookup!nic.hookup.net!xenitec!zswamp!geoff
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: comp.os.os2.apps,comp.dcom.modems
Subject: Re: HELP! Hayes ESP, 28.8 V.FC
Message-ID: <e8Fwic5w165w@zswamp.UUCP>
Date: Tue, 08 Mar 94 21:46:01 EST
References: <bwdCMAwBv.A28@netcom.com>
Organization: Izot's Swamp
Lines: 22
Xref: cs.utk.edu comp.os.os2.apps:36025 comp.dcom.modems:55187

bwd@netcom.com (Billy Dunn) writes:

>    Under Windows, when I could configure the ESP card, I could come close 
> to the 1 Meg per minute claim.  There are certain files on the Hayes BBS 
> that demonstrate the modem's capabilities (although I know these are 
> "ideal" files being used).  Under OS/2, I just can't setup the damn 
> board.
>  
>    I have heard some good things about Digiport.   Doesn't anyone have 
> contact information for that board?

DigiBoard USA
6400 Flying Cloud Dr.
Eden Prairie, MN 55344
(800)344-4273
(612)943-9020
(612)943-5398 FAX
info@digibd.com

Geoffrey Welsh geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff
"Recipes are for those who have a preconceived idea of what their food is
 supposed to taste like" - Ron Scoular


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



Newsgroups: comp.binaries.ibm.pc.wanted,comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.dcom.modems,comp.os.msdos.apps,comp.os.msdos.programmer,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.net,comp.sys.novell
Path: cs.utk.edu!emory!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!pjk
Message-ID: <pjkCMrBpq.CpF@netcom.com>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <1994Mar10.234044.27919@mixcom.mixcom.com>
Distribution: usa
Date: Wed, 16 Mar 1994 12:22:38 GMT
From: pjk@netcom.com (Phil Koenig)
Lines: 48
Subject: Re: INT 14h/NASI drivers for use with Netware 3.12

In article <1994Mar10.234044.27919@mixcom.mixcom.com> ELJA inc
 <ELJA.inc@mixcom.mixcom.com> writes:
>
>Could someone please point me in the right direction?  We have a program
>called Telix for Networks which runs on NETBios/Netware systems which
>use INTERRUPT 14h to redirect communication services to the modem.
>We have Novell Netware 3.12, and would like to use the NASI/NACS services
>supported by Netware.  What special requirements are necessary in order
>to use this?  Are there any drivers (INT 14h/NASI) that are available
>on the Internet or commercially for a reasonable cost?  Some of the
>products cost 10 times more than Telix for Networks itself.
> 
>Any thoughts or ideas on this?
> 
>Mike McWhinney
>Elja, Inc.



Int 14H is a DOS function call that was originally designed to access
the serial communication port.  Since it's pretty slow and sends data
one character at a time, most DOS software developers long ago started
writing their programs to bypass the DOS function and go directly to
the UART chip (Including standard TELIX, BTW).

It had a recent resurgence since it is a standard way of accessing 
communications programs, and therefore lends itself to network usage
in modem-sharing devices, etc.  NASI is a proprietary Novell method
of common serial communications which was derived from NCSI (invented
by Ungermann-Bass, I believe) which works better in the Netware environment
and is generally faster in my experience.

If your modem server hardware and your communication software both 
support NASI, I think it is a better way to go.  Novell provides NASI
as a free program, I believe, but the application has to be written
to support it.  There are, finally, some reasonably-priced comm. software
products that have NASI support.  Crosstalk for Windows is one, PC-
Anywhere-LAN is another, Remotely Possible-LAN is another.  There is
at least one other inexpensive single-user software other than Crosstalk
that now supports NASI.. it might be Procomm for Windows.

Hope the info helps..




Phil Koenig
pjk@netcom.com


 //////////////////////////////////////////////////////////////////////////////


Path: cs.utk.edu!emory!europa.eng.gtefsd.com!MathWorks.Com!zombie.ncsc.mil!admii!hsdndev!dartvax.dartmouth.edu!saturn.caps.maine.edu!maine.maine.edu!mshea
Organization: University of Maine System
Message-ID: <94099.114451MSHEA@MAINE.MAINE.EDU>
Newsgroups: comp.dcom.modems,comp.sys.ibm.pc.hardware.comm
References: <94092.095201MSHEA@MAINE.MAINE.EDU>
 <1994Apr5.125515.1267@mksol.dseg.ti.com> <Cnx6Hw.9n5@rahul.net>
Date: Sat, 9 Apr 1994 11:44:51 EDT
Lines: 53
From: <MSHEA@MAINE.MAINE.EDU>
Subject: Re: Procomm+Win and Kermit question


Update on what I have learned.  I started out with 70 bytes/sec for binary.
I now get 250 bytes/sec for binary transfers and up to 600 bytes/sec for
ascii transfers using Procomm+4W, a USR Sportster 14400 (external), on
A 386SX *WITHOUT* 16550UART.

MY ACCOUNT IS ON AN IBM VM.CMS MACHINE RUNNING AN OLD KERMIT CMS
(1990  4.2.0 ).  SOME OF THE NEWER CHANGES WHICH ALLOW FASTER TRANSFERS
are not implemented.

Changes to Procomm+4Win
     Upgrade from pw1.01 to 1.02 obtained from Datastorm BBS
     1(314) 875-0503 and got the bug fix "dialdr".  This fixed the
     truncation problem and cut down the UART overruns.
     AND fixed unwanted double-spacing in uploads.

     Decreased baud rate to 19200.  There is some loss of speed
     which more than compensated by  the decrease of UART
     overruns.

     Changed Packet Size to 1024 -- Long Packet Kermit.
     (I got msker313 and mskerdoc -- but the CMS Kermit is old)

Changes to windows/system.ini
     [386Enh]
     Com1AutoAssign=2    ;default is 2, but it was suggested that I
          add the line -- it says that a COM Port must be idle for 2
          seconds before Windows will let another app use it.
     COMIrqSharing=False  ;to prevent sharing between COM1 and
          COM2
     COM1Buffer=2048  ;default is 128 -- this change really helped
     COMBoostTime=10  ;Default 2 millisec.  The max time to
          process -- prevents lost keyboard character to raise it

Changes to CMS Kermit
     SET SPEED 19200    ;for binary transfers

     **********
     SET SPEED 14400    ;FOR ASCII TRANSFERS -- THIS DECREASES THE UART
          overruns which I am still getting between files when
          transferring multiple files with a wildcard.
     SET RECEIVE PACKET-SIZE 1024    ;max is 1900 -- just made it
                                 ;JUST MADE IT AGREE WITH PROC+4W
     SET SEND PARITY NONE   ;Why is default for MARK?
     SET SEND PADDING 1    ;I haven't finished playing with this
                           ;I was looking for a "pause" between
                           ;files to decrease the number of
                           ;UART overruns between files when
                           ;sending multiple files with wildcard.
     SET BLOCK-CHECK 2     ;actually I haven't noticed much difference
                           ;in speed among 1, 2, and 3 CRC

That's it so far, Marilyn



 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!howland.reston.ans.net!EU.net!Germany.EU.net!netmbx.de
      !zrz.TU-Berlin.DE!zib-berlin.de!news.belwue.de!news.uni-ulm.de
      !rz.uni-karlsruhe.de!subnet.sub.net!phoenix.ppc.sub.org
      !mips.ruessel.sub.org!not-for-mail
Message-ID: <2peo8h$25j@mips.ruessel.sub.org>
References: <1994Apr24.022622.14677@mnemosyne.cs.du.edu>
NNTP-Posting-Host: mips.ruessel.sub.org
Keywords: v.fast
Date: 24 Apr 1994 23:27:45 +0200
From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
Subject: Re: v.fast is?

anon257b@nyx.cs.du.edu (Name withheld by request) writes:

> 	I have been tryng to figure out exactly what is v.fast. Isnt v.fast
> the same as v.34?

Yes, it is.

> What speed does v.fast rate?

28800bps maximum.

> I have read that v.fast will be the fastest possible modems to build
> using analog phone lines.

Pretty much so. The theoretical limit is higher.

> Will the installation of fiber-optic lines change that?

When the local loop will be converted to fiber (in 2020 maybe?), it will
be completely different, most likely fully digital, from today's phone
technology whose principles date back ~100 years.

> How are the p[roblems of serial port speed in pc handled in 486s? I have

The problems are lesser than some sales people would like you to
believe.

> read that in the 14.4 modems, only the intel comsphere (sp?) external allows

The Comsphere line of modems is by AT&T, you're confusing something,
but...

> the serial port connection to run at 56k. Is this still a problem with the

... that's non-sense anyway.

> Do all 486pcs have 16550UARTs installed?

No. Most current boards don't have serial ports at all, you have to add
expansion cards of your own, so it's up to you to get what you need.
The new PCI boards are likely to feature '550 equipped serial ports,
although some manufacturers will probably cut corners there, too.

> How can I find out if my pc has them installed?

I think the UART type detection works like this (well, I looked it up in
/usr/src/linux/drivers/char/serial.c):

FCR is the fifo control register (write), IIR the interrupt
identification register (read), both are at base+2.
SCR is the scratch register, base+7.

- Write $01 (ENABLE_FIFO) to the FCR.
- Read the IIR, compare with this table:
    %00xxxxxx   8250 or 16450
    %01xxxxxx   unknown
    %10xxxxxx   16550
    %11xxxxxx   16550A

In case you care, the way to distinguish 8250 and 16450 seems to be:
- Write $A5 to SCR, read back.
- Write $5A to SCR, read back.
- If either back value differs from the one written, the UART is a 8250.

I haven't tried this yet, but I assume you can do this with the debug
command of DOS. You have to know the base address of the port in
question. The standard port addresses are:

    COM1:   3F8h
    COM2:   2F8h
    COM3:   3E8h
    COM4:   2E8h

The following would be an example session, figuring out COM1:

C:>debug
-o 3fa 1
-i 3fa
xx
-o 3ff a5
-i 3ff
xx
-o 3ff 5a
-i 3ff
xx
-q

Where xx are hexadecimal return values to be interpreted as explained
above.

-- 
Christian 'naddy' Weisgerber, Germany         naddy@mips.ruessel.sub.org



 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!swrinde!hookup!ames!decwrl!decwrl!netcomsv!netcom.com!cresta1.com!alexg
Message-ID: <alexg.46.003114BC@netcom.com>
Sender: netnews@netcom.com (USENET Administration)
Organization: Cresta Systems, Inc.
X-Newsreader: Trumpet for Windows [Version 1.0 Rev B final beta #1]
References:  <DAFT.94Aug19182020@debussy.crd.ge.com>
Distribution: comp
Date: Sat, 20 Aug 1994 21:23:52 GMT
From: alexg@netcom.com (Alessandro Gatti)
Subject: Re: Pentium hangs on startup of comm program

In article <DAFT.94Aug19182020@debussy.crd.ge.com> daft@debussy.crd.ge.com (Chris Daft) writes:

>I've a Dell XPS-90 connected to a Complete PC 14.4k modem (external,
>on com1; nothing's on com2).  This machine has 16550AF uarts.  Half of
>the time when I start comm software like PC-Xremote (or even Microsoft
>Terminal) under Windows 3.1, the machine hangs.  Only the reset button
>restores it to life.  I tried the fixes in NCD's documentation about
>this but they didn't help.  If the software gets through the first
>half a second of running, things are fine.  I notice that shutting the
>comm package down and starting it again seems to provoke the problem.

>Is this a known problem with Pentiums using 16550AFs and modems under
>Windows?  All advice gratefully received: this is one frustrating
>bug!

MS has a new VxD called SERIAL.386 which fixes problems under Windows on 
Pentium systems. I think this is due to the SMC Super I/O controller chip.

Try it! [the file should be on MS's ftp.microsoft.com or SMC's 
BBS: 1-516-273-4936].

Alessandro Gatti


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
Message-ID: <1994Dec11.212311.35180@cc.usu.edu>
References: <94340.130308SMITHM@qucdn.queensu.ca> <3cbbtd$iqi@apakabar.cc.columbia.edu>
Organization: Utah State University
Date: 11 Dec 1994 21:23:11 MDT
From: jrd@cc.usu.edu (Joe Doupnik)
Lines: 15
Subject: Re: Intermittent Problem with Kermit Under Windows

In article <3cbbtd$iqi@apakabar.cc.columbia.edu>,
  jt50@jambo.cc.columbia.edu (Jess  Ting) writes:
> 
> I've had exactly the same problem. What I've noticed is that when
> the modem is on BEFORE I start Windows, Kermit loads ok, but when 
> I turn on the modem only AFTER Windows has already started, I need
> to quit Kermit and restart it.
> 
> In any event, the problem is merely a nuisance, as Kermit functions
> perfectly well after it is restarted.
----------

	Mr. Gate's outfit needs to address that one. Windows fakes the
real hardware to the DOS box, so Kermit sees what Windows wants it to
see and Windows itself deals with the actual hardware. That's what these
.386 VxD's are about (faking the machine, in lieu of a real kernel).

	Joe D.



 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!europa.chnt.gtegsc.com!news.mathworks.com!news.ultranet.com!news.sprintlink.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
Message-ID: <1995Jun12.104248.53890@cc.usu.edu>
References: <3rhk95$l5@elna.ethz.ch>
Distribution: world
Organization: Utah State University
Lines: 31
Date: 12 Jun 1995 10:42:48 MDT
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Help! Kermit 3.1.4 makes my Windows 3.1 apps crash!

In article <3rhk95$l5@elna.ethz.ch>, FUTTERBAU@cumuli.vmsmail.ethz.ch (Frehner Marco) writes:
> Hello
> 
> I've been using Kermit for a while and with version 3.1.3 thing normally worked
> quite well. Except for occasional crashes of otherwise well-behaved programs
> (MS-Winword 2.0, MS-Excel 5.0) when Kermit was doing a file-transfer in the 
> background.
> However, after upgrading to Kermit 3.1.4 (and using 2000 character packets),
> things got a lot worse.
> I cannot work anymore during a file transfer as there will be random GPF's in
> Winword and errors similar to "Cannot load ANYDLL.DLL" in Excel.
> My Computer is an IBM PS/VP 433DX (33 MHz, 20 MB Ram) running MS-Dos 5.02 and 
> MS-Windows 3.1. I am running Kermit over a direct link (using a T-box and
> broadband communications) to a VAX server.
> 
> Has anyone experienced similar problems? I would greatly appreciate any hints.
------------

	Welcome to Windows, a hostile land for any communications process.
It's not Kermit itself, but rather some combination of ingredients in your
PC. Lovely. We can't diagnose the many ills that involve Windows, of course,
but the best that I can suggest is a) review your memory management with
a very careful eye to detail, and b) don't expect the stock Windows comm
driver to work much above 9600 bits/sec. If you've fallen victim to using
Smartdrive then remove it since it turns off cpu recognition of interrupts
when it does buffer flushes. Screen savers are another gotcha waiting to
strike. 
	Finally, please do take note of Kermit's use of EXPANDED memory
for screen rollback buffers. We discuss that in the release documentation.
	Good luck with the investigation, and you have plenty of company
with Windows GPF's from any cause.
	Joe D.


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


Newsgroups: alt.sys.pc-clone.micron
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!nntp-server.caltech.edu!news.cerf.net!usc!math.ohio-state.edu!uwm.edu!vixen.cso.uiuc.edu!news.uoregon.edu!usenet.eel.ufl.edu!news.mathworks.com!tank.news.pipex.net!pipex!news.sprintlink.net!in1.uu.net!caen!kylef
Organization: University of Michigan
Lines: 35
Message-ID: <42vkvp$h33@srvr1.engin.umich.edu>
References: <mtuley.245.0013CACB@jeffco.k12.co.us> <42t17i$6k5@srvr1.engin.umich.edu> <mtuley.251.00115695@jeffco.k12.co.us>
NNTP-Posting-Host: kylef@windsor.engin.umich.edu
Date: 10 Sep 1995 21:23:05 GMT
From: kylef@engin.umich.edu (Kyle Ferrio)
Subject: Re: What does "16550 compatible" mean?

In article <42t17i$6k5@srvr1.engin.umich.edu> shanming@engin.umich.edu (Shan-Ming Chiu) writes:

>All of the new Pentium motherboards made by Intel and Micronics use a
>single chip to provide EIDE, parallel, and serial functions.  On my
>Millenia, it is the SMC Super I/O chip.  There is no actual 16550 UART
>chip and is instead emulated by this single chip.  I've never had any
>problems but if you need the real-thing, you can buy a 16550 serial
>card for $20.
>
>Shan-Ming Chiu

I have been told by people intimately familiar with the device drivers
available to the Linux kernel that the SMC super i/o chip indeed emulates
16550, not 16550A.  The result is that Linux will see these emulated
serial ports as FIFO-less 16450 ports.  (This seems to be consistent with
the reports of overflow under Windows.) This could be important to anyone
trying to communicate serially in a true mutitasking environment.  Those 
people may wish to condsider a genuine 16550A serial card, as Shang-Ming 
suggested, above.

So here's the bonus question: 

What good is an unbuffered serial chip when 28.8 bps is becoming
commonplace?  So what does anyone hook up to these ports?  I suppose that 
if someone really hated (why?) the PS/2 aux mouse port, they could use a 
slow serial port.  But that still leaves a slow serial port unused.

Comments?

 _________________________ __________________________________________
| Kyle Ferrio             | Time Remaining until Divided Loyalties: 
| University of Michigan  | 23 days, 2 hours, 37 minutes
| Randall Laboratory      | That's right, I see B5 on Tuesdays.



 //////////////////////////////////////////////////////////////////////////////


Newsgroups: alt.sys.pc-clone.micron
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu
     !howland.reston.ans.net!EU.net!news.sprintlink.net!news.onramp.net!usenet
From: wfulton@onramp.net (Wayne Fulton)
Subject: Re: What does "16550 compatible" mean?
Date: 23 Sep 1995 05:55:49 GMT
Organization: On-Ramp; Individual Internet Connections; Dallas/Ft Worth/Houston
Lines: 113
Message-ID: <4407h5$35e@news.onramp.net>
References: <mtuley.245.0013CACB@jeffco.k12.co.us> <42t17i$6k5@srvr1.engin.umich.edu> <mtuley.251.00115695@jeffco.k12.co.us> <42vkvp$h33@srvr1.engin.umich.edu> <432k3f$mqb@usenet.INS.CWRU.Edu> <43aq6b$vq8@sernews.raleigh.ibm.com> <43herl$h5c@news.onramp.net> <43sqek$dce@sernews.raleigh.ibm.com>
NNTP-Posting-Host: stemmons40.onramp.net
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
X-Newsreader: WinVN 0.99.6

In article <43sqek$dce@sernews.raleigh.ibm.com>

>The first rule to BBS Dooming is, 
>no error correction, and no data compression.  The general consensus is
>that you shouldn't do speed-buffering (port speed > line speed).  But I
>don't believe that and tend to run my port at 57600 with the line negotiated
>between 19200 and 24000.

This is due to the interactive mode delays due to V.42 trying to fill full 
blocks, and not of course because V.42 isnt wonderful stuff for most all 
other applications.     

But with error control disabled, theres really no reason or advantage to set 
the port baudrate higher than the carrier.   Doing so in fact adds the 
very serious requirement of proper flow control.  Does Doom support flow 
control, and therefor provide information about how to set it?   If so, then 
fine.   But if not, then the higher port speed simply adds risk of data 
corruption without any offsetting benefit.   If you have a 9600 baud carrier,
there is no advantage for the character stream into the modem to exceed 9600 
baud (if V.42 is disabled).    

If you send only a few characters, flowcontrol is relatively unimportant.  If 
your TX led is on a lot, it's very important to have proper flow control with 
unequal baudrates.  If the modems buffers fill up because data is coming in 
faster than it is going out, the modem must be able to protect itself by 
telling the software to stop sending.   That's flow control.   If Doom doesnt 
discuss that, they probably dont support it, and if they dont, then there is 
no possible correct setting you can make to the modem.   The software isnt 
gonna stop.   Flow control is a communication between comm software and the 
modem, and it requires two partners to have a conversation.   The software 
and the modem MUST be set to match, to speak the same language, or there isnt 
any flow control at all.   

But at any rate, you need the higher port baudrates only for V.42 and 
V.42bis.   

>The general consensus on the BBS is, emulated 16550 doesn't work as 
>well as the real thing. 

I'd personally be skeptical that the 16550 can hurt at all, and would 
particularly be skeptical that the SMC chip is inferior to the old fashioned 
NS16550AFN in any way (if that is what you are calling emulated).  Emulated 
is the Supra style emulation, where there is no UART chip at all, and it is 
instead emulated in modem firmware.   The SMC is not at all the same kind of 
thing.

In a DOS environment on a Pentium machine, its rather unimportant to 
performance whether the 16550 buffer is used or not.   Theoretically, yes, 
the 16550 can and will add a four character time delay on small groups of 
received characters, but that's only 4 milliseconds at 9600 baud, which seems 
totally negligible compared to human reaction time.

Remember tho, the real world is that we can recommend turning the modem 
around north-south instead of east-west, and at least 20% of users will 
report either a great improvement or that it ruined their modem. <G>

>Is this 8 characters the size of an internal buffer in the 16550?  
>Could this size be more limited in another chip?  

The 16550 has two 16 character FIFO memories (first in, first out), for send 
and receive.  In the send direction, it allows the comm driver to load 16 
characters at each TBE interrupt (transmitter buffer empty) instead of only 
one character.  Only 1/16 the number of transmit interrupts greatly reduces 
the load on the computer, and lets it go on to other things.   The 16550 uart 
is like a little coprocessor, sending those 16 characters on its own without 
help from the CPU.  This doesnt help comm any if the computer can otherwise 
keep up, but it helps the other programs in a multitasking environment.
Windows 3.1 did not permit use of this send feature of the FIFO.  WFWG 3.11 
allowed it, but the default is OFF.   Win95 finally got it right.   

During receive, the 16550 FIFO receive interrupt trigger point can be set to 
1, 4, 8, or 14 characters.   Windows 3.1 set it to 14 characters, but WFWG 
and all better comm drivers set it to 8 characters.

Doom doesnt have to use the 16550 FIFO just because it is present.  It has to 
be written specially to do so.   It either enables the FIFO, or it doesnt. If 
it is in fact somehow harmful, I would think it wouldnt.  But I dont think it 
is harmful.  

Without a 16550 FIFO being both present and enabled, the software receives 
one interrupt per every received character, and has only one character time 
to process that interrupt and fetch the character, before the next arriving 
character overwrites the first, losing data.  Windows is not tough enough to 
run this way above 19200 baud, but the 16550 helps it run 57600 pretty well. 

But assuming the software sets the receive fifo interrupt trigger to 8 
characters, it means that you get only 1/8 the total number of receive 
interrupts, greatly reducing the load on the computer.   Setting the RX 
trigger to 8 characters also means that if you are slow to process that 
interrupt, because you were off multitasking when you should have been paying 
attention, you now have up to 8 more character times to do it before 
characters start spilling onto the floor and are lost.  The 16 character FIFO 
accumulates 8 characters, and then generates one interrupt.   If you are 
slow, the remaining 8 spaces can be filled without worry about loss of 
characters.   Actually, 99.9% of one more character before damage is done, so 
the 16550 FIFO really gives 9 character times instead of one character time 
to process the interrupt before data is lost.  

Plus the interrupt rate is 1/8 of what it is without the 16550.   The 16550 
makes 19200 baud be the same interrupt rate as 2400 baud without the FIFO.   
This makes a tremendous improvement for Windows, and for any slower machine 
trying to run fast comm. Whenever you do finally get there to process the 
interrupt, you simply read all the characters present in one pass, at the 
expense of only one interrupt.

Dos in a 486 or Pentium is plenty fast enough without the 16550, but I cant 
believe it makes any noticeable difference to Doom to disable it.  OTOH, I 
have not tried it either <G> 

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

Newsgroups: alt.sys.pc-clone.micron
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!gw1.att.com!news.bu.edu
     !bloom-beacon.mit.edu!newsserver.pixel.kodak.com!news.sprintlink.net
     !news.onramp.net!usenet
Organization: On-Ramp; Individual Internet Connections; Dallas/Ft Worth/Houston
Message-ID: <43g8k7$72g@news.onramp.net>
References: <mtuley.245.0013CACB@jeffco.k12.co.us> <42t17i$6k5@srvr1.engin.umich.edu> <43aqbk$vq8@sernews.raleigh.ibm.com> <43d7ft$juj@news.onramp.net> <43fr2n$6e3@geraldo.cc.utexas.edu>
NNTP-Posting-Host: stemmons53.onramp.net
X-Newsreader: WinVN 0.99.6
Date: 17 Sep 1995 04:36:23 GMT
From: wfulton@onramp.net (Wayne Fulton)
Lines: 73
Subject: Re: What does "16550 compatible" mean?
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII

In article <43fr2n$6e3@geraldo.cc.utexas.edu>, 
dcook@utpapa.ph.utexas.edu& says...
>
>In article <43d7ft$juj@news.onramp.net>,
> Wayne Fulton <wfulton@onramp.net> wrote:
>
> >[...] But the Micron SMC 16550 ports are plenty fine in every 
> >way, and you dont need anything else. [...]
>
> Is this your personal experience, Wayne?  I was going to get an internal 
> US Robotics Sportster because of the grumbling about the Micron serial 
> port, but it would be nice to have an external modem with all the 
> blinking lights.


Yes, absolutely, personal experience.  I have two Micron P133 with 
the SMC 16550 ports, at work and at home.  My occupation is a comm 
programmer, and I'm getting involved here because I really do know 
one or two things about it as a user. We have a few other new Micron 
P133 at work as well, and all are fine.  Plus, friends buying 
replacement Pentium motherboards have no problems either.  There 
simply is no such problem.
   
You can definitely believe that the SMC 16550 ports are quite fine 
and 100% functional as a 16550 (with FIFO) in every way.  It's 
absurd to think otherwise.   Remember, virtually every Pentium 
motherboard ever made [as of 1995] has the SMC chips (those with
motherboard  serial ports anyway), and there is certainly no outcry
from the masses about the 16550 not working. There must be hundreds
of them come thru this one newsgroup every day.   The SMC chips are
100% functional as a 16550.  It's just that technology has marched 
forward, and things are done differently now, but there should be no 
concern.  Using OS/2 Warp and SMC chips, I often run two external 
PPI 28800 modems simultaneously, and comm is extremely good.

FWIW, there was an old bug (fixed in any SMC chip made in the last 
year) that used to cause the machine to hang the second time the 
port was used. All the comm drivers were immediately upgraded to 
work around that problem in software, and the SMC hardware was also 
fixed.  Fixed a year ago.  Problem had to do with the way the 16550 
FIFO was reset, and because of that, disabling the FIFO was another 
(very poor) workaround for the hang.  Apparently that has caused 
incorrect old wives tales by those that dont quite understand.  But 
again so it is very clear, there was never a loss of function in the 
16550 FIFO, and upgraded comm drivers fixed it for old chips, and 
all SMC chips in the last year are fixed anyway.   It's not a 
problem.  It's historic trivia.

Some people do prefer an internal modem, they are tidy and a few 
dollars cheaper, but they are harder to install (risk of conflicts, 
etc), dont provide any LED display for feedback, consume a 
motherboard slot.  They dont have a power switch, so you must reboot 
the computer to reset the modem.   Unless you specifically want an 
internal modem, it would be a pity to buy one for the wrong reason. 
Older computers typically had no 16550 port, and an internal modem 
made some sense (but still had the same shortcomings), but the 
Micron (and most other Pentiums) now have two fine SMC 16550 ports 
just sitting there configured and sitting there ready, willing, and 
able.  You merely connect the modem cable, and you're off and 
running in first class.  I'd very much rather have an external 
modem.

SMC is at http://www.smc.com/.   I'm not associated in any way.

The best thing about the Microns SMC Super I/O chip is the 2.88 MHz 
floppy controller, because it makes a QIC-80 tape drive run twice as 
fast.

Wayne

 //////////////////////////////////////////////////////////////////////////////

Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!math.ohio-state.edu!newsfeed.acns.nwu.edu!ftpbox!mothost!mdisea!uw-coco!nwnews.wa.com!news1.halcyon.com!usenet
Newsgroups: alt.sys.pc-clone.micron,comp.sys.ibm.pc.hardware.comm
Organization: Osiris Technical Services / Seattle, WA
Lines: 58
Message-ID: <4eirt6$b3r@news1.halcyon.com>
References: <4edprj$44t@news1.halcyon.com> <4egtl6$8fi@fcnews.fc.hp.com>
Reply-To: jdavid@halcyon.com (David Ruggiero)
NNTP-Posting-Host: chinook.halcyon.com
Date: 29 Jan 1996 16:16:38 GMT
From: David Ruggiero <osiris@halcyon.com>
Subject: Re: Hayes ESP card nukes my Micron...anyone else have better luck?

rjn@csn.net (Bob Niland) writes:
>It was just replaced by Hayes, but the new one also caused problems,
>although different problems.  It even hung the BIOS config program!  I
>finally (fingers crossed) got it to work by:
>    0. Using I/O ports 0x180+188 (the default 0x300 presumably conflicts
>       with the MPU MIDI function of the SoundBlaster Vibra16).

Good suggestion! But <sigh> it didn't work (floppy drive, cdrom, etc, still
nuked) for me.

>    1. disabling (in BIOS) both 16550A COM ports on the M54Hi motherboard

Can't do that; it's not worth losing two serial ports to get one back :).

>    2. telling the BIOS config that I did NOT have a plug'n'play operating
>       system (true for the moment).

Already set that way (I have WFW 3.11).

>    3. Ignoring the ESP manual when it says that system.ini should have
>       comm.drv=c:\windows\system\esp2_w31.drv
>       What it actually puts in the .ini is
>       COMM.DRV=D:\WIN16\SYSTEM\COMM.DRV
>       and that seems to work.  

Wish I could get that far...without a diskette, CDROM, other comm ports, or
soundcard, it seems rather pointless...

>#2 raises an issue that has been troubling me. I presume that disabling PnP
>on the M54Hi merely shuts off I/O Port address 0x0279 (which I was avoiding
>in configuring the ESP anyway), so that should make no difference either way,
>unless the Hayes code is browsing for I/O ports for some reason, and poking
>the PnP port in way that causes lockups. But beyond that, neither Micron nor
>Micronics, so far as I can tell, document what the heck I/O resources are
>used by motherboard functions. For example, I presume the EIDE channel 1 is
>at port 0x01F0-01F7, but is channel 2 at 0x0170-177? How does one find out?

Good question. I paid ~$15 to Micronics directly for their version of the
M54Hi manual, and other than documenting the POST error beep codes, it
provides no more useful information than the bland Micron manual.

>I'm glad I got the ESP working, because the 16550A ports were
>overrunning like crazy above 9600 bps, even with the TurboCom/2
>aftermarket comm driver and receive-FIFO-trigger-level set to 1.  I
>presume this overrun problem is a result of the Matrox Millenium video
>card locking up the PCI bus for too-long bursts (and Matrox video BIOS 1.9
>did NOT fix it, either).

I had the *identical* problem with the Diamond Stealth 2001 (ARK) card
that came with the unit (and I, too, have TurboComm). After many fruitless
calls to Micron and Diamond, I junked it, and put in an ATI Mach64 card.
Immediately, all the overrun problems disappeared. (I myself thought the
Diamond driver was turning off interrupts for too long a time rather than
hogging the bus, but that's sheer speculation.)

Thanks for the input and experiences...

David

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

Article 12591 of alt.sys.pc-clone.micron:
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!chi-news.cic.net!nntp.coast.net!col.hp.com!fc.hp.com!rjn
From: rjn@csn.net (Bob Niland)
Newsgroups: alt.sys.pc-clone.micron,comp.sys.ibm.pc.hardware.comm
Subject: Re: Hayes ESP card nukes my Micron...anyone else have better luck?
Followup-To: alt.sys.pc-clone.micron,comp.sys.ibm.pc.hardware.comm
Date: 28 Jan 1996 22:34:14 GMT
Organization: Colorado SuperNet
Lines: 57
Message-ID: <4egtl6$8fi@fcnews.fc.hp.com>
References: <4edprj$44t@news1.halcyon.com>
Reply-To: rjn@csn.net
NNTP-Posting-Host: waikiki.fc.hp.com
X-Newsreader: TIN [version 1.2 PL2]
Xref: cs.utk.edu alt.sys.pc-clone.micron:12591 comp.sys.ibm.pc.hardware.comm:16289

David Ruggiero (osiris@halcyon.com) wrote:

> Stuffed into my Micron P90 (based on a Micronics M54Hi PCI motherboard),
> however, it manages to kill nearly every IO device on the system. The

I had a 2-port ESP that I used for 1.5 yrs on a 486DX33 clone with zero
problems.  When I installed it in a Micron P133PCI, it hung Windows (3.1
and WFWG 3.11, all possible I/O port address, all possible IRQs, no
other cards in machine, clean installs, etc.), generally behaved
bizarrely and convinced me after days of troubleshooting that one port
on the ESP card had gone bad (under warranty, fortunately).

It was just replaced by Hayes, but the new one also caused problems,
although different problems.  It even hung the BIOS config program!  I
finally (fingers crossed) got it to work by:

    0. Using I/O ports 0x180+188 (the default 0x300 presumably conflicts
       with the MPU MIDI function of the SoundBlaster Vibra16).

    1. disabling (in BIOS) both 16550A COM ports on the M54Hi motherboard

    2. telling the BIOS config that I did NOT have a plug'n'play operating
       system (true for the moment).

    3. Ignoring the ESP manual when it says that system.ini should have
       comm.drv=c:\windows\system\esp2_w31.drv

       What it actually puts in the .ini is
       COMM.DRV=D:\WIN16\SYSTEM\COMM.DRV

       and that seems to work.  

#2 raises an issue that has been troubling me.  I presume that disabling
PnP on the M54Hi merely shuts off I/O Port address 0x0279 (which I was
avoiding in configuring the ESP anyway), so that should make no difference
either way, unless the Hayes code is browsing for I/O ports for some
reason, and poking the PnP port in way that causes lockups.

But beyond that, neither Micron nor Micronics, so far as I can tell,
document what the heck I/O resources are used by motherboard functions.
For example, I presume the EIDE channel 1 is at port 0x01F0-01F7, but is
channel 2 at 0x0170-177?  How does one find out?

I'm glad I got the ESP working, because the 16550A ports were
overrunning like crazy above 9600 bps, even with the TurboCom/2
aftermarket comm driver and receive-FIFO-trigger-level set to 1.  I
presume this overrun problem is a result of the Matrox Millenium video
card locking up the PCI bus for too-long bursts (and Matrox video BIOS 1.9
did NOT fix it, either).

...not looking forward to re-upgrading to Win95, even tho the ESP'95
drivers are now available...

Regards,                                            1001-A East Harmony Road
Bob Niland                                          Suite 503
Internet:  rjn@csn.net                              Fort Collins
                                                    Colorado     80525   USA

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


Path: utkcs2!transfer.stratus.com!cam-news-feed2.bbnplanet.com
      !cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com
      !news-peer.sprintlink.net!news-backup-east.sprintlink.net
      !news-in-east.sprintlink.net!news.sprintlink.net!Sprint!129.240.148.41
      !nntp.uio.no!mn5.swip.net!not-for-mail
Newsgroups: comp.terminals
NNTP-Posting-Host: mn8.swip.net
Message-ID: <34f56aa2.1985485@NNTPSERVER.SWIP.NET>
References: <34F31695.C70ADAF@wxs.nl>
Date: Thu, 26 Feb 1998 13:30:49 GMT
From: MATS.ANDREN@MBOX309.SWIPNET.SE (Mats Andr^n)
Subject: Re: writing and retrieving data from serial port

On Tue, 24 Feb 1998 19:51:01 +0100, "S. van der Wal"
<svanderwal@wxs.nl> wrote:

>Hello experienced people,
>
>I want to try to write a program for writing data and
>retrieving data from a hardware-device connected to my
>serial port. I have the protocol, but then my knowledge
>stops.
>What kind of software (and/or hardware) do I need to be able
>to send data (ASCII) to and from my serial port? Could
>anyone fill me in on this kind of matters?
>I'm using Windows 95.

Windows treats the serial-ports as a file.  (I assume you're using a
32-bit c++-compilator) You open a port like this:

"CreateFile (szDevice, fwdAccess, fwdShareMode, lpsa, fwdCreate,
fwdAttrsAndFlags, hTemplateFile);

..where the parameters stands for...

 1: COM1 or COM2 
 2: GENERIC_READ, GENERIC_WRITE or both (separated with the "|"-sign)
*3: 0 for serial applications because the ports can't be shared in
Win95. 0 Means that your application gets full controll over the port,
so don't forget to give the control back to windows when your program
terminates.
 4: NULL = default
*5: OPEN_EXISTING = default (because serial ports always exists)
 6: FILE_FLAG_OVERLAPPED for asyncron use of the port
*7: Has to be NULL
-------------------------------------------------------------------
Close a serial port:

CloseHandle (hComm);

1: hComm=handle wich is returned by CreateFile
-------------------------------------------------------------------
Then you use the ReadFile and WriteFile to receive/send data.

It's really too much to be covered in this mail, and you won't get
very far with these instructions because there are a couple of
structures that you will need to be aware of before you can write a
working app.. ..a few brief examples of other functions that you'll
need:

GetCommProperties (hComm, lpCommProp);
BOOL GetCommState(hComm, &dcb);
BOOL SetCommState(hComm, &dcb);

There is a good book on the subject from microsoft press (suckers)
called "Communications programming for windows95". ISBN 1-55615-668-5

Frantik/Ht (c64)


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
Message-ID: <01bdef9b$c35c0900$63636363@laptop-brc>
References: <EwSP1.3951$777.3402789@nntpserver.swip.net>
NNTP-Posting-Host: pm4-1-s5-17.orf.infi.net
Date: 4 Oct 1998 13:30:49 GMT
From: Bill Creager <creager@norfolk.infi.net>
Subject: Re: I/O RS232 terminal program

Microsoft distributes a sample program tty.c with their Visual C++ compiler
which would be helpful to you. I have implemented several interactive
computer to computer interfaces which have been derived from this program.
I believe it has been distributed with each release of their compiler.

> Could someone please help me getting more info & hints  about how to make
> a RS232 terminal application in C-programming (similar like common Kermit,
> but not at all that fancy) in order to get a interactive serial
> communication
> between an electronic equipment based on Intel CPU486 and a computer
> (SUN). Or a site where I may get some more information


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
Message-ID: <90o00i$2oh$1@newsmaster.cc.columbia.edu>
References: <90l28b$r6e$1@news1.skynet.be>
Date: 7 Dec 2000 12:32:18 GMT
Organization: Columbia University
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Subject: Re: bidirectional parallel port terminal software for windows ?

In article <90l28b$r6e$1@news1.skynet.be>,
Serge Defever <sdefever@comports.com> wrote:
: Hello,
:
: does anybody know where I can find bidirectional parallel port terminal
: software for windows ? It should support 4-bit and EPP/ECP modes.
:
: Thanks,
: Serge

In Windows 9x the parallel ports support the serial port API and
can be used by any terminal emulation.  Use of 4-bit or EPP/ECP modes
is usually selected as part of the PCs BIOS configuration.

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * kermit-support@kermit-project.org

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals, comp.os.ms-windows.networking.tcp-ip
References: <x6Cf7.34224$vW2.15267444@news1.sttln1.wa.home.com>
    <3B7EAAC2.D51D8B72@rcn.com> <20010818_223500_rshu@stratagy.com>
Message-ID: <3B7F43CA.7AA095CE@rcn.com>
Date: Sun, 19 Aug 2001 04:42:51 +0000
From: Jim <microsyseng@rcn.com>
Subject: Re: comm/terminal emulation
         (was: 16-bit communication program for Win 3.1)

The file for TCP/IP which will work on Win 3.11 is

    win31b.exe  569001   10/6/96

The file vserver.386 needs to be updated as well

I am not sure if it will work on Windows 3.1--I rather doubt it--which
is why I suggested the original poster find a copy of Windows 3.11.

There is an upgrade from Win3.1 to 3.11 or Windows for Workgroups.
Along with 3.11, there are approximately 8 files that need to be
updated. I was able to locate my archives for that system, and it's
all there along with the Microsoft advisories.

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
Message-ID: <rhl18.1771$6n1.281712@news20>
Organization: Jump.Net
Date: Wed, 16 Jan 2002 14:20:05 -0600
From: vb <reply_to_group@please.com>
Subject: terminal emulator for PC talking to USB ports

For the Mac, ZTerm can talk to ports on USB.
Is there a PC program (hopefully freeware or shareware) that can do the same?

vb


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <rhl18.1771$6n1.281712@news20>
    <raO18.7083$He.119037@sea-read.news.verio.net>
Message-ID: <0OZ18.3764$6n1.411724@news20>
Organization: Jump.Net
Date: Fri, 18 Jan 2002 12:25:27 -0600
From: vb <reply_to_group@please.com>
Subject: Re: terminal emulator for PC talking to USB ports

The Expert <expert@gmx.co.uk> wrote:
>
> Organization: Jump.Net
> I think I recall one at Attachmate

"Joe Silagi" <joesi@wrq.com> wrote in message
news:raO18.7083$He.119037@sea-read.news.verio.net...

> What's connected to the USB port?


I would love to answer "Why does it matter?", but I have learned that is does
matter.

It possible to connect RS-232 terminals and modems to a PC USB by using a USB
to serial adapter like:

    http://www.keyspan.com/products/USB/usa19w/

 but it's no simple matter to
change old software to operate over the USB connection.

One new aspect is that the PC becomes a "host" and the device becomes a slave.

 This is much different then DTE and DCE.  You just
don't swap a few cable wires and chug along.

 There does not seem anything like
a simple terminal emulator for a PC to talk to a
device over the USB.  The reason has partly to do with the plug-and-play
complexities of the Winbloz PC and the complexities of
addressing devices on a muti-path bus.  Winbloz wants to know what your
connecting and it wants the *device* to tell it.

Oh, nevermind...

vgb


 //////////////////////////////////////////////////////////////////////////////


