I finally had some time to work on the Propeller software that interprets the synchronous serial data. The data in this picture are definitely completely wrong but at least the synchronous serial analyzer cog is generating data. For one thing, the Windows 98 computer was off during this first test and I don't know if the DCC-175 even talks to the chip in the DCC-Link in this state. Also the output format doesn't make sense: it should show a hexdump with lines that start with a memory address, followed by hexadecimal data, followed by filtered ASCII characters.

There was another problem that I solved a week or two ago if I remember correctly. If I connect the recorder to the Propeller with no hardware in between, and the Propeller doesn't have any power, the residual impedances in the Propeller are enough to send a tiny amount of current into the WAKEUP line -- enough to make the microcontroller power up the recorder.

That would mean I can't leave the Turkey Lab powered while I'm not working on the project, because even if the Propeller isn't plugged into the development computer, it would keep powering up the recorder, and I want the recorder to stay in Standby when I'm not using it.

Additionally, the microcontroller in the recorder apparently doesn't check for the WAKEUP signal when it's powered on (so that answers the question what WAKEUP does during operation: Nothing). So once it's on and sits there, twiddling its thumbs (after it's straightened out the tape during startup), it waits for a few minutes and then turns itself off, and then immediately on again.

The fix was to put a resistor in series with WAKEUP. I did some experimenting and it turns out with a 10K resistor, the Propeller can still reliably wake the recorder by making WAKEUP high, and when the Propeller is not powered or when the Propeller holds the pin LOW, the recorder doesn't switch itself on.

Anyway, the next step is to debug the software until I get something sensible on the serial terminal. At least it's producing SOME data, and the output is definitely caused by the synchronous serial port parser: it's the only thing that generates commands for the TXX module after the banner message.

So once again, not much news but I'm making some progress now.

Addendum: The Hexdump Command Is 2, Not 8

As I suspected, I was sending the wrong command to my TXX module to generate a hex dump of the incoming data from the recorder: I had the input mode and output mode fields mixed up in the command, so instead of sending a command to generate a hexdump, I was sending a command to print a decimal representation of a 16-bit value. Yeah, not what I wanted.

Now that's fixed, it actually dumps packets from the microcontroller in the recorder! Well... Sort of.

As you can see, it clearly uses two buffers: one at location $0704 and one at $0724. But it only decodes one byte from the data stream per packet, and I'm scratching my head as to why...

The good news is that the data looks legitimate. The above data that looks wildly random, was generated while the recorder was playing a tape. When the recorder is in stop mode, the data seems a lot less random and a lot more repetitive. Once I find out why the code thinks each packet is only one byte long, I'll know more.