Close

Introduction to the DCC-175

A project log for DCC Hacking

Reverse-engineering Digital Compact Cassette recorders

Jac GoudsmitJac Goudsmit 07/18/2018 at 03:450 Comments

It shouldn't surprise anyone that a DCC recorder is significantly more complicated than a regular cassette deck.

This article gives an overview of the general architecture of a DCC recorder, and the DCC-175 in particular.

---------- more ----------

The diagram above is the block diagram for a typical "third generation" DCC system (I may go into the generations of DCC later, in a different article). The parts that are marked in grey are only needed for recording. I copied the diagram from the SAA3323 / SAA2023 datasheet. The SAA3323 and SAA2023 Drive Processors (DRP) are functionally identical but the power supply voltage is different.

DCC Recording

To record analog inputs, an A/D converter or an S/PDIF digital audio input provides an I2S stream that represents the incoming audio. This signal is basically a synchronous serial version of the PCM data on the input. It can be monitored on the outputs of the D/A converter and S/PDIF outputs, but it also goes to the Stereo Filter Codec (SFC).

The SFC filters the incoming signal into 32 frequency bands. For each band it calculates how loud the frequency band is and what the phase is. The information that's generated here can be used to synthesize a signal that's exactly identical to the source signal.

The "magic" of PASC lossy compression (which is similar to MPEG-1) happens in the Adaptive Allocation and Scaling chip (ADAS3). This chip gets the full load of information from the SFC, again, via an I2S bus. For each of the 32 sub-bands, the ADAS3 receives 12 samples of 24 bits each, times 2 channels, for a total of 768 samples (18432 bits) per frame.

The ADAS3 chip uses tables and calculations to determine which frequencies are under the threshold of human hearing, and/or are masked by other frequencies. This is called a psycho-acoustic model. Based on this, it determines which frequency bands are more important and which frequencies matter less. The most important frequencies are encoded with more accuracy than the less important frequencies, and some frequencies may not get any bandwidth allocated at all. The result is a 384kbps PASC data stream over another I2S bus, which is basically compatible with an MPEG-1 stream. That stream is divided into frames of 420 bytes per frame. The ADAS3 sends that stream to the SFC which forwards the data to the DRP.

The DRP applies error detection and correction codes to the data stream, so that if bits can't be reliably read from the tape, it will still be possible to decode the music even if 1/8th of the data ends up missing. Then it applies 8-to-10 modulation (where every 8 bits are encoded as 10 bits in such a way that there are never more than a few 0-bits or 1-bits on the tape.

