Looking for some info...

Force them Rigs to accept True Voodoo!
Post Reply
BillPaul
Digital Voodoo Guru
Posts: 66
Joined: Wed Jan 19, 2011 11:52 am

Looking for some info...

Post by BillPaul »

As previously noted, I like to use my TS-950SDX on AM. It turns out that it is possible to achieve voodoo-style audio on AM with this radio, and I even wrote a small computer-assist utility to facilitate it. However, what I'd really love to do is modify the firmware so that the external software is not needed. For that though, I need a bit of info.

The main issue is that when you set menu option 21 on the TS-950SDX to "off" in order to increase the high end response out to 6.7Khz, the radio will no longer generate a carrier on AM. You can work around this by toggling the mode from AM to SSB and back to AM again, while keeping the transmitter engaged.

Previously, in order to achieve voodoo audio on the TS-950SDX, you needed the SDXCC kit, which was designed to intercept some of the signals sent to the DSP unit and modify them in order to get the DSP into wide band mode on transmit.

Previously, Voodoo Guru said:

"The way we actually do it is to intercept the 16bit word the Main CPU sends to the DSP Gate Array and reprogram it to send an alternate 16 bit word sequence. This way you are not switching all the analog circuitry inside the rig from SSB to AM while in TX, the only thing you will be doing is digitally switching the DSP Chip from SSB to AM while in TX, this of course remains to be seen as to what the actual words are that the Main CPU is sending. We have mapped all the words out previously when the SDXCC Unit was being designed & developed, but alas we did not send the sequence needed for AM when in WideGlide Mode (credit to Bill, KB1NCP for this terminology)."

After reading this, I did a little research on the microcontroller in the TS-950SDX. It's an NEC upd7810 part. I found the datasheet for it, and thanks to a friend I even found the user's manual for it. Both are here:

http://people.freebsd.org/~wpaul/ts-950 ... 0agq36.pdf

http://people.freebsd.org/~wpaul/ts-950 ... 514253.pdf

Thanks to the same friend, I also learned that the MAME arcade machine simulator package includes a disassembler utility that understands upd7810 instructions. (Apparently this same processor was used in some video game systems.) Using that, I was able to produce disassembly of the latest firmware image for the radio. The links to the binary firmware image and the disassembly listing are below:

http://people.freebsd.org/~wpaul/ts-950 ... W_JQGA.zip

http://people.freebsd.org/~wpaul/ts-950 ... 950SDX.txt

From the service manual it looks like the main CPU communicates with the DSP through one of the I/O ports, IC6. The signals from here eventually end up at connector A, on the back of the radio, which leads to the DSP unit on the bottom of the rig. The SDXCC was designed to be plugged in between the radio and this connector so that it could intercept and modify some of these signals.

It looks like there are a couple of different signal lines:

MH0 -- DSP HPF on/off
MH1-MH2 -- DSP HPF select
MATT -- DSP TX IF attenuator on/off

MCK -- DSP control serial clock
MDA -- DSP control serial data
MEN -- DSP comand enable
MLE -- DSP PLL data enable

My money says that the control word in question is sent via the serial pins. Also, looking at the disassembly of the firmware code, I think I can see where the data is clocked through the I/O port (look at the instructions starting at address 00001A7E). I've been doing embedded software development long enough that I think I can recognize 'bit-banging' when I see it. :)

The only problem is, it's very hard to tell what the actual words are that the firmware writes to the DSP. I believe that it keeps most of its state in RAM, which the firmware treats as non-volatile, since its contents are preserved when power is off using the 3v lithium battery. The code seems to be loading a value from RAM and sending it through the serial port, but there's no easy way for me to know what that value is. This is the sort of problem that's normally solved using hardware debug tools, but I don't have any such tools for this kind of CPU.

What I could also do is use a logic analyzer to sample the signals at connector A on the back of the radio and see how they change when the DSP menu options and mode selections are changed from the front panel. However, I believe that the developers of the SDXCC hardware already did this, since Voodoo Guru said they had mapped all the control words out.

So, after all that, here's my question: is this control word map available somewhere, and could I get a look at it? If it contains enough information, then in theory I could insert some instructions into the firmware to modify the value sent through the bit-bang code so that it keeps the carrier on in AM mode. If nothing else, it might help me interpret the code a little better.

It's possible that I'm wasting my time with all this, and I should just quit while I'm ahead, but I guess that voodoo bug has bitten me just a little too hard for me to give up just yet. :)

-Bill

User avatar
Voodoo Guru
VooDoo Site Admin
Posts: 719
Joined: Wed Feb 23, 2005 8:47 am
Location: Down there on the right...

Post by Voodoo Guru »

Howdy BillPaul,

Yup, that's how we got the words, using a Logic Analyzer on the SPI Serial Data Buss to the DSP Gate Array.
The problem is that we never mapped that particular scenario of TX in AM while the MENU 21 is OFF. The reason for this is because at that time the Power-On Mod to enable the OFF selection in Menu 21 was not known.
We can email you a PDF that has all the 16-bit words that were mapped off of the SPI Buss, and some of the notes we took while developing the SDXCC Unit.
Hopefully, this can help you.

Please send us an email so that we can return it with the information.

Take Care,
Voodoo Guru
From Deep in the IDD of the Sub-Harmonix Realm

BillPaul
Digital Voodoo Guru
Posts: 66
Joined: Wed Jan 19, 2011 11:52 am

Post by BillPaul »

E-mail address has been sent via PM. Thanks!

I understand about the lack of info for the AM modes, but like I said, anything helps. In order to really figure out what values the firmware is computing to send to the DSP, I think I'd have to run down what all the reset-default values are, and then see how they're modified when the keypad controls are sampled. That's a bit more than my brain can handle right now.

What I'm hoping is that it's just a matter of setting an extra bit somewhere. There are some unused gaps between code blocks in the firmware image, so in theory it should be possible to insert a small amount of code there, then patch the bit-banging routine to divert it to the extra code to clean up the control word, and then return back. If I'm lucky, the rest of the firmware should be none the wiser.

If I'm unlucky, Kenwood put code in somewhere to checksum the firmware and it won't run unless I figure out where the checksum is stored and update that too. A lot of firmware developers do that these days. I suppose I can find out by just modifying one byte in one of the unused regions and seeing if the radio still works.

Anyway, thanks again for the info. We'll see how it goes.

-Bill

Post Reply