开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育

Has anyone fully decoded the X9000 memory mapping?


 

Being the X9000s are still plentiful and I have a few I would be interested in working on a similar type of device for them. I started working on figuring out the memory mapping and another individual sent me some info he figured out but there is still quite a bit left to be figured out. This makes me wonder if anyone has a source for decoding what all the various bits do.?


 

Hey Casey, how's tricks?
I thought you had succumbed to "digital mode fever" like those other digital sheeple...lol...."OH YEAH" [beware of crashing wall] (pop culture refenence)
Last time I talked to you, you were on a mission to go headless on a Spectra (Astro?).? I did see a post on amother site that you got the SB9600 spoof to work. Good to know the theory worked! SB9600 spoofing may be "THE" backdoor into all things that run SB9600, including a revamp of the X9000 head design.
?? Anyway, are you looking for something specific? I have discerned one or two things more about the X9000 codeplug since we kicked that dog, but what and where exactly that info is, may be a challenge to find again.
? Sadly, I'm not q great "documentor" and tend to jump hither and yon cursed with the attention span of a 4 yo. when on a mission...lol
I did come across info to code the RX and TX pl freqs to th required hex data values. I *think* that included DPL, but alas, that was a few hours of sleep and more than a few cold adult beverages ago...lol
I may have written a proof of concept (Arduino) code snippet to do that, regardless I do have the math so it is doable in uC code. I know I did the same for an X9000 codeplug checksum (re)calculator...got to check my .ino archives.....

There are some zero page memory locations I sorted that set max modes, max MPL count, dual drawer byte val, checksum, etc.
I never ventured into plotting accessory interface, signalling or encryption feature settings memory usage.

Good to hear you are still kicking about.
73
s


 

I assume you guys know about the great web resource on Syntor/X/9000 stuff, onfreq.com...
http://www.onfreq.com/syntorx/syntorx9k/index.html
73
Brad KB9BPF
On Thursday, July 28, 2022, 01:55:55 PM CDT, swguest via groups.io <swguest@...> wrote:


Hey Casey, how's tricks?
I thought you had succumbed to "digital mode fever" like those other digital sheeple...lol...."OH YEAH" [beware of crashing wall] (pop culture refenence)
Last time I talked to you, you were on a mission to go headless on a Spectra (Astro?).? I did see a post on amother site that you got the SB9600 spoof to work. Good to know the theory worked! SB9600 spoofing may be "THE" backdoor into all things that run SB9600, including a revamp of the X9000 head design.
?? Anyway, are you looking for something specific? I have discerned one or two things more about the X9000 codeplug since we kicked that dog, but what and where exactly that info is, may be a challenge to find again.
? Sadly, I'm not q great "documentor" and tend to jump hither and yon cursed with the attention span of a 4 yo. when on a mission...lol
I did come across info to code the RX and TX pl freqs to th required hex data values. I *think* that included DPL, but alas, that was a few hours of sleep and more than a few cold adult beverages ago...lol
I may have written a proof of concept (Arduino) code snippet to do that, regardless I do have the math so it is doable in uC code. I know I did the same for an X9000 codeplug checksum (re)calculator...got to check my .ino archives.....

There are some zero page memory locations I sorted that set max modes, max MPL count, dual drawer byte val, checksum, etc.
I never ventured into plotting accessory interface, signalling or encryption feature settings memory usage.

Good to hear you are still kicking about.
73
s


 

I *think* that included DPL
Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
for that is in the syntorxgen source.

ISTR hearing that the '9000 code plug has a copyright statement and some
executable code in it somewhere that are necessary for proper operation.

De


 

I'll admit that my memory SUCKS these days, but I don't recall the
X9000 having a physical code plug. Wasn't it programmable via a
cable? I never had any X9000 radios myself.

73's Skip WB6YMH

On Thu, Jul 28, 2022 at 12:53 PM Dennis Boone <drb@...> wrote:

> I *think* that included DPL

Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
for that is in the syntorxgen source.

ISTR hearing that the '9000 code plug has a copyright statement and some
executable code in it somewhere that are necessary for proper operation.

De





 