The result is a signal that gets encoded to 8 tracks on the tape, at 96kbps per head (768kbps total; that's twice as many bits per second as the PASC stream!). The Write Amplifier (WRAMP) takes care of this. The encoding of the bits at this point is very simple: the write amplifier either generates a positive or negative pulse in a small coil inside the head assembly (one coil for each track). and the pulse gets gets stored on tape as magnetization in one of two directions. That means that it's not necessary to erase the tape (neutralize the direction of magnetization): in the end, the recorded tape is entirely magnetized; some parts in one direction, some in opposite direction.

The auxiliary ninth track of DCC is also written by the WRAMP and the heads, but the main data tracks and the auxiliary track can be switched from recording to playback and vice versa separately. The aux track contains things like markers that indicate the start of a track. The data rate of the aux track is much lower than the data tracks (only 12kbps instead of 96kbps) so that it can be read even while the tape is going past the head at high speed, while the DCC player is searching for a track. The aux track can also be erased (unlike the other tracks); the head amplifier accomplishes this by sending positive and negative pulses to the head at double speed, generating a 192kHz signal that neutralizes the tape magnetization.

While recording, the capstan motor runs at a fixed speed of 3.78cm/s (1 7/8ips).

DCC Playback

In playback mode, the Read Amplifier (RDAMP) sends a small electric current through the Magneto-Resistive (MR) head to generate a magnetic bias that makes it possible to read the signals from the tape. The current is not strong enough to re-magnetize the tape. The magnetization of the particles on the tape cause the current in the heads to vary enough to pick up the encoded bits. Remember, both values 0 and 1 are encoded as magnetization, only in opposite direction; tape with neutral magnetization has no value.

The RDAMP samples the signals about 3.2 times faster than the original write speed, and multiplexes the amplified analog samples into a signal called RDMUX. This is sent to the DRP.

The DRP equalizes the samples and digitizes them. It figures out where each new bit on the tape begins, and then applies the 10-to-8 demodulation. Now the data goes through an error detection and correction matrix. The result is the original 384kbps stream that was previously generated by the SFC and the ADAS3 chip during recording.

The DRP also detects if the frames of data are coming in too fast or too slow, and generates a PWM signal for the capstan motor. There is buffering in the DRP to help compensate for speed variations in the mechanism.

The PASC stream leaves the DRP as yet another I2S signal, to the SFC. The SFC is in decode mode, so the ADAS3 isn't needed and is on standby. To decode the signal from to PCM, all the SFC has to do is to synthesize the frequencies of each band with the parameters from the PASC stream, and mix them together digitally into a PCM stream. That PCM stream goes to the I2S bus that's shared with the D/A converter and S/PDIF encoder.

Analog Playback

The earliest portable players didn't have separate heads to play back analog cassettes. They just used two of the DCC heads to pick up the analog signal. But all other players and recorders have separate heads for the analog tracks. The RDAMP reads these and amplifies them as needed. They are processed through a Dolby noise reduction chip (not in the drawing above) and, for portable recorders, a chip (also not in the drawing) that can amplify the signal to headphone and analog output signals. The headphone output has a volume control and an optional bass boost filter. The analog output is also connected to the A/D converter so that the S/PDIF encoder can generate a digital signal even when there's an analog cassette in the machine.

Communication between the Chips

All of the chips mentioned above are under control of a microcontroller. Each chip has 3 pins for the "L3" bus. The L3 bus consists of a clock pin, a signal pin and a pin for each chip that selects that chip. The microcontroller activates the selection pin of the chip it wants to talk to, and then sends synchronous serial bytes over the clock and data lines to give commands to the chip. To let the chips answer, the microcontroller holds the chip active while it sends clock signals. The chip's data pin is now an output and the microcontroller's data pin is an input.

When playing a DCC cassette, the DRP provides the microcontroller with a copy of the SYSINFO data that's part of the main data stream, and the AUXINFO data which is what's on the 9th track, The microcontroller can send that data out on the User Data subchannel of the S/PDIF output, to be processed by an ITTS (Interactive Text Transmitting Service) decoder. The DCC museum has such as decoder (of which only a few prototypes were made), but it only works with the first and second generation recorders. We're not sure at the time of this writing why this is the case. Philips made it possible for users to record and display their own song titles on third generation recorders (but not the portables); it's possible that they gave up on the idea of ITTS or ran out of time or out of ROM space to implement it, but it's also possible that they changed the ITTS output format slightly in such a way that the ITTS decoder of the DCC museum doesn't recognize the data anymore.

DCC-175 - The Precious

The DCC-175 is unique among DCC recorders, because it features a connector to which a computer can be attached. Philips sold the DCC-175 in combination with the cable (as "PCA11DC") but also sold the cable separately (as "PCA10DC"). The cable is also referred to as PC-Link or DCC-Link.

Not many cables were made; there was a shortage of them even before the DCC format was discontinued. The DCC-175 was only available in the Netherlands and the cable was pretty much impossible to find. And it wasn't possible to change a DCC-170 into a DCC-175 or replicate the cable: there was a custom chip in it to connect it to the parallel port of a Windows PC, and the 16-bit software used direct access to the parallel I/O chip to communicate with the custom chip, so it only works with Windows 98 and earlier.

But the service manual of the DCC-175 and the datasheets of the DRP and the microcontroller make it pretty clear that the cable is nothing more or less than a connection to a bidirectional synchronous serial port on the microcontroller, and a bidirectional connection to the I2S bus between the SFC and the DRP.

On the PC, Windows sees the plug as a plug-and-play device for which there is no driver. The documentation says that the printer port can be set to standard mode (not recommended), EPP or ECP mode. Someone who started on reverse-engineering the software and the plug in the 1990s (but never finished), found out that the custom chip may have been produced in cooperation with (or by) Shuttle Technologies, which is/was a company that produced parallel port interfaces for tape drives (which totally makes sense).

The microcontroller on the DCC-175 that controls the DCC chips, accepts commands from the control panel of the recorder but it also listens for commands from the PC. The PC can tell the recorder to do things such as:

The microcontroller stays in control of the DRP. The way that the PC and microcontroller communicate, is part of what I hope to find out in this project.

Future Plans

Obviously the DCC-175 is a unique device and it's very rare. Not quite as rare as the DCC-Link Cable but still. The initial plan is to reverse-engineer how the microcontroller and the custom chip communicate with each other. It's already clear that with current technology, it's probably easy to implement the same communication protocol on a Parallax Propeller. The Propeller can then be used to e.g copy all the audio from a tape to an SD card in PASC format, or even to send the PASC data over a serial connection (384kbps is not that hard to do in 2018).

Depending on the kind of reactions I will get to this project, and on how smooth things are going to go, I might continue from there in one of the following ways:

Discussions