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: 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 ----**----**----**----**----**----**----**----**----**----**----**----**---- 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: 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 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: 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: 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: References: NNTP-Posting-Host: po2.andrew.cmu.edu In-Reply-To: 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: References: 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: References: <761107686.2544.0@windsor.math.cmu.edu> 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 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: Sender: news@news.chalmers.se Nntp-Posting-Host: wagner.cd.chalmers.se Organization: Chalmers Computer Society References: 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 , Bill Davidsen wrote: >In article 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: 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: 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: Date: Tue, 08 Mar 94 21:46:01 EST References: 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: 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 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> Date: Sat, 9 Apr 1994 11:44:51 EDT Lines: 53 From: 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: Sender: netnews@netcom.com (USENET Administration) Organization: Cresta Systems, Inc. X-Newsreader: Trumpet for Windows [Version 1.0 Rev B final beta #1] References: 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@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: <42t17i$6k5@srvr1.engin.umich.edu> 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: <42t17i$6k5@srvr1.engin.umich.edu> <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. >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 ----**----**----**----**----**----**----**----**----**----**----**----**---- 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: <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 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 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 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" 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: NNTP-Posting-Host: pm4-1-s5-17.orf.infi.net Date: 4 Oct 1998 13:30:49 GMT From: Bill Creager 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 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: <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 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: Organization: Jump.Net Date: Wed, 16 Jan 2002 14:20:05 -0600 From: vb 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: Message-ID: <0OZ18.3764$6n1.411724@news20> Organization: Jump.Net Date: Fri, 18 Jan 2002 12:25:27 -0600 From: vb Subject: Re: terminal emulator for PC talking to USB ports The Expert wrote: > > Organization: Jump.Net > I think I recall one at Attachmate "Joe Silagi" 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 //////////////////////////////////////////////////////////////////////////////