Hi @Jac, another topic just for better structure. Do you think attempting a 2nd gen mod would be worth it considering the lesser integration and the lower hardware pricing? Got a dirt cheap DCC300 when I saw it for that purpose.
This is definitely on the agenda!
There are several reasons why I’m doing my reverse-engineering project on a DCC-730: One is that the third generation chipset is well documented. Furthermore, it has 18 bit audio and can record user titles, which are important features for some people. Analyzing how title recording works on a DCC-730 might make it possible to implement that as a feature on 2nd and 1st gen recorders!
Another reason for using a DCC-730 is that the architecture of the recorder is very modular, so it’s possible to take the deck out and hook up some cables and make it work. It should be very simple to make a “duplication bank” with multiple 3rd gen decks, creating many cassettes at the same time.
The final reason for using the DCC-730 is that, out of all recorder types, the 730 is the only type of which I have two. Ralf gave me the one that I use for hacking, because it was beaten up and had a repaired Play button, so he figured he wouldn’t be able to sell it for a decent price anyway. I bought my first DCC-730 in 1994 and it was my first DCC recorder, so I treat it gently and don’t want to do any big modifications to it, but if my hacking 730 gets some dings and pings from traveling, it’s not a big problem.
The second generation hardware is absolutely awesome for hacking. The level of integration is lower but in a way that’s a good thing: It’s much easier to see which steps the signals go through to get processed and eventually this might be a tremendous help if we ever want to replace the entire hardware of a DCC recorder by e.g. a single FPGA. Also, the microcontrollers in the second-generation recorders are simpler and use simpler protocols to communicate, so they are probably easier to reverse-engineer. The division of tasks between the front panel microcontroller and the main microcontroller is (likely) very different from the 3rd generation situation: In 3rd gen, the front panel micro basically just puts on the display what the main micro says, and passes button presses and remote control commands to the main micro, but in the 2nd gen the front panel micro probably does a lot more things, such as tape deck control. But that means the main board controller is much more focused on controlling the custom chips, so it might be easier to replace it by something we make ourselves to inject our own SYSINFO and AUXINFO.
I have a DCC-600 and a DCC-300 and mechanically and electronically, they are my favorite decks. I love the portrait mode trays and I love the controls (for example they have separate buttons for wind/rewind and search and they have VU meters). I love how quickly they switch between play and stop and how quickly they reverse (they have an auto-reverse sensor that senses the lead-out tape at the end of side A). The 3rd generation mechanism has Turbo Drive and that’s cool, but whenever you do e.g. a search operation, it always sounds like the 3rd gen gets completely overwhelmed: back and forth, back and forth. Second generations decks are like: “I found it! Stop! Play!”. I’m looking forward to hacking a 2nd gen when I get along with the project a little further. As I mentioned, I think it would be cool to make them show song titles that are stored in the AUXINFO by a 3rd gen deck or DCC-Studio.
The DCC-900 (and its friends and cousins) are my least favorite recorders, because the schematics are so complicated and messy. They also are most notorious for problems such as leaking capacitors. I don’t really want to deal with a DCC-900 that might fail at any time while I’m working on it, but eventually I’ll hopefully hack one of those too. I don’t currently have one and I don’t have plans to buy one because I don’t have space to put it, and no time to work on it.
I have some vague ideas about replacing PASC with something better. Maybe if I ever get to that, it will be interesting to do that on a DCC-900 since they seem to be the most common DCC recorders. The first people who bought DCC were probably mostly interested in the sound quality and didn’t care that much about not having features such as title recording (I remember the absence of title recording was one of the reasons for me not to buy a first gen recorder). I’ve seen modded CD players with switchable oversampling and better DACs online, maybe there’s a market for modded DCC-900’s with e.g. 18 or 20 or even 24 bit codecs and/or multiple psycho-acoustic models, or the ability to use a Dolby Digital or DTS encoded SPDIF signal.
I don’t think there is a real market for it, we all could be using Spotify anyway.
For audio I would go with Opus, as it is open, the best and even has variable framesize.
When all other problems are solved, I would like to put AV1 (video) on the tapes in realtime. Of course, the quality will be rather bad, but it would be a nice art project, like the one from Vinyl that Techmoan showcased.
First of all I would not want to work with a 1st gen specifically, as they are more expensive than 2nd gen (at least in Europe) and as like you said more complicated and more error-prone, too.
Was able to obtain more detailed information, will probabbly release some or all of it soon.
I can imagine multiple viable ways of operation of a 2nd gen mod, which ones would you chose, seperate for read and write:
DDSP: Digital Drive Processing
DEQ2: Digital Equalizing
LT-BUS: Microcontroller to everything else for control and AUX/SYSINFO (p. 13/14 original, p. 10 on the www.freeservicemanuals.info scan also hosted on GitHub and dccmuseum.com)
- Capturing the raw 9 parallel amplified outputs of the
- Capturing the time-multiplexed output
TDA1317Read Amplifier directly to a file, could even be a good starting point for a file format.
- Capturing the parallel 9 pin output of the
SAA2051DEQ2 (just does A/D and D/A for a cleaner signal in this case)
- Capturing the I2S PASC and the LT-BUS for AUX/SYSINFO from the
- Transmitting the data to the
TDA1316TWrite Amplifier with its own serial protocol to talk to and perfect timing for the slightly alternating writing.
- Transmitting the 9 pin data to the
- Using SAA41 DDSP to deliver PASC via I2S and and SYSINFO/AUX via LT-BUS.
Other options are either insanely work intensive like controlling the head with an own amplifier or are limited to the normal capabilities of the device which we want to extend.
I would like to save all frames, be able to restore backups bit perfectly except maybe adoption to tape length if that is even necessary, so I would prefer not to work on Read 4. and Write 3. based on I2S and the LT-Bus with the SAA41 DDSP. Nevertheless reverse engineering of the LT-BUS would be useful for controlling the
SAA2051 DEQ2 and maybe more in the future.
It’s been a while since I was in this thread, so insert Gandalf “I have no memory of this place” meme here
One of the things I want to eventually be able to do is make dumps of tapes. One way to do that is to intercept the raw tape data from RDMUX but that is a very fast changing analog signal that’s not in sync with the tape. The chipset intentionally samples the tape faster than necessary and then uses an algorithm to decode the actual bit stream, probably based on the fact that with 8-to-10 encoding, there can only be n consecutive ones or zeroes on the tape (I don’t remember what n is at this time).
I think an easier (and more useful) way to generate tape dumps is probably to get the SYSINFO and AUXINFO from the L3 or LT bus, and the PASC data from the I2S subband bus. The third generation chipset is well documented and has some timing information that shows the relation between the tape blocks, the clock and the availability of the SYSINFO/AUXINFO on the L3 bus. I’m not sure how to do it with the earlier chipset but I expect that it won’t be all that different.
I think the best format for a tape dump will be something like MKA (Matroska Audio), where the MP1 data is interleaved with SYSINFO and AUXINFO information. That way, existing media players that support MP1 and MKA can play the files without modification, and we can implement new modules to decode the SYSINFO and AUXINFO data. I think there is already a data type for CD-Text, maybe some or all of that can be reused to encode/decode ITTS. In the future it may be possible to design something that can put an MKA tape dump back onto a tape with the SYSINFO and AUXINFO in the exact same location as the original.
3.072 MHz of RCLK as multiplexing frequency
AUX DUMMY CH0 CH1 CH2 CH3 CH4 CH5 CH6 CH7
RDSYNC is an additional indicator for the start of an AUX frame to sync with 1/10 the frequency.
I think the opposite way, nowadays these signals aren’t a challenge anymore and our documentation of the raw data on the tapes is more extensive than any of the busses. Preserving the frames has the huge advantage to avoid little timing differences, easier comparing between different releases just like *.iso from a CD compared to just copying the file contents. But you focussing on the busses and I2S and me on the more or less raw 9 data lines as stored on the DCC seems sensible to avoid duplicate research.
Nice that you liked my idea of using matroska. I would prefer to control timing myself and have a bitidentical backup and restore.
I opened a thread on the EEVBlog forum for it to find the most suitable hardware and software-platform as I did neither find enough info by myself nor found a person with the right knowledge to help (contrary to my ITTS project).
Good luck! By the way the ISO 61866 standard is in use by DAB I think, and I think CD-text is also based on it. I may be wrong but I’m pretty sure it’s not “not used for anything” as you say in your post.
I explored it before. DAB is far behind its potential in terms of features, ITTS is included in the DAB standard but I asked people deep down the rabbit hole if they ever heard of it and I got a no. And CD-Text is completely independent from ITTS, I have seen no proof of any connection: The ITTS CD-Text myth
That got me nothing, unfortunately. I saw a flex-cable soldered directly to the pins to SMD IC Pins, a technique we could apply for capturing the raw output from the read-amplifier once I have suitable hardware for that task.
The open hardware FPGA platform that I will be using called Glasgow finally has its Crowdfunding. I was not able to get the early bird discount 20 minutes after receiving the e-mail: https://www.crowdsupply.com/1bitsquared/glasgow
I found it a while ago by asking a bigger account to ask on Twitter for help as my EEVBlog forum post lead to nothing.
It has 16 I/O ports that can support anything we ever want up to 100 MHz. It uses an easy-to-use Python-based FPGA toolchain and is already being used for reading raw data from floppy disks including very corrupted ones which naturally has some similarities I might be able to reuse. Some very flexible I2S work has also already been done, in case @Jac is stuck with his solution due to hardware limitations.
I am 99.9% confident that if I will succeed this will be the platform, I ordered it.
@drdcc The board will be stocked later, you don’t have to order it right now just because it will be the solution in the future. The raw singnals will likely be captured via USB and processed on the PC, for preserval we don’t need processing in real-time. Recording back will be a whole different nightmare but I think it can one day be archieved.