Hi Bradley,
? Thanks for the input and interest.
Casey and I have both communed with Mike B., aka "Guru of all things Syntor and Spectra". Have you seen Casey's frequency agile X9000 proof of concept Youtube video? It's a few years old now, I guess it's still up.
Mike spelled out the divider theory details (some typical Moto misdirection and Voodoo...lol) and operational order, and Casey pounded out some Arduino code and made the necessary tie-ins to the divider circutry and behold... a frequency agile X9000...albeit scattered across the bench via some hookup wire and Atmel dev boards...but indeed proof of concept.
? I started with disecting the codeplug structure and revealed some of it's ways and means and have written some .xls based frequency to byte value and checksum calculators and some Arduino w/LCD touchscreen code to manipulate memory locations for the same reason...again, POC.
Life & priorities change so I have not visited the project for some time.


 

It's been a while since I messed with my pile of Syntor X radios as well, but I'm sure interested in watching that YouTube video you mentioned. I did a little searching but wasn't certain I was seeing the video by Casey that you mentioned. Got any other clues?
Thanks,
Brad KB9BPF
On Thursday, July 28, 2022, 03:19:02 PM CDT, swguest via groups.io <swguest@...> wrote:


Hi Bradley,
? Thanks for the input and interest.
Casey and I have both communed with Mike B., aka "Guru of all things Syntor and Spectra". Have you seen Casey's frequency agile X9000 proof of concept Youtube video? It's a few years old now, I guess it's still up.
Mike spelled out the divider theory details (some typical Moto misdirection and Voodoo...lol) and operational order, and Casey pounded out some Arduino code and made the necessary tie-ins to the divider circutry and behold... a frequency agile X9000...albeit scattered across the bench via some hookup wire and Atmel dev boards...but indeed proof of concept.
? I started with disecting the codeplug structure and revealed some of it's ways and means and have written some .xls based frequency to byte value and checksum calculators and some Arduino w/LCD touchscreen code to manipulate memory locations for the same reason...again, POC.
Life & priorities change so I have not visited the project for some time.


 

Hi Dennis,
Good to see your still out and about too.
DPL...I just dont recallany details on how to derive it outside of RSS. Nothing near me used DPL so I didnt have any reason to expend gray matter proccessing power to it.

I havent looked at your syntorxgen source code. Do you derive the hex values from a formula or use a lookup table? I remember some SyntorX codeplug layout data on a site..Xbits something? that's gone now. I thinks Mike B. replicated the info on his site.
I think maybe the DPL formula was in that info? I do know the CTCSS hex values are derived via formula.

Copyright statement? Hmmm..dont recall seeing it but I would have just glazed over it like the same as editing a Maxtrac MDF file...lol? As for executable code....sounds like a Scary Moto Urban Legend....lol. There is a checksum though and the RSS will bitch and puke and refuse to write if it's wrong.
There are a number of codeplug/FW/RSS version incompatabilities that must be kept in mind too.

Skip,
?It has a 2816 (2k) or 2864 (8k) mapped into the Hitachi uC's address & data busses.
In this respect the codeplug is a binary file written to the EEprom thru the Hitiachi uC via SB 9600.



 

Found the YouTube channel - Casey Crane. Thanks for the tip!
On Thursday, July 28, 2022, 03:58:45 PM CDT, Bradley Andrews via groups.io <kb9bpf@...> wrote:


It's been a while since I messed with my pile of Syntor X radios as well, but I'm sure interested in watching that YouTube video you mentioned. I did a little searching but wasn't certain I was seeing the video by Casey that you mentioned. Got any other clues?
Thanks,
Brad KB9BPF
On Thursday, July 28, 2022, 03:19:02 PM CDT, swguest via groups.io <swguest@...> wrote:


Hi Bradley,
? Thanks for the input and interest.
Casey and I have both communed with Mike B., aka "Guru of all things Syntor and Spectra". Have you seen Casey's frequency agile X9000 proof of concept Youtube video? It's a few years old now, I guess it's still up.
Mike spelled out the divider theory details (some typical Moto misdirection and Voodoo...lol) and operational order, and Casey pounded out some Arduino code and made the necessary tie-ins to the divider circutry and behold... a frequency agile X9000...albeit scattered across the bench via some hookup wire and Atmel dev boards...but indeed proof of concept.
? I started with disecting the codeplug structure and revealed some of it's ways and means and have written some .xls based frequency to byte value and checksum calculators and some Arduino w/LCD touchscreen code to manipulate memory locations for the same reason...again, POC.
Life & priorities change so I have not visited the project for some time.


 

I'll admit that my memory SUCKS these days, but I don't recall the
> X9000 having a physical code plug. Wasn't it programmable via a
> cable? I never had any X9000 radios myself.

Mine too! :)

The code plug is loaded over the wire (RIB, programming cable, ...), but
Moto seemed to stick to the term even though there wasn't a physical
pluggable object any more.

