NEC uPD7201 misfeature, and V.14 (was Re: NEC uPD7201C Datasheet, Pinout?)

The NEC uPD7201(A) and Intel 8274 have a misfeature that makes them almost unusable with modems that employ synchronous modulation (which is almost all common PSTN modems at bit rates of 1200 bps or higher, except bell 202 and V.23), except when an error control (e.g. MNP or V.42) used between the modems and flow control is used between the modem and the 7201/8274. The problem is that due to rate mismatches between the hosts, and between the host and the modem's sychronous modulation, the receiving end modem may receive data at a slightly higher rate than it can be sent over the asynchronous serial line to receiving host. In order to deal with this, the receiving modem is allowed to send the characters to the receiving host with a stop bit that is shorter than usual. The stop bits can be as short as 7/8 of a bit time, or (optionally for an extended signalling range, which I've never actually uses) as short as 3/4 of a bit time. This stop bit shaving is part of the ITU-T V.14 standard. Most UARTs don't have any problem with it, as they typically only sample the start bit at the middle of the expected bit time. However, the 7201/8274 looks at at least one sample in the bit time, and will consider a shaved stop bit to be a framing error, which IIRC causes the loss of at least the next character and usually multiple consecutive characters. This was a huge problem with 1200 bps and 2400 bps modems on the AT&T 7300 and 3B1 "Unix PC" before the error control protocols (MNP or V.42) became commonly available in modems. I learned far more than I (n)ever wanted to know about V.14 when I worked at Telebit, especially when I was in charge of adding Appletalk Remote Access Protocol (ARAP) support to the NetBlazer router. ARAP used MNP 3 and V.42bis compession (a non-standard configuration) on the Macintosh, and required that any error control (MNP or V.42) and compession be disabled in the modem. This was done because Apple engineers found at the time that hardware flow control between the Macintosh and commodity modems was unreliable, due to limitations of both. We were implementing a multiline ARAP server on the NetBlazer router and didn't have enough CPU power to do compession for more than a few lines. Since we only officially supported use of our own modems on the NetBlazer, the solution was for us to implement the unusual combination of MNP 3 and V.42bis in our modems (T1600, T3000, and WorldBlazer), and rely on reliable flow control between the router and the modem. Running V.42bis compression used nearly all of the available CPU cycles of the modem. We also had to deal with another aspect of V.14, stop bit deletion, which happens when the async data to be transmitted is overspeed with regard to the modulation. It allows the transmiting modem to completely discard the stop bit of up to one out of eight consecutive characters (one of four for dxtended rate), and the receiving side has to reinsert them. Our modem used an SCC channel of the MC68302 to send clocked asynchronous characters to the DSP bit pump (when not using V.42 error control, and V.42 is not used when dping MNP 3). Unfortunately the SCC channel doesn't know about V.14 stop bit deletion (or the corresponding reinsertion on receive), so the SCC has to be used in "raw" mode rather than clocked asynchronous mode, which means that the control CPU has to run a software UART to convert the character stream to a suitable raw bit stream for the SCC. A softwate UART is a piece of cake, you might say, and normally you'd be right. Unfortunately the modem engineers had written the world's fanciest, all-singing, all-dancing software UART, which took nearly all of the CPU time of the control processor. Which was normally fine, since you never used V.42bis compression over an asynchronous data stream over the synchronous modulation. Except, of course, when you're running V.42bis compression over MNP 3 error control to support ARAP. I offered to write a more efficient software UART, using under 10% of the CPU instead of over 70%, and the modem engineers claimed that it couldn't be done. The fundamental problem was that their software UART was in fact doing everything a single bit at a time. To do it efficiently, you do as much as possible a byte at a time, using a few kilobytes of data tables to assist. Another problem was that the modem control code was written as a series of tasks that all were called in round-robin sequence all of the time, whether there was anything to do or not. There was no easy way to determine CPU utilization because you couldn't do it as the complement of the idle time because there was no idle time to measure. Even when it was doing nothing it was running full-tilt. I'm told that eventually Apple switched from their wacky proprietary ARAP protocol to PPP, with the modem doing normal V.42 error control and V.42bis compression, but by then I had moved on to other projects that were less Sisyphean. Somewhat by coincidence, before working for Telebit I worked at Apple doing QA for (among other things) the Macintosh MNP 3 and V.42 drivers used by Appletalk Remote Access, then known by the codename "976". Eric