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.

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 audio to tape, 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, using Fourier transformation. The information that's generated here can theoretically be used to synthesize a signal that's identical to the source signal.

The "magic" of PASC lossy compression (which is the predecessor of MPEG-1 layer 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.

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 an MPEG-1 Layer 1 stream. The ADAS3 sends that stream to the SFC which forwards the data to the DRP.

The DRP generates a tape data stream that's divided into blocks and frames. Each tape frame contains 8192 bytes of PASC data, and 128 bytes of System Information (SYSINFO) data; the rest is used by error detection and error correction data. The data is encoded using the 8-to-10 encoding algorithm to avoid writing more than a few consecutive 0-bits or 1-bits to the tape. SYSINFO data includes copyright information and recording format information (such as whether the cassette was user-recorded or prerecorded), and also contains text information for prerecorded tapes. 

The result is a raw data stream that gets scattered to the 8 digital tracks on the tape. The scattering follows a fixed pattern so that if a tape dropout occurs, it's more likely that the error correction codes will be able to recover the missing data. The data rate per head is 96kbps; a total of 768kbps for all 8 data tacks. That's twice as many bits per second as the PASC stream!

The Write Amplifier (WRAMP) records the raw stream to tape. 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 4.76cm/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 PASC 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

When playing analog tapes, the recorder simply uses two of the DCC heads to pick up the analog signal. The RDAMP reads these and amplifies them as needed. They are processed through a Dolby noise reduction chip (not  shown 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. The L3 bus consists of a clock pin, a signal pin and a direction pin. The microcontroller sends synchronous serial bytes over the clock and data lines to give commands to the chips. Each chip has their own address. 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 the text data out on the User Data subchannel of the S/PDIF output, to be processed by an ITTS (Interactive Text Transmitting Service) decoder. There were never any DCC recorders that could decode the ITTS information but the DCC museum not only has a recorder with a (non-working) built-in ITTS decoder modification, but also an external  decoder (of which only a few prototypes were made), The external decoder only works with the first and second generation recorders and was used in mastering facilities to check if the ITTS information on prerecorded tapes was correctly formatted. We can only speculate as to why Philips never made it possible for consumers to decode the ITTS information on prerecorded cassettes.

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 simply 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 SCSI 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