noring@netcom.COM (Jon Noring) (05/21/91)
Hello, A couple of weeks ago, I posted a request for info on high-speed modems (9600+ baud) for my pc. My main reason for wanting a higher speed modem (I now use a 2400 baud Everex internal w/MNP5) is for file downloading from BBS's and from Netcom. I received a couple of replies (thanks to those who replied), but I was hoping for a little more feedback (there were five others who replied wanting to know what I found out, but I have little to report). Can I conclude that most of you guys (and gals) don't know much about the subject to comment on it? Anyway, I've begun to educate myself on the subject. The other day, while looking at the articles on asynchronous communications in PC Magazine of April 30, 1991, I came across an article entitled "The 16550A UART: Breaking Old Bottlenecks", with the summary: "FIFO.COM can help you activate the UART buffer on your side of a high-speed link". Included with the article was a DEBUG script for FIFO.COM, a program that activates the 16550A UART's FIFO buffer. Overall, the article gave me the impression that I should have a 16550A UART (along with appropriate communications software) if I get a high speed modem. I ran FIFO.COM on my 386-33 pc (Omnitel motherboard) and the program said that I didn't have a 16550A UART, rather that I had an 8250. The main question: Is it really worthwhile replacing my current 8250 UART with a 16550A when I get a 9600+ modem, or are the gains minimal? (of course, I'll have to make sure that my communications software fully takes advantage of the 16550A UART). Any help out there would be most appreciated. -- ============================================================================= | Jon Noring | noring@netcom.netcom.com | "The dogs bark, but the | | JKN International | IP : 192.100.81.100 | caravan moves on." | | 754 Catalina Drive | Phone : (415) 294-8153 | "Pack your lunch, sit in | | Livermore, CA 94550 | V-Mail: (415) 862-1101 | the bushes, and watch." | ============================================================================= Disclaimer: The opinions expressed are those of JKN International. I own it. "If you make $50,000 today, you have the same buying power as the average coal miner did in 1949, adjusted for taxes and inflation," John Sestina, nationally recognized Certified Financial Planner; quoted in 1987.
rdippold@cancun.qualcomm.com (Ron Dippold) (05/22/91)
In article <1991May21.163229.6631@netcom.COM> noring@netcom.COM (Jon Noring) writes: >I ran FIFO.COM on my 386-33 pc (Omnitel motherboard) and the program said >that I didn't have a 16550A UART, rather that I had an 8250. > >The main question: Is it really worthwhile replacing my current 8250 UART >with a 16550A when I get a 9600+ modem, or are the gains minimal? (of course, >I'll have to make sure that my communications software fully takes advantage >of the 16550A UART). If you are multi-tasking, yes. I have a 386/33 as well, and find that the 16550 eliminates an irritating problem I have when I'm running at 14.4K in which switching to/from the communications task's window can louse up the transmission. The program immediately catches it, but it's still irritating. The FIFO on the 16550 gives DesqView / Windows more time to do its swap to screen. In addition, the communications task does not load down the system as much as it used to. This only happened to me at 14.4K, usually, but I'd say if you are getting a 9600+ you should get the fast UART. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
rdthomps@vela.acs.oakland.edu (Robert D. Thompson) (05/22/91)
In article <1991May22.000143.3599@qualcomm.com> rdippold@cancun.qualcomm.com (Ron Dippold) writes: >In article <1991May21.163229.6631@netcom.COM> noring@netcom.COM (Jon Noring) writes: [ stuff deleted ] > >If you are multi-tasking, yes. I have a 386/33 as well, and find that the >16550 eliminates an irritating problem I have when I'm running at 14.4K >in which switching to/from the communications task's window can louse up >the transmission. The program immediately catches it, but it's still >irritating. The FIFO on the 16550 gives DesqView / Windows more time to >do its swap to screen. In addition, the communications task does not load >down the system as much as it used to. > Can anyone provide information on how to write a communications application that will support the 16550A? The reason I am asking, is because someone had said in a previous article that you can use the 16550A with "the appropriate communications software" Also, I was told a while back about a windows driver for the 16550A - WHERE IS IT/WHERE CAN I GET IT? Thanks in advance...Regards |(8> --- Robert rdthomps@vela.acs.oakland.edu
root@zswamp.uucp (Geoffrey Welsh) (05/23/91)
In a letter to All, Jon Noring (noring@netcom.COM ) wrote: >The main question: Is it really worthwhile replacing my >current 8250 UART with a 16550A when I get a 9600+ modem, >or are the gains minimal? If your system works fine with your 8250, then you don't need a 16550A. Although the 16550 can reduce the CPU overhead of interrupt service, the real effect is, as you say, minimal. However, there are many systems which won't work reliably -or at all- at 9600+ bps, and a 16550A can usually cure the problem completely. Some things which *may* cause problems with high speed serial I/O (problems which will be solved with the use of a 16550A): - CPU simply too slow for baud rate (especially affects 4.77 MHz XTs) - 286 changing from protected to real mode (to access extended memory from DOS, or returning to OS/2 or QNX from a DOS compatibility box) - Perstor ARLL controllers (or other devices with long DMA sessions) - Multitasking None of these spells sure death for high speed serial I/O; if one or more applies to you, you may be able to get away with your 8250... but you're in a 'high risk group'. >(of course, I'll have to make sure that my communications >software fully takes advantage of the 16550A UART). Any 8250 driver that is extremely well-written (i.e. takes into account the possibility that a character might arrive while the routine fetches the one that caused the interrupt, and therefore should also be fetched immediately) will work with a 16550A with buffers enabled. Unless your software re-initializes the 8250 (Telix does, but it's 16550-aware), you'll be able to enable the buffers beforehand using a program such as FIFO.COM and reap the benfits. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
chrisb@pro-permian.cts.com (Chris Bagwell) (05/24/91)
Can anyone provide information on how to write a communications application that will support the 16550A? The reason I am asking, is because someone had said in a previous article that you can use the 16550A with "the appropriate communications software" -------- [End quote] The easiest way I now to support the use of FIFO's is to use a fossil driver, such as X00.SYS. They usually have an option to use FIFOs. Of course, if you were writting your own communication routines then you would need to find the code to turn it on some where. I've never seen that. Its always been easier for me to implement fossil drivers to handle to hard work and let me do the easy stuff [grin]. ---- ProLine: chrisb@pro-permian Internet: chrisb@pro-permian.cts.com UUCP: crash!pro-permian!chrisb ARPA: crash!pro-permian!chrisb@nosc.mil
martelli@cadlab.sublink.ORG (Alex Martelli) (05/24/91)
rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes:
...
: Can anyone provide information on how to write a communications
: application that will support the 16550A?
(Software-reuse fanaticism warning:-) Grab a copy of the appropriate FOSSIL
driver, such as the BNU TSR program for Dos, from your nearest Fidonet node,
and program to its interface, which is very simple; IT will support 16550's
FIFOs for you. I think you can also find BNU on simtel.
Similarly, if you're on Unix, grab the FAS208 ('Final Async Solution') device
driver, and configure *that* into your kernel; then, in your application,
just read and write the /dev/ttywhatever - FAS will exploit the 16550 itself.
In general, appropriate support for clever (or braindamaged, for that matter)
hardware is in the *device drivers*; *application* programmers should be able
to stick to *application* concerns...
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).