There are two answers to the question: "What internal modems are compatible with VCS Async Models?

1. None.
2. Read the rest of this page.

Rather than list all the many modems that work and those that don't, we've chosen to treat you like a grownup and explain how to determine simply if a modem will likely function with VCS or not--and why.

First, a word about "the phone company." They're all digital; why do we subscribers get analog? The worst portion of any phone system is the copper wires that lead from beside your desk to the phone company's Central Office or CO. At the CO reside a great many analog-to-digital conversion devices. Once digitized, your voice (or the aquirrelly screech you may hear when a modem is connecting) is handled by various computers and typically your signal gets multiplexed (a techie term for mixed in an orderly way that can be figured out at the other end) with many others and sent through various high speed links (think optical fiber). The nearby (think a few miles) CO is part of a huge network of COs around the world. It is amazing that most phone calls work and even more amazing that 56K, DSL, T1s and other such things work most of the time.

If you think about what's inside a modem that plugs into a PCMCIA, PCI, or other slot, you will soon realize that a modem is a bridge between the slot and an RJ-11 phone jack. Nobody ever said there must be a UART in an internal modem.

By the way, here's a site that is all about modems and how they work and don't work. This site is rich with practical and expert information; site author Richard Gamberg has written everything that I've forgotten about modems. I heartedly recommend it if you're interested in why your 56K modem won't connect at 56K--as an example.

If you've ever designed computer hardware or circuitry, you may realize that you really don't need the formality equated to a UART (Universal Asynchronous Receiver Transmitter). All UARTs on the planet (for Intel machines) have exactly eight byte-sized registers. Each bit in each register has a well defined use and when a UART is designed that does not obey the "laws of the 16550" as to register use, people like you and I get into trouble.

Inside the UART are buffers (FIFO and others), shift registers, holding registers, and other logic:

• The transmit shift register takes 8 or fewer data bits at a time, inserts a start bit, optional parity bit, and 1 or more stop bits and converts the result to "one wire", that is to serial data.
• The receive shift register does just the opposite. It receives data on "one other wire," consumes the start and stop bits to tell it how to "frame" the data, uses the parity bit to check the validity of the data bits, and accumulates the data bits into a register that is "byte wide."
• The purpose of FIFO (First In First Out) buffers is to permit the UART to store or accumulate some number of bytes of data each time it has to interrupt the processor. For instance, your computer probably has [the equivalent of] a 16550 UART for each serial port. A 16550 contains 16 byte-size registers for the transmit side and 16 more for receive.
• Your machine's processor runs threads, not programs. Modern Windows systems achieve the illusion of simultaneity by preemptively switching threads (some of which are portions of your applications, some are the operating system itself) so fast that your eyes don't notice the fact that only one thread is actually running at a time.
• When the UART has accumulated some number (think 13 or 14 with 16550 UARTs) of incoming data characters, it must request an interrupt. A hardware interrupt, when the CPU gets to it, will then transfer all of the incoming data in the receive FIFO into your application's software buffer. The same sort of thing works in reverse for transmit.
• Timing is very important to proper function of a UART. What happens is your application sends some bytes (two) to the UART to tell it the number to divide into a high speed clock circuit to get the proper baud rate.

Next, let's peek under the hood of an external modem. There's some interesting stuff in there.

• The word "modem" stands for MOdulator-DEModulator. What that means is that a carrier signal is modulated in certain prescribed ways (based on standards, new designs, and whims) and an a priori requirement is that you have to have a compatible modem at the other end so that the type of modulation effected by your modem when sending can be unscrambled (demodulated) at the other end.
• In addition to modulating [a carrier signal of a particular frequency] and demodulating [a different carrier frequency], modems also understand what is called the "AT" command set. It turns out that there are many AT command sets but to lend a bit of sanity to the world, there is a subset of all AT command sets that overlap so that you can depend upon most basic operations like "ATZ" means reset, "ATDT5551212" means use the touch-tone dial method and dial 555-1212, whoever that may be.
• The modem needs to connect with at least two devices: (1) the phone jack on the wall, and (2) your PC or some other device capable of interfacing with a modem. To keep it simple, assume PC. The connection between your PC and external modem is a modem cable which ends up connecting a physical UART in your PC with circuitry that either is another UART or logic that behaves like one. So, the data flowing through the modem cable consists of serial transmit and serial receive data, plus various control and status lines.
• Let's pretend that I just explained (using 10,000 or more words plus a bunch of diagrams) the circuitry that encodes or modulates a signal that a like modem can understand--and that which understands and converts received data into digital form. The good news it it works most of the time.
• Accessing a UART depends upon the existence of a certain set of registers in a certain location in I/O address space and a certain IRQ; what you need is to come up with a way to convert "PCI" to "RJ-11." It's obviously more complex than this--there needs to be codecs and transformers and whatnot that provide the types of modulation and other characteristics that a typical (e.g. v.92 in today's world) modem presents. Your circuitry also needs to translate and buffer the signals on the PCI (or other) bus, provide data compression and buffering and all the other goodies that modems have today. Modems are commodities. Some of us can remember when they weren't, but the point is, the technology is mature, so what you do as a modem developer has little to do with obeying the laws of 16550 or other UART architecture. UARTs are for a whole 'nother purpose. They're for serial communications, and although broadly speaking, that's what an internal modem does, it does so in a quite different way. You could say, "well, they both communicate characters over some kind of link, so aren't they the same?" The answer is "yeah, and a bus is like a railroad train, they both take you from point A to point B but in quite different ways."

  The prototypical example of a non-UART internal modem is the "Win Modem" devices that were put on the market in the late 80s at far lower prices than traditional (e.g. D.C. Hayes) external modems and a few now obsolete internal modems. The Win Modem was a bridge between the ISA (and later PCI) bus and a phone cord. The developers knew they weren't going to be connecting to anything that related to a UART. By implementing some of the logic in software, they completely bypassed the UART idea.

  Boiled down, the truth is that your chances of winning the lottery are better than finding a PC or laptop with an internal modem that IS compatible with VCS.