De


 

Bradley,
? Let me see what I can find. This was an X9000 but hardware wise at the point he made the connections the X and the X9000 *should* be the same animal. You will need service manuals for both to pursue the project.

He basicly severed the uC's data/control lines to the synthesizer and injected data calculated by his arduino from info Mike B. shared about the radio's divider/synthesizer operational process.

Again, POC. It would still take a fair amount of designing to hammer out the details and make an operational radio that doesnt resemble an alien autopsy.


 
Edited

The X9000 has a socketed 2 or 8K EEPROM for the code plug and is also programmable by the RIB interface which is a piggy back cable that the control cable plugs into along with the radio main plug. Likewise the control head is programmed with a separate executable via this interface. The radio has socketed firmware in 32, 64, 128 , and 256 channel capability. The 128 being most stable. The control heads vary in capability with some having socketed EEPROM and 8K expansion.

The Syntor X9000 drawer units are plentiful. Control cables and heads are less plentiful, but are still available. Control head plastic, buttons and VFD display are limitations.

The major obstacle is in the DOS RSS programs required. Finding a suitable DOS computer is becoming difficult as a 486 mother board with slow clock is a requirement.

Finding a method of programming the radio and control head codeplug s out of circuit would be helpful.

A second product to emulate the X9000 control head via an Android tablet and Bluetooth would be attractive. In this way a minimalistic control cable could be installed. However this would require an interface to emulate some analog control head circuitry, speaker? and mike connections, as well as provide a BT tranceiver for the SB9600 bus.?

There were dual drawer configurations of X9000 which might be possible with a new interface.

edit: Another feature for Low Band versions would be some sort of support for antenna tuning and/or selection. For example a tuning mode to drop power during tuning for screwdriver or auto tuners and/or a set of I/O's mapped to channels that would select a particular antenna relay. This would have to be paused during scanning , perhaps to a default antenna.?


On Thu, Jul 28, 2022 at 03:57 PM, Skip Hansen wrote:
I'll admit that my memory SUCKS these days, but I don't recall the
X9000 having a physical code plug. Wasn't it programmable via a
cable? I never had any X9000 radios myself.

73's Skip WB6YMH

On Thu, Jul 28, 2022 at 12:53 PM Dennis Boone <drb@...> wrote:

> I *think* that included DPL

Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
for that is in the syntorxgen source.

ISTR hearing that the '9000 code plug has a copyright statement and some
executable code in it somewhere that are necessary for proper operation.

De





 

True,
The term has come to mean the customer's radio operational information contained inside the product. Up to and including APX stuff and beyond. The X is probably the last to use a physical code plug, save the Midland ST1 series.
Even though it's Moto term, in the world of CCRs and other programmable radios, it sticks.

A real GE or Johnson guy would never use the terms "PL" or "DPL" for CTCSS or DCS but pretty much everyone eles does....lol


 

If anyone is willing to do an Xcat-2022 with a modern processor I'd be
willing to help with the firmware. With Kicad and places like JCLPCB
it should be much easier now!

Maybe just a daughter board for an ESP32 module or a "Blue pill? ??
(Why an ESP32 ... because you can GET them! Unlike lots of other
things.)

The Xcat raced the F8 processor to provide data, I don't know if the
same technique would be viable with an X9000, but it will be easy to
find out. Does anyone with an X9000 have a logic analyzer then can
connect to the "code plug" chip?

73's Skip

On Thu, Jul 28, 2022 at 2:20 PM RFI-EMI-GUY <rhyolite@...> wrote:

The X9000 has a socketed 2 or 8K EEPROM for the code plug and is also programmable by the RIB interface which is a piggy back cable that the control cable plugs into along with the radio main plug. Likewise the control head is programmed with a separate executable via this interface. The radio has socketed firmware in 32, 64, 128 , and 256 channel capability. The 128 being most stable. The control heads vary in capability with some having socketed EEPROM and 8K expansion.

The Syntor X9000 drawer units are plentiful. Control cables and heads are less plentiful, but are still available. Control head plastic, buttons and VFD display are limitations.

The major obstacle is in the DOS RSS programs required. Finding a suitable DOS computer is becoming difficult as a 486 mother board with slow clock is a requirement.

Finding a method of programming the radio and control head codeplug s out of circuit would be helpful.

A second product to emulate the X9000 control head via an Android tablet and Bluetooth would be attractive. In this way a minimalistic control cable could be installed. However this would require an interface to emulate some analog control head circuitry, speaker and mike connections, as well as provide a BT tranceiver for the SB9600 bus.

