Getting the 2B+D payload data out of a standard ISDN U interface transceiver chip like MC145572 is surprisingly tricky. The traditional digital side interface presented by these chips is either IDL or GCI, both of which are specialized interfaces invented just for this purpose (for ISDN BRI).

But wait, the microprocessor on the CopperRocket is an MC68LC302 which has explicit special support for both IDL and GCI. Wouldn't it then be a totally straightforward matter to connect the two chips with either of these interfaces (whichever one you like better) and be done? Well, not so fast.

The gotcha is that we are dealing with IDSL rather than standard ISDN. Both IDL and GCI are time-division multiplexed interfaces with specific time slots for B1, B2 and D channels, and the IDL and GCI support hardware in the 68302 (unchanged in the LC version) is designed to separate these channels as would be required in a standard ISDN application. Specifically, it is designed to route each channel to a particular SCC as programmed. But what if we want to merge the channels together to make IDSL rather than separate them? This is where the gotcha lies.

While the 68302 manual says that merging B1 and B2 by routing them to the same SCC is supported, no word is said about what would happen if one tried to merge the D channel as well. However, it is pretty certain that at the time when the classic 68302 was designed, no one had probably even thought of such an application. It is thus quite probable that the trick won't work.

I don't know whether CM had found out for sure that this trick wouldn't work or if they had simply chosen to err on the side of caution, but the CR201i hardware design does not use IDL or GCI to connect the MC145572 to the MC68LC302. Instead they have used the former chip's timeslot assigner (TSA) configuration and configured the latter for the PCM highway interface rather than IDL or GCI. (In the PCM highway mode the 302 takes two external inputs which indicate when one or none of 3 interesting time slots is active.)

In the TSA mode the MC145572 transceiver can put out a fairly arbitrary TDM frame instead of its standard IDL or GCI. The position of each channel in this frame is programmable, and there is also an auxiliary output pin (TSEN) which can be programmed to go low on particular time slots.

Here is how this mode is useful for IDSL: TSEN can be programmed to go low on just one particular time slot, or as an OR of any programmed set of time slots. (Well, not any combination: if both B1 and B2 are enabled, TSEN can't separate them, it's either on for both or off for both. But it doesn't matter for us.) Thus configuring the pin to go low on all of the active channels and wiring it to the 302 as an indicator of an interesting PCM time slot achieves IDSL functionality.

There is an additional gotcha that apparently this signal by itself doesn't satisfy the 302's timing requirements, and thus CM has done a kludge instead. They use an HCT74 flip-flop to generate the signal that actually goes to the 302, and the inputs to this flip-flop are a weird combination of the TSEN output just discussed, DCL (the bit clock) and FSR, the receive frame sync signal. The flip-flop's D input is tied to GND and the controlling inputs are the clock (rising edge trigger) and the async set (active low). The former is tied to TSEN and the latter is DCL gated by FSR. Weird, huh?

The only limitation imposed by this HCT74 kludge is that all active time slots must be consecutive and start at the beginning of the constructed TSA frame. Not any real functional limitation though, as the set of active channels is still arbitrary and they can be arranged in any order. Just something for us to keep in mind on the Hack-o-Rocket.