Close

Analyzing, Please Stand By. Your Call Is Important to Us.

A project log for DCC Hacking

Reverse-engineering Digital Compact Cassette recorders

jac-goudsmitJac Goudsmit 08/19/2018 at 06:540 Comments

As I mentioned in the previous log, I found out that the microcontroller in the DCC-175 and the custom chip in the DCC-Link cable communicate in blocks of 32 bytes each direction. I've been wanting to set up a Propeller on a breadboard to do some deeper analysis but because it's crunch time at work, I haven't had time.

Anyway, I thought it might be a good idea to do a brain dump of some of the details of my findings, along with some pictures of the logic analyzer screen for reference. That way I'll have all the information gathered here once I start programming. I'll also show some timing diagrams from the 3rd generation chipset datasheets.

Warning: This might get a little dry, technical and boring so if you're here to see circuits getting soldered together (or breadboarded) and doing useful stuff, you may want to "sit this one out".

The Connector Itself

Before I dive into the electronics stuff, let's start with the connector that goes into the DCC-175. To my surprise, it was easy to find: It's the Hirose 3240-10P-C(50). It's still in production, and your favorite large online electronics store probably has them in stock!

On the original PCA10DC cable assembly, there is a shielded 10-conductor cable of about 1 meter (3 feet) between the two plugs. There's a ferrite bead on the cable near the Hirose plug that goes into the recorder. The cable has to be thin because the Hirose plug only allows a cable outer diameter of up to 5.4mm.

Now for the bad news: I looked at several online stores to find out how much it would cost to buy the same kind of wire and the short answer is: "You don't want to know". 10-conductor shielded wire is not difficult to find, even at the rather tiny specified maximum diameter, and it's also not that expensive per meter or foot, but unfortunately it seems that that exact cable is only available in large quantities. So if I would ever make this into a project that I'll sell, I might end up having to invest something like $1200 (UPDATE: the price has gone up to $1400 as of January 2022) for a roll of 1000 feet (304m) of cable. Ouch!

Once I get further along with the project, I'll have to look into this a little further. Maybe there are other ways to solve the problem. It might be possible to squeeze a slightly thicker cable into the connector (EDIT: Nope! The connector is really only big enough for a 5.4mm outer diameter. The 5.9mm cable that I got, didn't fit and made it impossible to put the connector together). Or maybe I'll be able to find an alternative connector that's a better fit for a thicker cable, or get the right wire in smaller quantities from a different supplier. I don't know yet. At least it's clear that it will be possible to make complete cables (well... without the custom chip) without the need to make any modifications to the recorder.

UPDATE: I found a different cable at a different supplier in January 2022. The cable should be thin enough and it's available in smaller quantities. I ordered some of it and will update this page again when it arrives.

Connections between DCC-175 and the PCB in the Parallel Plug

Inside the parallel port plug, the cable terminates in a connector that goes onto a 2x6 pin right-angle pin header with 2mm pitch on the circuit board. Pins 11 and 12 are not used.

In the Hirose plug on the recorder end, the conductors are connected in order of standard (IEC 60062) electronic color codes, but because there's no pin 0, the colors are "off by one": black (0) is pin 1, brown (1) is pin 2, etc. On the other end (in the parallel port plug), the wires are crossed, and connected as follows:

DCC-Link 2mm
header pin
DCC-175 pinColorSignal nameDirection
from recorder
11Black5VOut
210WhiteGNDGround
39GreyL3REFOut
44OrangeSI2In
55YellowSO2Out
63RedSBDAOOut
77BlueSBDAIIn
88VioletSBWSOut
96GreenSCK2Out
102BrownWAKEUPIn

5V and GND

The chips in the parallel plug have to get their power from somewhere, and there's no power output on a standard parallel port. So the recorder provides a 5V power supply to the plug.

WAKEUP

The PC pulls WAKEUP down for a short time to turn the recorder's power on.

Interestingly, the line is HIGH most of the rest of the time, but not quite always. I observed instances where it was LOW for short times while the recorder was on and working correctly (the picture at the top of this article shows a lot of aggregated pulses on the WAKEUP line). At this time, I don't know if these pulses are:

Either way, the extra pulses that I saw on the WAKEUP line seem to be random and appear to have no influence on the operation of the recorder or the PC. I'll ignore it for now and I'll assume that the extra pulses are unnecessary but harmless.

EDIT: The WAKEUP pin is simply used to turn the recorder on from the PC, and is kept HIGH during PC operation. It appears that the recorder either ignores the input when it's on, or it's an edge-triggered input. Pulling the input HIGH will switch the recorder on, but if the PC doesn't communicate with the recorder, it will turn itself off after the usual timeout, and then turn itself on again immediately.

SBWS, SBDAI and SBDAO

The I2S bus that transfers PASC compressed audio data between recorder and computer, is directly connected to the DRP and SFC. This diagram from the SAA3323 DRP datasheet shows how the PASC data is formatted:

The SBCL (Sub-Band CLock) is the time-base for the PASC stream. It's generated by the DRP and always runs at 768kHz, which is twice the 384 kilobits per second at which the stream is played and recorded. SBCL is not present on the DCC-Link cable. If it would be, there would probably be too many problems with analog distortion because of the relatively long cable, as well as problems with propagation delay and interference. So instead, the chip on the PC side has to recover the clock. That's pretty easy with a PLL (phase-locked loop) that uses SBWS as input.

SBWS (Sub-Band Word Select) runs at 1/64 the speed of SBCL, just like the Word Select clock on other I2S buses, and the first significant bit starts one SBCL clock period after each transition of SBWS. But unlike other I2S buses, the SBWS state doesn't correspond to the left or right channel, but rather indicates whether the encoded data contains the first 16 bits (SBWS=LOW), or the last 16 bits (SBWS=HIGH) of a 32-bit PASC "slot". Slots are always aligned on a tape frame, and L3REF helps to find the start of a tape frame; see below.

So during each half-period of the SBWS cycle, there are 16 bits of significant data, followed by 16 zero-bits. The PASC stream uses only half of the available bandwidth of the 768kHz bus, making up for the double speed of the bus.

In all DCC recorders, the SBDA line is bidirectional: In playback mode, the PASC datastream on SBDA comes from tape (in third generation recorders: the DRP) and goes to the PASC decoder (in third generation recorders: the SFC), and in recording mode, the data goes the other way.

But the DCC-175 is special, because the computer can also be a source and target for PASC data. To make sure that the PC and the chips inside the recorder can't put data on the subband I2S bus at the same time, the bidirectional SBDA line is connected to the PC using two separate uni-directional lines SBDAI (Sub-band Data Input) and SBDAO (Sub-band Data Output). The microcontroller controls which of the two is enabled (and only one of them can be enabled at a time). That way, if the recorder and the PC ever disagree about which direction the PASC data should flow (e.g. because of a software bug on the PC), no damage can be done.

L3REF

As you might guess from the name (because it starts with L3 instead of SB), the L3REF signal is technically part of the L3 bus, not the PASC I2S bus. Nevertheless, L3REF is used to synchronize the PC with the PASC datastream.

L3 is the protocol that Philips uses in DCC recorders and other equipment to let a microcontroller communicate with a relatively high number of chips. It's similar to an I2C (Inter-IC) bus but it uses multiple chip-select lines to allow the microcontroller to quickly select a slave chip instead of selecting the chip by address, as I2C does.

The DRP datasheet describes the L3REF signal as follows: "This active LOW output pin indicates the start of a time segment, it goes LOW for 5.2 µs once every 42.66 ms approximately and can be used for generating interrupts for the microcontroller. If a re-synchronization occurs then the time between the occurrences van vary." In other words: this signal can be used to synchronize the microcontroller (and in our case: the PC) with the PASC data stream. And it can be used to trigger the logic analyzer too.

The photo shows the trigger on the point where the L3REF signal goes from HIGH to LOW. The trigger on this logic analyzer is displayed as a red vertical dotted line, you may need to click on the picture to show it in large format and see it. I had the X marker (green) adjusted to the SBWS flank which happens 720ns earlier than the L3REF flank. I don't know yet if this timing is significant (EDIT: it probably isn't).

The O marker (yellow) is on the LOW-to-HIGH transition of SBDAO which happens 2.52 microseconds (one PASC cycle of 1 / 384000 second, minus the 720 nanoseconds, roughly) after L3REF goes low. As you can see, that yellow marker is pretty much in the middle of the L3REF pulse so yes, that pulse is about 5.2 microseconds long as the datasheet says.