There were dual drawer configurations of X9000 which might be possible with a new interface.

On Thu, Jul 28, 2022 at 03:57 PM, Skip Hansen wrote:

I'll admit that my memory SUCKS these days, but I don't recall the
X9000 having a physical code plug. Wasn't it programmable via a
cable? I never had any X9000 radios myself.

73's Skip WB6YMH

On Thu, Jul 28, 2022 at 12:53 PM Dennis Boone <drb@...> wrote:


I *think* that included DPL
Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
for that is in the syntorxgen source.

ISTR hearing that the '9000 code plug has a copyright statement and some
executable code in it somewhere that are necessary for proper operation.

De





 

Yes, exactly. The thing was amazingly fast. The "problem" is the radio took on the attributes?of whatever mode was selected at the time. So, if mode 1 was selected, had a PL of 151.4 etc.... if I tuned away to a different frequency those attributes followed, being only the frequency was changing. It would basically require duplicating all the other features of the radio in hardware/software to take advantage of this method fully which is of course absurd.?

My thought was to present the uProcessor with one mode's worth of data and then change that data dynamically, allowing the uP to do all the rest of the work. I have the service manual and it appears it has a strobe line which basically thumbs through pages?of the eeprom grabbing data for different modes. If it were fed data that we could dynamically update despite whatever mode (eeprom data offset) it's looking for then we could control it all.

As said earlier, life has taken priority and caused a stall on the project but I do have some very nice code I came up with for the Raspberry Pi which I think could be used to feed an arduino as an internal decoder resulting in a very nice full color capacitive touch screen 4.3" user control interface with infinitely configurable mode names, scan lists, search parameters etc... all fed to the radio via a simple lightweight serial interface or perhaps even via one of the bluetooth serial dongle boards leaving only audio paths to be dealt with.?

As the solar cycle has heated up it's something that has got me thinking about it all again.?

I just don't know if this is the place to discuss it and I don't want to infringe or step on any toes regarding the project this group is about so I should probably start another group so as not to clutter this one.

Casey



On Thu, Jul 28, 2022 at 4:16 PM swguest via <swguest=[email protected]> wrote:
Bradley,
? Let me see what I can find. This was an X9000 but hardware wise at the point he made the connections the X and the X9000 *should* be the same animal. You will need service manuals for both to pursue the project.

He basicly severed the uC's data/control lines to the synthesizer and injected data calculated by his arduino from info Mike B. shared about the radio's divider/synthesizer operational process.

Again, POC. It would still take a fair amount of designing to hammer out the details and make an operational radio that doesnt resemble an alien autopsy.


 

Good to hear from you as well. I will contact you direct and bring you up to speed on some ideas and also some info on some things taking time away from the project. I hope all has been good on your end.


 

Yes, I have the logic analyzer and several low band units. All I'm missing is time but I'll do my best to set one up for testing.


On Thu, Jul 28, 2022 at 4:30 PM Skip Hansen <skip@...> wrote:
If anyone is willing to do an Xcat-2022 with a modern processor I'd be
willing to help with the firmware.? With Kicad and places like JCLPCB
it should be much easier now!

Maybe just a daughter board for an ESP32 module or a "Blue pill? ??
(Why an ESP32 ... because you can GET them!? Unlike lots of other
things.)

The Xcat raced the F8 processor to provide data, I don't know if the
same technique would be viable with an X9000, but it will be easy to
find out.? Does anyone with an X9000 have a logic analyzer then can
connect to the "code plug" chip?

73's Skip

