(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.

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

Steps where as follow:

• 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 synchronus 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), her used as a trick to create a noticeable messate 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.

(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.

(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.

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

Steps where as follow:

• 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'

• 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.

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 handle paketization and so on.

(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.

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

Steps where as follow:

• 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 synchronus 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), her used as a trick to create a noticeable messate 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.