I fixed a few problems in the Synchronous Serial capturing program that catches the output of the microcontroller in the DCC-175, and behold: this was scrolling up my screen while I was playing my Grace Jones - Island Life prerecorded cassette!

Not So Fast!

Okay, there still seems to be a problem where every once in a while it misses a byte. I don't know why this happens, it could be interference. I'm sure my non-shielded wires don't help, and it's possible that, even though output buffers are used for the output lines in the DCC-175 computer connection, they might not generate enough current in some cases to draw the Propeller inputs low or high. Or maybe there's something that I can do about my timing parameters to prevent this.

Try the Veal: Wait, There's a Menu???

The titles of the last two songs on the cassette are clearly visible (and so was the rest of the track list): "9 MY JAMAICAN GUY" "10 SLAVE TO THE RHYTHM" but there's more to see here: "MAIN MENU" "1 ALBUM TITLE" "2 TRACK LIST"...

Those last texts would have totally bewildered me a few years ago. What is this strange information that looks like it's an interactive menu, and why is the DCC-175 sending it to the computer?

The answer is that this is the Interactive Text Transmission Service (ITTS) data that's stored on every prerecorded tape. Prerecorded tapes usually mention this on the J-card: they tell you they contain "DCC-Text" data that can be shown on TV if you have a compatible DCC recorder. No such recorder was ever available to consumers, but Philips made prototype ITTS decoders that could be connected to early DCC recorders to show the information so that mastering facilities could verify that the DCC-Text information showed up as expected.

The ITTS information is formatted according to the ISO-61866 standard. I have a copy of that standard, and it's expensive and big. I can't share the standard here because of copyright, but as I understand, the way that the data is formatted is similar to CD-Text. I strongly suspect that there are lots of things in the standard that existing prerecorded DCC tapes don't use, but because the recorder basically only acts as a device to pick up the information and spew it out to a decoder, the standard can be any size and there can be any amount of features, and the recorder couldn't care less. Making a decoder for ITTS is probably difficult (and that might be why Philips never went through with it) but it's not impossible. It may happen one day, but that's a whole different story.

Decoding All the Bits

The DCC Museum recently found a PDF online that might help with decoding the data. The document is called "Technical Guide Volume 31: Auto DCC Technology" and it pretends to be a service manual for the Panasonic CQ-DC1 car stereo system with DCC mechanism, but contains a HUGE amount of information about the inner workings of DCC, probably copy-and-pasted from the DCC specifications. And it looks like Page 27 has information about how various information such as time codes and song titles are stored in the AUX track. This could be the Rosetta Stone that could help me decode the information that the microcontroller spits out, but I expect that there's more about the data format of the synchronous serial port, since it also gives the computer information about the state of the mechanism (Play, Stop, Wind etc.) and possibly other things.

EDIT: The DCC System Description, donated to the DCC Museum, contains the official information.

Lather, Rinse, Repeat

When I look at the myriads of data scrolling by on my terminal emulator screen, there are a few things that stand out:

• When playing a self-recorded cassette, there is almost no data at all: Most bytes from the recorder are zeroes. When there's a marker (recorded with the DCC-Studio program), I can see the song title scroll by but then it gets mostly quiet again. It's like the Borg were all told to go to sleep and the voices get really quiet
• It appears that when the recorder has nothing to report, it just sends the same data over and over. Obviously this is by design. Probably the microcontroller sends a designated buffer based on interrupts and/or timers, and that part of the code doesn't have time to decide whether it already sent something. On the other side, the PC can probably detect where the data belongs "in the big picture", and stores anything it gets. It reminds me a bit of how Teletext works/worked: TV's would just show the lines of the selected page but all pages would be transmitted by the TV station continuously.
• It's not clear where data begins and how long the blocks of data are. I already know that data is transferred in packets of 32 bytes but it looks like those packets are grouped together. But just like other things in the world of DCC, things don't necessarily make sense at all levels; for example you might expect that packets are in groups of 4 because there are 4 tape blocks to a tape frame, but no. This will take some research. EDIT: There are 12 blocks of data in each tape frame, with 4 times a group of 3 packets containing 28 bytes of recorder data, 36 bytes of AUXINFO and 32 bytes of SYSINFO. Thanks Vick for pointing this out in the comments!

So Where Am I Going?

The dropped bytes are a potential problem, I should figure out what goes wrong there. Maybe the recorder really is sending fewer bytes sometimes? Is it an electrical problem? Maybe the tape I'm using is too damaged or my heads weren't clean? I should try cleaning the heads and try some other tapes to see if the dropped bytes can be eliminated.

As for the repeating data, I wonder if it would help to detect the L3REF pulse in my Propeller code. That might let me know where the start of the data is.

In order to follow the data from the recorder to the PC as well as the data from the PC to the recorder, I need to run two instances of the sync serial decoder. But the data stream for each line (TX and RX basically) runs at a pretty high speed, and generating a hexdump generates a lot more serial traffic than just sending the bytes in another way. I think if I interleave the transmit data with the receive data, it will make things very confusing very quickly, and I would be practically begging for flow control problem (because there is no flow control) if I would keep doing things in Hex.

So I think it would be better if I send the data out from the Propeller in binary or (slightly more friendly to the eyes) Base64 or something. That way, the stream has a much better chance of arriving intact, and that way I can write a C application under Windows to help me decipher the data. I'm thinking for starters I'll write a console application that hexdumps the data in a much wider format than 80 characters, so that I can get a feeling of where the fields are in the data that gets repeated all the time.

In the next log, I hope I can show some results of my analysis.