It appears that CM's original prototype development of their SDSL transmission technology (prior to integration into their amazingly complex CopperEdge DSLAM) was done on a platform similar to their CopperRocket Ethernet bridge CPE, and that the latter is actually a close derivative of their original prototype platform. This conclusion has been drawn from our reverse engineering of the CR201s firmware.
It is particularly noteworthy that CM SDSL CPE supports HTU-C mode
operation in addition to HTU-R, meaning that CM SDSL HTU-C
is not
necessarily a DSLAM.
CM's SDSL module for Netopia
provides this support in a quite open and documented manner: Netopia's
configuration menus allow the user to select the operation mode, and when
the HTU-C mode is selected, an additional option becomes available to
select the speed.
However, this HTU-C mode support also exists on the CopperRocket, although
it is unclear how it would get invoked.
It appears that what has eventually become CopperRocket 201 SDSL has not always been a configurationless DSLAM-controlled slave unit, and that at one time there were some switches connected to the MC68LC302 microprocessor's GPIO pins selecting different operation modes. The numerous unpopulated footprints on the CR201s board are also likely related to this design's past use as the SDSL prototyping platform, perhaps somewhat similar to our OSDCU.
PA4 is an input indicating what kind of hardware it is. 0 corresponds to our familiar CR201s and 1 corresponds to some earlier prototype hardware (see below).
PB<11:9> are rather interesting inputs. They are used as a group and
appear to have been DIP switches at one point. If HTU-C operation gets invoked,
however this happens, the code read from these inputs selects the data rate.
Also if the code on these inputs is 0, a routine that is clearly CM's modified
version of _BtMain() performs the ERLE test at all supported data
rates in turn.
One would also expect this code to select between the normal HTU-R and HTU-C
operation, but this appears not to be the case.
If pin PA4 reads as 1, the firmware expects some hardware different from our familiar CopperRocket. The processor clock is expected to be 24.000 MHz instead of 24.576 MHz and the serial ICD2053 control for bitpump symbol rate selection is replaced with direct parallel control of some multiplexors. Clearly the 4.096 MHz reference clock and ICD2053 did not exist on that hardware.
The set of bitpump symbol rates on the prototype hardware is different from that supported via ICD2053. PB3 and PB5 control multiplexors feeding the clock to the bitpump, so a total of 4 data rates are possible on a given hardware platform.
The bitpump symbol rate selection code for the prototype hardware looks like this:
switch (datarate) {
case 160:
PB3 = 0;
PB5 = 0;
break;
case 208:
case 392:
PB3 = 1;
PB5 = 0;
break;
case 320:
PB3 = 0;
PB5 = 1;
break;
case 416:
case 784:
PB3 = 1;
PB5 = 1;
break;
}
Note that the code drives the same external signals for 208 and 392 kbps, and for 416 and 784. Obviously the actual bitpump clock selected by these signals can only be one or the other, so there must have been two different versions of this prototype hardware: one with 160/208/320/416 kbps data rates, and another with 160/320/392/784 kbps. I suspect that they correspond to Bt8960 and Bt8970 bitpumps, respectively. It's also evident that PB3 selected between two different clock sources while PB5 enabled or disabled a divide by two stage. I believe that this is the origin of the numerical relation evident among CM data rates which come mostly in pairs of two rates related by a factor of two.
Note the 392 kbps data rate that is not supported on the production hardware. For contrast, the data rates supported by this firmware version via ICD2053 are 160, 208, 320, 416, 784 and 1040 kbps.
As with all historical speculations, all we can do is guess, but my guess is that IDSL was implemented somewhat grudgingly and as somewhat of an afterthought in order to go through ISDN U-repeaters and loop carriers. It should definitely be a safe guess that CM's main emphasis was on SDSL. Also note that CM SDSL (not IDSL) can be turned down to 160 kbps (undersold by CM and ISPs as 128 kbps), so IDSL is completely unnecessary except for going through those ISDN repeaters and loop carriers.
On the basis on these observations I venture a guess that SDSL was the only game in town during the early prototyping phase, and IDSL came into the picture a little later when most of the prototyping was over. Also note that CR201i has fewer unpopulated footprints on the PCB than CR201s, although it still has a few.