Hi Lew,

first, an apology .. I've been neglecting this and most other echoes the
last 10 days, since getting back from Sydney with my new box, learning
about it and OS/2, and all that .. I guess you'll understand :)

 IS> Lewin would know a lot more about this, from the perspective of the maker
 IS> tuning those characteristics via the DSP, and about what's available to
 IS> the manufacturer who uses the DSP pretty well raw, like Netcomm, Dataplex
 IS> and a few others, and those who just bolt in the pre-coded 'solution'
 IS> best-guess stuff.  Then, how much access the USER has to play with it, by
 IS> published or possibly unpublished commands.

 LE> I found Rod's reply to this and searched back for your
 LE> message. First, no Rockwell-based manufacturer (including
 LE> NetComm et al) has access to the DSP. In the DPi-series
 LE> datapumps, the high-level controller has access only to DSP
 LE> RAM. Basically, you're given a memory map with a lot of
 LE> holes in it; you're told the functions of certain locations
 LE> in DSP RAM. Under no circumstances can you actually update
 LE> DSP code. You cannot tweak low-level protocol parameters,
 LE> it's simply not possible. I don't know exactly how much ROM
 LE> the datapump contains, but there's not a lot of RAM, and
 LE> even if there was a way to halt and restart the DSP at a
 LE> specific location, there isn't enough space to upload code
 LE> patches. So NO tweaking.

Hmm, ok.  I guess that keeps people from messing with what they're unlikely
to understand, at least ..

 LE> A _lot_ of stuff is implemented DIRECTLY in the DSP in that
 LE> unmodifiable code. For example, CLI-CND. The datapump can
 LE> detect an incoming CLI packet and will tell the host uC so.

 LE> The controller is there to handle interface with the host,
 LE> and to implement high-level protocols.

What about V.42 and V.42bis?  I thought they were addons, either using the
Rockwell code or yer own?  Is that what you mean by high-level protocols?

 ..> A surprising amount
 LE> is implemented in the datapump, retraining for example, cf.

Oh, that would have to be, being part of the physical layer protocol.

 LE> p6-2 of the RC288DPi Modem Designer's Guide (remember, this
 LE> guide talks ONLY about the 288DPi and NOT the AC firmware
 LE> which Rockwell supply, for "modem" read
"datapump" and for
 LE> "user" read "modem controller") :

 LE> === edited quote begins [I can't be bothered typing it all out] ===

[.. clipped and saved, ta.  I'll have a closer look sometime there's time ..]

I get the picture though - the manufacturer is effectively suggesting what
he wants to happen, rather than really implementing anything much.  Macros.

 LE> === quote ends ===

 LE> And that's just the tip of the iceberg.

 IS> I'd be surprised if both the Netcomm and the Sportster didn't have a way
 IS> to select the bit error rate (BER) at which fallforward and fallback

 LE> This is a controller-pushed feature and is
 LE> controller-implemented; the controller follows the
 LE> procedures above to initiate retrains. I don't know if
 LE> customization of this feature is in current NetComm ROMs,
 LE> but afaics it wasn't in the one I hacked (an oldish version
 LE> of the M11F firmware).

Which might explain something about why the Netcomms are among those modems
that seem reluctant to train up at really the right speed for the line
conditions, as Paul and Arthur were commenting on .. the disagreements
between the Motorola Lifestyles and the M34 rack modems being typical
examples, requiring BER changes to the Motorola to get around.  I've just
done a lightning scan through the last weeks traffic, though I missed a lot
..

Thanks for that.  I'll probably be asking you all sorts of hassly questions
about other things in the near future, but not so much about modems :)

Cheers, Ian

--- MaltEd 1.0.b5