1

When first modems for PCs started to appear in the USSR in late 1980s, they usually were in the form of an ISA card, and supported a bare minimum of the Hayes AT commands. Given the quality of Soviet phone lines, and, most importantly, pulse dialing which introduced noise in all wires in a bundle, using such modems without error correction at speeds greater than 300 baud was next to impossible.

At the time modems with hardware error-correction (MNP) support were quite expensive; I remember that for quite a while our office had a cheap 1200 baud modem card and an MS-DOS MNP driver (MNP.SYS or some such, not particularly large, maybe a few Kb) which allowed to connect to the DEMOS's MNP-capable modem in the error-correcting mode.

Reading about the Microcom Networking Protocol, I don't quite understand how the software driver was able to negotiate the protocol with a "dumb" modem:

After connection to the remote modem, Microcom modems played a special tone into the line and listened for a response; if a proper tone was received in reply, the modems entered their error-correcting state.

How exactly did that software MNP driver work?

Improve this question
1
  • I have updated the Wiki article with the handshaking details. Lacks the part about the protocol selection - blame the ITU's docs.
    – Maury Markowitz
    Commented Jan 20, 2019 at 14:02

1 Answer 1

Reset to default
6

(Caveat, this is from memory)

After connection to the remote modem, Microcom modems played a special tone into the line and listened for a response; if a proper tone was received in reply, the modems entered their error-correcting state.

Completely and utterly rubbish. There was no special tone. It was a bunch of characters, some of them encoded in unusual manner.

Steps were as follows:

  • Calling modem calls
  • Called modem accepts call
  • Physical connection will be established (using various means to identify the speed)
  • Connection established

  • Caller sends DC1(e) X'FF' [X'FF'] DC1(o) X'FF' [FF]

    • DC1 is the ASCII device Control 1, X'11' (*1)
    • DC1(e) is DC1 with even parity
    • DC1(o) is DC1 with odd parity
    • X'FF' is 8 bits of one - send once or twice.

  • Called modem answers either with

    • ASCII 'EC' if error correction is available, or
    • ASCII 'E0' if error correction is disabled, or
    • Not at all if the called modem is not capable of error correction
  • This is followed by further handshake to define the level of correction and other parameters.
  • Agreed parameters are set (like synchronous communication, framing, etc.)
  • Framed communication starts

The whole protocol was a driver layer atop an existing connection below a user side transfer.

All an MNP driver (for a non-MNP-modem) had to do was to handle above sequences ahead of the application - and ofc, after establishing an error corrected connection manage the packetization, retry and so on.

*1 - Also known as CTRL-Q or XON - Normally used to release a stopped connection (XON/XOFF protocol), here used as a trick to create a noticeable message even if there is some driver handling XON/XOFF on low level. Sending it with parity on and off was meant to get it over in an identifiable manner (as parity error) at least once, no matter what parity was chosen beforehand.

Improve this answer
11
  • Did MNP modems use conventionally-framed octets for everything, or did they use some other bit-level encoding that avoids the 20% overhead traditionally spent on start and stop bits?
    – supercat
    Commented Jan 18, 2019 at 21:20
  • @supercat MNP3 means switching to synchronous transmission (I mentioned it, didn't I?), thus eliminating start/stop bits, resulting in like 105% thruput, despite additional framing data/protocol overhead. MNP4 added variable packet size, MNP5 compression and so on...
    – Raffzahn
    Commented Jan 18, 2019 at 21:30
  • Ah--I'd missed the parenthetical "like synchronous transmission, framing, etc". Could software-based MNP modems typically have a means of sending unusual framing patterns over the wire, or did they use conventional UARTs at the native transmission speed which required them them to negotiate conventional framing?
    – supercat
    Commented Jan 18, 2019 at 21:36
  • No idea. Some UARTs can be programmed that way, others can't. But I guess it will be a task to make that happen. Then again, the most important steps are taken with MNP-3 already. Error correction, which is important for bad phone lines, and variable block size, which dies help a lot for asymetric transfer. We are talking slow lines anyway - at this technological stage having a reliable transmission is way more important than a fast one.
    – Raffzahn
    Commented Jan 18, 2019 at 23:41
  • 1
    @LeoB. Not sure what you mean. A (simple) modem doesn't care about synchron or not. It just turns signal level into tones. It's the task of the serial interface to deliver 'new' bits within the timing neccessary to stay syynchronized. A modem capable to do MNP-4 in turn switches during protocol negotiation on its own, continuing to talk asynchron to the PC, while doing synchronus timing on the line.
    – Raffzahn
    Commented Jan 19, 2019 at 22:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .