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".

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

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". The cable is not difficult to find, even at the 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 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. 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 without the need to make modifications to the recorder.

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, 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. 

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. 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/32 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 PASC "slot".

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 interesting part of L3REF is what it synchronizes with. I once wrote a program to convert files from the DCC-Studio program from PASC to MPEG by removing the start byte and removing the padding bits (available here), so I knew that PASC packets are always 420 bytes (105 slots) long. so when I connected the DCC-Link plug to my logic analyzer, I assumed that L3REF was occurring at the start of each PASC packet. But it's not: L3REF indicates the start of a time segment and the DRP datasheet reveals (indirectly) that there are 4 time segments in a tape frame.

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.

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 kHz 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 4 x 16384 = 65536 PASC bits in a tape frame. This is not explicitly mentioned in any public documentation.

It seems illogical to have tape frames not be a multiple of a PASC frame. It makes it so that when the DRP switches from playing to recording, it may do so in the middle of a PASC frame. That means at playback time, a resynchronization of the PASC chip is almost always (3359 times out of 3360) necessary at the point where the tape goes from one recording to the next. So there will probably always (or almost always) be a tiny dropout in the output of the DCC recorder when that happens. But the dropout is something on the order of 8ms so I guess the Philips engineers figured that would be acceptable.

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. 

At 592.9 microseconds after the start of the L3REF pulse, the microcontroller starts sending a burst of clock pulses on SCK2. There are apparently always 32 bytes with 8 databits transferred in both directions With a synchronous serial port like that, there's no need for start bits or stop bits so all bits are data. 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. 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 clock frequency too much.

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.

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 yet.

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