DCC recorders are complicated devices. But the service manuals and datasheets that are available online give great insight into how a DCC recorder works in general. They also give many subtle hints about how we could teach them new tricks.

Here's a list of the things that I want to make my recorders do:

It will take a lot of effort to do all this, but I'm pretty sure the information to accomplish it is all publicly available. What I first need to do is figure out some details about how a recorder works, and find a way to improve it.

Third Generation DCC Recorders

The DCC-730 and DCC-951 "third generation" recorders were released around 1995, and by then, Philips were getting very good at making DCC recorders in a highly modular way. They released a System Description document that describes the Third Generation DCC system, and the following is roughly the same information in my own words, with extra focus on the parts that I need to use or modify for this project.

The heart of the 3rd generation recorder is the DDU-2113 Turbo Drive mechanism shown above. The DDU (DCC Deck Unit) is pretty much a standalone unit. In theory, if you would want to build a DCC recorder around a DDU, all you would need is:

Philips made two DCC recorders with the DDU-2113: the DCC-730 and the DCC-951. They also used the same electronics in the FW68 mini-set but because that unit doesn't have digital inputs and outputs, they left a chip and a connector unpopulated.

The block diagram above shows that all the essential electronics for an entire DCC recorder are on the DDU:

Let's have a closer look at the Digital Board.

The Digital Board: The Heart of the DDU

The Digital Board is on the back of the DDU and it's what connects the DDU to the outside world.

The most important chips on the board are as follows:

Buses on the Digital Board

MUP control buses

The MUP has three buses:

The L3 bus is a synchronous serial bus with 3 lines: Clock, Data and Mode. 

The datasheets for the chips describe each command very accurately; it's almost like the engineers at Philips wanted us to build a DCC recorder for ourselves :-)

Audio buses

Besides control buses, there are also three I2S buses:

How It All Comes Together

You should now have some idea of how the most important parts of the DDU work. For further details about parts that I didn't go into, see the documents that are linked in various places. You can also post a question or contact me of course!

As you may have figured out, the DRP and MUP are the most important chips on the Digital board. The DRP determines what goes on a tape, makes it possible for the MUP to extract information such as song titles and does a bunch of work "under the hood" to take care of formatting the tape and correcting problems at playback time. The MUP puts all the chips in the right mode and tells the deck controller to do the things it's supposed to do.

You could say that the MUP knows all the tricks that the DCC recorder can do. So to teach the recorder new tricks, you'd have to modify the program that's stored in the MUP. Unfortunately it's not that easy, for many reasons:

For now I think a better approach is to use the existing MUP for normal operations, and intercept when we want to do something special.

I am Locutus

The schematic gives some good hints about how it would be possible to use the MUP for normal operations, and switch it off to do special things: just put it to sleep. When the MUP is asleep, it goes off the L3 bus (and the other buses) and all pins go to high-impedance mode. A number of pull-up and pull-down resistors make sure that the other DCC chips are put to sleep.

The MUP goes to sleep when you send it a STAND BY command from the front panel (to be precise: when you send that command from the remote control). So the plan is to inject a STANDBY command into the Front Panel communication bus, just like the Enterprise crew did when they fought the Borg.

Once the MUP is offline, my microcontroller can take over the functionality of the MUP. Obviously this will take some reverse-engineering: I need to be able to take over (at least) the most basic functionality while the MUP is offline:

When the MUP goes offline, it's likely that it sends some commands to the Deck Controller and the chips to make them shut down in a coordinated way. Obviously I have to make sure that those commands never reach their target and that the MUP gets any expected responses to those commands. 

Can You Hear Me Now?

Once I have control over the buses that are connected to the MUP, I should be able to control the deck, and inject and extract text information via the L3 bus. But the audio doesn't go through the MUP, so to extract the audio from a tape or record new audio to a tape, I'll have to do other things.

Extracting PASC audio from a tape is possible with a modern microcontroller with an I2S bus: I would just have to lock the microcontroller to the DCC bus clock and connect the data to the sub-band bus of the DCC recorder. That's not too hard (though it will probably require soldering), but allowing my microcontroller to inject audio may be more difficult because the SFC is directly connected to the DRP and they determine which way the sub-band I2S bus flows.

Fortunately the data pin for the sub-band I2S bus on the SFC is on a corner, so maybe it will be possible to desolder a leg of the IC and connect my system to both the leg and the circuit board. That way my microcontroller is the boss over the bus.