The casual mentions of the timing of the L3REF signal are interesting. The actual number of bits in a tape frame (or time segment) is not directly mentioned anywhere in any available datasheet, but those numbers are important because the DRP can only be switched between playback and recording modes at the start of a time segment or tape frame (I don't remember which, at this time).

The PASC data rate is 384 kbps and the I2S bus runs at 768 kHz. It's probably not a coincidence that the specified 5.2 microsecond pulse length is pretty much exactly 4 clocks on the I2S bus, or 2 clocks of the real-time PASC stream: the actual duration of 4 / 768000 second and 2 / 384000 second are within 0.2% of 5.2 microseconds. So for now let's assume that L3REF is low for 4 clocks of the I2S bus, though we won't let anything depend on the actual pulse width.

The quoted "42.66 ms" interval for each time segment, divided by the bit time of 1 / 384000 second is 16381.44. It's very likely that there are actually 16384 bits, because 16384 is a round number in binary and 16384 / 384000 is 42 2/3 milliseconds. That means there are 16384 PASC bits in a tape frame. This is not explicitly mentioned in any public documentation. (EDIT: the DCC System Description document which was donated to the DCC Museum indeed confirms that a Tape Frame contains 8192 bytes or 2048 slots of PASC information, along with 128 bytes of System Information (SYSINFO)).

It surprised me a little that tape frames are not evenly divisible in PASC frames (in other words: PASC frames and tape frames are not guaranteed to be aligned, though each tape frame always starts at the beginning of a PASC slot), but in a way it makes sense: First of all, the PASC decoder could be developed without dependency on the tape format. Secondly, it was possible to use varying sizes of PASC frames, almost without limitation. And thirdly, this left open the possibility that DCC might store audio (or other media) in different formats in the (then) future. And it wasn't that difficult to implement: The Philips engineers just decided to put a slot with value 0xFFFFFFFF at the beginning of every frame, and carefully designed the rest of PASC so that that slot value could never appear anywhere else in a PASC frame.

SI2/SO2/SCK2

This is the bidirectional serial port of the microcontroller in the recorder. The clock (SCK2) is HIGH while idle, and signals are latched upon the LOW-to-HIGH transition of the clock. There are no startbits or stopbits. This makes the serial bus compatible with what's commonly known as SPI mode 3.

At 592.9 microseconds after the start of the L3REF pulse, the microcontroller starts sending a burst of clock pulses on SCK2. There are always 32 bytes with 8 databits transferred in both directions. When the PC has nothing to send to the recorder, it just keeps its data line (SI2) LOW during the entire time that there are clocks on SCK2.

The clock pulses are obviously symmetrical and have a period of approximately 2.64 microseconds, as shown above. This corresponds to the somewhat unusual baud rate of 378787.8 bits per second (not too far off from the 384kbps of the PASC stream but that might be a coincidence). I don't know if there's any jitter on this clock (I expect there is none), but any hardware that I will build, will not rely on the measured clock frequency too much, only on the fact that clock pulses at the correct rate are supplied by the recorder.

The interval between two bytes is shown in the picture above. It looks like the time between bits is about 6.6 microseconds, which is 2.5 bit times. Again, my hardware will not rely on this too much, but it gives me an idea on how to configure my time-outs.

The picture above shows that there are multiple bursts of 32 byte packets, but they don't occur at regular intervals (there are no SI2 clocks on the left side of the picture, i.e. just before the L3REF pulse). The software will have to measure how many packets are transferred between L3REF pulses.

EDIT: I found out later that there are 12 bursts of 32 bytes (384 byes total) of information per tape frame:

All of the above appear 4 times (with different data) during each tape frame. It's not yet clear what the sequence is (i.e. which of the 3 items comes first within a frame) and what data is in the recorder status/control packet.

The picture above shows an entire "packet" on the serial bus. I think this was while the recorder was in STOP mode. A 32 byte packet takes about 841 microseconds, and about 10 SBWS clocks. I wouldn't be surprised if it takes exactly 10 SBWS clocks but I didn't verify this.

Interestingly, the time interval between two 32-byte packets is also 841 microseconds and 10 SBWS clocks.

That makes the total maximum time to send or receive and process each 32-byte packet equal to 1.682ms as shown above. 

Some More Pictures, Taken in "Accumulation" Mode

You may have noticed in the previous pictures that "Accumulate" was on, but each picture was just a single run. The following pictures are where I let the analyzer run continuously, accumulating all the possible transitions which might help for timing analysis. I don't think timing needs to be accurate down to the microsecond or nanosecond but it might help to know the expected amount of jitter for things such as recovering the I2S clock and adjusting the phase of it to make sure that the PC can record to cassette successfully. Mind you, I didn't actually take pictures while the recorder was in Recording mode, where things might be different because the system might be locked to the incoming audio signal instead of the internal crystals.

Above: The average time from the start of the L3REF pulse to the first bit on the SBDAO line (recorder to PC) appears to be 125 microseconds.

Above: 10 bits on the I2S SBDAO bus add up to about 13.06 microseconds so one bit appears to be about 1.306 microseconds. Actually the bit length should be 1.302 microseconds (1/768000); I bet that inaccuracy is caused by me getting sloppy at putting the markers in the center of the transitions.

Conclusion

Unfortunately my analyzer isn't smart enough to interpret the signals on the serial port (as far as I know). It also doesn't have a lot of memory: I think it stores 4K samples per channel (8K when running in half-channel mode). This is where I'm going to need the help of a Propeller or something. It can probably also be done with other microcontrollers if you're reading along and want to try it at home -- by the way did you know the Raspberry Pi has an I2S bus for audio input and output? 

I'm going to set up a Propeller on a breadboard (actually I'll probably use a Propeller Flip) and write some software to analyze the serial port and the I2S port. Important questions that I want answered, are:

Discussions