On Thu, Jul 28, 2022 at 2:20 PM RFI-EMI-GUY <rhyolite@...> wrote:
>
> The X9000 has a socketed 2 or 8K EEPROM for the code plug and is also programmable by the RIB interface which is a piggy back cable that the control cable plugs into along with the radio main plug. Likewise the control head is programmed with a separate executable via this interface. The radio has socketed firmware in 32, 64, 128 , and 256 channel capability. The 128 being most stable. The control heads vary in capability with some having socketed EEPROM and 8K expansion.
>
> The Syntor X9000 drawer units are plentiful. Control cables and heads are less plentiful, but are still available. Control head plastic, buttons and VFD display are limitations.
>
> The major obstacle is in the DOS RSS programs required. Finding a suitable DOS computer is becoming difficult as a 486 mother board with slow clock is a requirement.
>
> Finding a method of programming the radio and control head codeplug s out of circuit would be helpful.
>
> A second product to emulate the X9000 control head via an Android tablet and Bluetooth would be attractive. In this way a minimalistic control cable could be installed. However this would require an interface to emulate some analog control head circuitry, speaker? and mike connections, as well as provide a BT tranceiver for the SB9600 bus.
>
> There were dual drawer configurations of X9000 which might be possible with a new interface.
>
> On Thu, Jul 28, 2022 at 03:57 PM, Skip Hansen wrote:
>
> I'll admit that my memory SUCKS these days, but I don't recall the
> X9000 having a physical code plug. Wasn't it programmable via a
> cable? I never had any X9000 radios myself.
>
> 73's Skip WB6YMH
>
> On Thu, Jul 28, 2022 at 12:53 PM Dennis Boone <drb@...> wrote:
>
>
> > I *think* that included DPL
>
> Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
> for that is in the syntorxgen source.
>
> ISTR hearing that the '9000 code plug has a copyright statement and some
> executable code in it somewhere that are necessary for proper operation.
>
> De
>
>
>
>
>






 

I havent looked at your syntorxgen source code. Do you derive the hex
> values from a formula or use a lookup table? I remember some SyntorX
> codeplug layout data on a site..Xbits something? that's gone now. I
> thinks Mike B. replicated the info on his site. I think maybe the
> DPL formula was in that info? I do know the CTCSS hex values are
> derived via formula.

The basic DPL code bits are simple. But there are three additional
mystery bits in the code plug. Syntorxgen now uses a formula to
calculate the proper values for those bits. It's not clear to me what
those bits do, other than being a pita. I had originally just set those
extra bits to zeros as suggested by Paul Kasley and Mike's code plug
info, then found that there were one or two types of radios (VX-5R, and
a Pacific Research repeater controller, iirc) that Didn't Like That
<tm>. I then experimentally* built a table (it's still in the source,
but no longer used) that mostly worked, and a few other folks (e.g. Andy
Brinkley) contributed some effort to find corrections. Eventually the
formula was worked out.

Paul's site is long gone, but Mike may have a copy at onfreq, and I
fished one out of the wayback machine for my Syntor X pages.

For CTCSS, the value is basically a multiplier or divider value.
Syntorxgen will let you set non-standard tones because it just does the
math. The code plug page gives you the bit patterns for the standard
tones.

De


* Yes, this was _exactly_ as fun as it sounds. 32 modes in a code plug
will hold all 8 possible mystery bit patterns for 4 DPL codes. Burn
EEPROM. Insert into radio. Select mode 1. Try a transmission. Try a
reception. Note results. Mode 2. Lather rinse repeat. Decide which
of multiple patterns opened the squelch _fastest_. There are, what,
~104 DPL codes? :)


 

If anyone is willing to do an Xcat-2022 with a modern processor I'd
> be willing to help with the firmware. With Kicad and places like
> JCLPCB it should be much easier now!

> Maybe just a daughter board for an ESP32 module or a "Blue pill? ??
> (Why an ESP32 ... because you can GET them! Unlike lots of other
> things.)

I've thought for some time that a Beaglebone Black, with its two PRU
(Programmable Realtime Unit) processors, would be nearly the whole
device. People have e.g. spoofed GPS signals and imitated old MFM hard
drives' flux interfaces with them.

De


 

The problem with the Beaglebone Black is that it's unlikely to fit
inside of a Syntor if that's your goal.

My interest was always in "remote base stations" and I didn't care
about Motorola control heads. I don't really know how many people are
interested in mobiles vrs bases.

When I bought a new car in the 80s I went to "rice boxes" for my car
because I was too lazy to run control cables. When I got my last car
(2010) I went back to control cables and a Spectra under the passenger
seat. Replacing the caps in the Spectra wasn't fun, but it's still
running 12 years later. Not that I turn it on very much these days...

73's Skip WB6YMH

On Thu, Jul 28, 2022 at 2:39 PM Dennis Boone <drb@...> wrote:

> If anyone is willing to do an Xcat-2022 with a modern processor I'd
> be willing to help with the firmware. With Kicad and places like
> JCLPCB it should be much easier now!

> Maybe just a daughter board for an ESP32 module or a "Blue pill? ??
> (Why an ESP32 ... because you can GET them! Unlike lots of other
> things.)

I've thought for some time that a Beaglebone Black, with its two PRU
(Programmable Realtime Unit) processors, would be nearly the whole
device. People have e.g. spoofed GPS signals and imitated old MFM hard
drives' flux interfaces with them.

De