Yes, it’s possible to disassemble the existing software but I feel that it would be a big waste of time. Disassembling DCC-Studio and reassembling or recompiling to a 32 bit executable file won’t be enough to make it work. The program accesses the printer port directly and all current operating systems will prevent a regular program from doing that. Only device drivers should access hardware directly, and writing device drivers is difficult, not to mention you have to jump through hoops like getting your driver to be WHQL certified to make it install on Windows. And after you go through all that effort, a 32-bit version of DCC-Studio with a new device driver will only benefit those with a Windows computer and an original cable from Philips.
So the plan is to make new hardware that gets connected to the USB connector of a PC (or Mac or Linux machine). DCC-Studio won’t work so we’ll have to write new software. But there are many things that DCC-Studio can’t do, that can easily be implemented in our own software. For example, DCC Studio shows you a nice information window with all the track titles while you’re copying a tape to hard disk, but it doesn’t use the information to write the audio to separate files with automatically generated file names, or even to generate markers in the single track file. That is an obvious feature that I can easily implement from scratch, without the need to decompile DCC-Studio first.
I disagree with that. C is such a low level language that decompiling is usually pretty easy. I did it with the Lode Runner game for DOS. That took a long time, though!
The hard part is when the optimizer does a bunch of weird things like reordering and reusing instructions. However in the 1990s, optimizers weren’t that good yet. Based on my experience, it should be pretty easy to disassemble and maybe even decompile DCC-Studio but as I said, it won’t get you anywhere, other than understanding how the program works.
If you want to know how the plug works, it’s probably much easier to disassemble the DCC.SYS device driver that the DOS Backup program installs. That driver focuses only on sending data back and forth and controlling the recorder, and another guy and I worked on disassembling it in the 1990s. We abandoned the project because we didn’t know enough about DCC at the time, but I may get back to it because it may help me understand the protocol on the serial port.
The interface has a half-duplex version of the I2S sub-band bus, i.e. the PASC data, and a synchronous serial port. The bit clock isn’t on the cable, probably because it would generate too much interference and wouldn’t arrive unscathed anyway, but it can be easily derived with a PLL and the word clock. Extracting and injecting PASC/MP1 data should be extremely simple with a microcontroller with an I2S interface such as the Raspberry Pi or the Teensy. I’ll probably use the Teensy 3.5 because it’s 5V tolerant, has I2S, a MicroSD card reader, SPI buses and USB, and there is an extensive audio library framework that looks like it’s possible to make it appear to the USB host (PC, Mac or Linux) as a USB audio device. If it’s possible to make the Teensy appear as a multi-point USB device, I’ll also make an HID device appear for control of the recorder.
The synchronous serial port has a protocol that I tried to analyze, but haven’t been successful yet. In fact I sort of abandoned that effort because there were just too many unknowns. I know that the recorder and the plug exchange data continuously in packets of 32 bytes, and it appears that packets are handled in groups of three packets (96 bytes) but I’m not sure of that yet. I’ve only looked at a continuous hex dump of the serial data stream from the recorder to the plug, and it looks like it has the SYSINFO and AUXINFO data from the tape during playback. If we’re lucky, it’s also possible to record SYSINFO and AUXINFO through the serial interface, and make our own prerecorded cassettes. From the datasheets, it looks like the chipset can do it (I’m not 100% sure) so if the microcontroller simply transfers data to the L3 bus, the serial port can do it too. I don’t know yet.
I don’t think that will work. I tried using a VM with Windows 95 connected to a physical parallel port sometime around 2003 so things may have changed since then, but you have to keep in mind that even VM software like VirtualBox also has to follow the rules and talk to hardware through device drivers that are installed in the host OS. And the DCC-Link works different from a printer, so chances are that it still won’t work, although I haven’t tried recently, because I don’t have any PC’s with parallel ports anymore anyway.
===Jac
