开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Xcat
  2. Messages
Expanded Topics Messages Polls
Date
Re: Has anyone fully decoded the X9000 memory mapping?

 

@ Dennis,
You are still doing better than me...When it comes to this family of boards I'm in the "Everybody knows pie are round. Cornbread are square" camp.

A Pico as What kind of peripheral?

@ Casey,
Mounted inside the radio you can tap the single ended side of the com bus and tie the Pico to a BT radio mounted outside the case.

Outside the case, taking advantage of the differential bus noise immunity use the CH end of the cable. `
Re: Has anyone fully decoded the X9000 memory mapping?

 

Check this out.



On Sun, Aug 7, 2022 at 7:02 PM Skip Hansen <skip@...> wrote:
Yea, it's not the processor it's who programmed it!? I bow to the genius.

73's Skip WB6YMH

On Sun, Aug 7, 2022 at 4:51 PM swguest via
<swguest=[email protected]> wrote:
>
> @ Ship,
> Isn't it amazing.
> A lowly 35+ yo, 2 meg clocked processor can generate and decode sub audible frequency to tenth of a hz better than all these fast, powerful embedded uC's out there.
> That just dont seem right.
>





Re: Has anyone fully decoded the X9000 memory mapping?

 

That was what I thought. You get the advantage of the robustness of the differential lines as well. I wish the pins and cable assembly ends were more plentiful. If we get that far the physical interfacing will become an issue. I might unsolder the entire connector and use something else, maybe a plate with RJ45 and a separate Power Pole panel mounted.?


On Sun, Aug 7, 2022 at 7:27 PM Dennis Boone <drb@...> wrote:
You know, a cute way to talk to the Pi inside the radio would be to put
it on the SB9600 bus as a peripheral.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

You know, a cute way to talk to the Pi inside the radio would be to put
it on the SB9600 bus as a peripheral.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

It sure would be interesting to see how it all works.


On Sun, Aug 7, 2022 at 6:40 PM Skip Hansen <skip@...> wrote:
One of my other projects back in the day was "thelinkbox", which
is/was a PC based repeater controller and Viop thingy.? I played with
software based PL and touch tone decoding at lot and while I got a
couple of them to work they were NEVER anywhere close to as good as a
Motorola radio.? At one point I tried disassembling the Maxtrac ROMS
to try to figure out how it did it, while it was "FUN", I never got
very far.

I also had a physical repeater controller that used a PL decoder chip.
Aain it worked but nowhere near as well as a Motorola anything.? The
chip was discontinued a couple of years after it was introduced...
maybe that's why?

Other than just for the heck of it I won't consider replacing the
control board.? But ... now thanks to the NSA we have Ghidra ... it
might be fun to disassemble the code.? But it's not clear if Ghidra
supports the 6301 or not.

Oh boy, another project ... adding 6301 support to Ghidra.

73's Skip WB6YMH

On Sun, Aug 7, 2022 at 3:09 PM Casey Crane <ccrane148@...> wrote:
>
> I'm not trying to distract from the goal here either but have been mulling over other options. I was sitting here thinking what all we need it to do. In reality to me, and maybe I'm wrong, but really the only thing we need from it is a steerable signal using 5k or 6.25 k stepping, a receiver that tracks just the same and PL/DCS on TX and RX. The rest would be handled by higher level programming of whatever flavor anyone wanted be it C or Python or what not. As long as we can communicate with it using some standard we come up with to package the data in and out of it to obtain the above we are golden.
>
> When I made the VCO tuning project using the Arduino I found a low frequency freq counter library made by the PJRC guy I believe. I tapped into the DETECTED PL line into the uP and fed that into the Arduino and made a table of PLs in something like a switch table. It seemed to work well. I just needed to add in some coasting delay for times voice caused the PL to wash out. I have tried to find a PL/DCS detect and encode library but haven't been successful. If a good reliable one was found we could still go that route as well then rip out the uP and hijack the SB9600 bus for our own external comms. PA ENABLE, DETECTOR MUTE, SQUELCH DECISION and other items are available for use still. Heck, we could probably hijack the D0-D7 lines and drive the audio options latch. It's not like anyone would be using the ancient options stuff like the MDC600 options boards and we would not be using the factory control head. At least I didn't intend to.
>
> MX-COM and later I think CML used to make PL/DCS encoder/decoder chips. Are they still available? If so, what about one of those driven by SPI or i2c or whatever?
>
> Again, not trying to derail the idea because I think using the stuff (existing uP) that obviously works well already is probably best but if in the end the thing becomes too problematic maybe this is another option.
>
>
>
> On Sun, Aug 7, 2022 at 4:48 PM Dennis Boone <drb@...> wrote:
>>
>>? > No distraction at all. It got me thinking about the activity of the
>>? > firmware eeprom since it utilizes the extra addressing. It might help
>>? > to paint a more complete picture.
>>
>> Seems like it might be useful, for example, in working out what i/o
>> devices are where, and how they work.? Knowing the instruction address
>> for various things might help with disassembly of the firmware.? Etc.
>> None of this is relevant to code plug ROM emulation.
>>
>> The space between the top of RAM (0x013F) and the bottom of code plug
>> (0x8000) is ripe for i/o devices.? There's also a gap between the top of
>> the larger code plug ROM (0x9fff) and the firmware (0xC000) that could
>> have Stuff and Things in.
>>
>> Again, this is a distraction from Goal A: emulate a code plug ROM, which
>> I'm most emphatically not trying to derail.
>>
>> De
>>
>>
>>
>>
>>
>





Re: Has anyone fully decoded the X9000 memory mapping?

 

Actually ... You *could* do it in Python (or Basic if such a thing
> exists) on the Pi Pico. The Pi Pico's programmable parallel port can
> do **ALL** of the heavy lifting given the right program.

Guess I need to really dig into this beast instead of shooting off my
mouth! :)

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

I hadnt looked into it at all. All I picked up on for the Pico
> Pi....MicroPython...yadi yadi, to which I just just kinda glazed
> over......

It appears I told a lie. The Micro Pi _isn't_ a linux box. But you
_can_ program it in C, which is the sane plan here.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

That sounds so much easier than I was thinking. I've got to take a close look at this DMA/state machine stuff


On Sun, Aug 7, 2022 at 04:48 PM, Skip Hansen wrote:
Actually ... You *could* do it in Python (or Basic if such a thing
exists) on the Pi Pico. The Pi Pico's programmable parallel port can
do **ALL** of the heavy lifting given the right program. Take a look
at that C64 ROM replacement project on github. Once the parallel
port's state machine is setup the timing critical stuff is all handled
by it. The CPU is completely out of the loop.

So a block of on chip RAM is DMA'ed to the pins by HARDWARE, the CPU
just needs to modify the data in RAM for the "vfo" mode based on input
from the "control head".
Re: Has anyone fully decoded the X9000 memory mapping?

 

Yea, it's not the processor it's who programmed it! I bow to the genius.

73's Skip WB6YMH

On Sun, Aug 7, 2022 at 4:51 PM swguest via groups.io
<swguest@...> wrote:

@ Ship,
Isn't it amazing.
A lowly 35+ yo, 2 meg clocked processor can generate and decode sub audible frequency to tenth of a hz better than all these fast, powerful embedded uC's out there.
That just dont seem right.
Re: Has anyone fully decoded the X9000 memory mapping?

 

@ Ship,
Isn't it amazing.?
A lowly 35+ yo, 2 meg clocked processor can generate and decode sub audible frequency to tenth of a hz better than all these fast, powerful embedded uC's out there.
That just dont seem right.
Re: Has anyone fully decoded the X9000 memory mapping?

 

Actually ... You *could* do it in Python (or Basic if such a thing
exists) on the Pi Pico. The Pi Pico's programmable parallel port can
do **ALL** of the heavy lifting given the right program. Take a look
at that C64 ROM replacement project on github. Once the parallel
port's state machine is setup the timing critical stuff is all handled
by it. The CPU is completely out of the loop.

So a block of on chip RAM is DMA'ed to the pins by HARDWARE, the CPU
just needs to modify the data in RAM for the "vfo" mode based on input
from the "control head".

73's Skip WB6YMH

On Sun, Aug 7, 2022 at 3:59 PM Dennis Boone <drb@...> wrote:

> I dont know MP LAB source or Python, or what it would take to port
> Skip's Xcat source to Python.

Don't waste your life trying to do this with python. You want to do it
in C. The timing will be too inconsistent. A Pi is just a Lunix box.

> It just occured to me....I'm guessing from the references to memory
> allocation in a previous post you are perusing the Hitachi's data
> Handbook? IIR, there are several internal memory configs depending on
> the chip version, Even one w/masked OTP ROM.

HD63A03YP has 256 bytes RAM, no internal ROM.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

Dang it Dennis,
That's another rabbit hole on the map.
I hadnt looked into it at all. All I picked up on for the Pico Pi....MicroPython...yadi yadi, to which I just just kinda glazed over......aka Homer Simson thinking about doughnuts

A simple Google of Arduino IDE and Pico Pi netted a lot of positive results.
Looks like it's time to head down that rabbit hole. At least I'll recognize some of the scenery along the way.........

@Casey,
?That's a serious bunch of cobbling!? Good show. It get's you access to the acces to the pins. That's what counts.
I had some of those "chip clips" that were so old they fell apart at the pivot point. The plastic was so brittle they were not salvagable. I dont know if they even make those anymore.

If you have ever seen a hacked VC II 010 board you will appreciate the endeavor.

I had something similar in mind. I'll have to find the link to the connectors I got to do the duty.
Re: Has anyone fully decoded the X9000 memory mapping?

 

One of my other projects back in the day was "thelinkbox", which
is/was a PC based repeater controller and Viop thingy. I played with
software based PL and touch tone decoding at lot and while I got a
couple of them to work they were NEVER anywhere close to as good as a
Motorola radio. At one point I tried disassembling the Maxtrac ROMS
to try to figure out how it did it, while it was "FUN", I never got
very far.

I also had a physical repeater controller that used a PL decoder chip.
Aain it worked but nowhere near as well as a Motorola anything. The
chip was discontinued a couple of years after it was introduced...
maybe that's why?

Other than just for the heck of it I won't consider replacing the
control board. But ... now thanks to the NSA we have Ghidra ... it
might be fun to disassemble the code. But it's not clear if Ghidra
supports the 6301 or not.

Oh boy, another project ... adding 6301 support to Ghidra.

73's Skip WB6YMH

On Sun, Aug 7, 2022 at 3:09 PM Casey Crane <ccrane148@...> wrote:

I'm not trying to distract from the goal here either but have been mulling over other options. I was sitting here thinking what all we need it to do. In reality to me, and maybe I'm wrong, but really the only thing we need from it is a steerable signal using 5k or 6.25 k stepping, a receiver that tracks just the same and PL/DCS on TX and RX. The rest would be handled by higher level programming of whatever flavor anyone wanted be it C or Python or what not. As long as we can communicate with it using some standard we come up with to package the data in and out of it to obtain the above we are golden.

When I made the VCO tuning project using the Arduino I found a low frequency freq counter library made by the PJRC guy I believe. I tapped into the DETECTED PL line into the uP and fed that into the Arduino and made a table of PLs in something like a switch table. It seemed to work well. I just needed to add in some coasting delay for times voice caused the PL to wash out. I have tried to find a PL/DCS detect and encode library but haven't been successful. If a good reliable one was found we could still go that route as well then rip out the uP and hijack the SB9600 bus for our own external comms. PA ENABLE, DETECTOR MUTE, SQUELCH DECISION and other items are available for use still. Heck, we could probably hijack the D0-D7 lines and drive the audio options latch. It's not like anyone would be using the ancient options stuff like the MDC600 options boards and we would not be using the factory control head. At least I didn't intend to.

MX-COM and later I think CML used to make PL/DCS encoder/decoder chips. Are they still available? If so, what about one of those driven by SPI or i2c or whatever?

Again, not trying to derail the idea because I think using the stuff (existing uP) that obviously works well already is probably best but if in the end the thing becomes too problematic maybe this is another option.



On Sun, Aug 7, 2022 at 4:48 PM Dennis Boone <drb@...> wrote:

> No distraction at all. It got me thinking about the activity of the
> firmware eeprom since it utilizes the extra addressing. It might help
> to paint a more complete picture.

Seems like it might be useful, for example, in working out what i/o
devices are where, and how they work. Knowing the instruction address
for various things might help with disassembly of the firmware. Etc.
None of this is relevant to code plug ROM emulation.

The space between the top of RAM (0x013F) and the bottom of code plug
(0x8000) is ripe for i/o devices. There's also a gap between the top of
the larger code plug ROM (0x9fff) and the firmware (0xC000) that could
have Stuff and Things in.

Again, this is a distraction from Goal A: emulate a code plug ROM, which
I'm most emphatically not trying to derail.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

It's a mash up of headers and sockets soldered together. Basically it just raises the chip up above things and has angled pins (bent two row headers) that connect to the top socket pins and the outer row of headers are all shorted to ground for each flying lead's ground line.?



On Sun, Aug 7, 2022 at 5:52 PM swguest via <swguest=[email protected]> wrote:
@ Casey,
So what's the skinny on the DIP socket extender you fab'd up?
My actual develpment ended at that point. I had enough mega code to test the config I was going to use, but I had speed concerns that i think I had a HW workaroud for but I've got to get the bus lines up to a perf board to dev anything further.
Looking at that Pico Pi, that fixes a lot of the workaround HW I was considering, and if I go that route, I'm back to square one.

Either way to test PH I emulation function we've got to get interfaced with the busses.

?I dont know MP LAB source or Python, or what it would take to port Skip's Xcat source to Python.

The detect address and serve data routines should be a good template. Remap the GPIO lines to the X9000's buses and put a valid codeplug in memory should be a solid start.

@ Dennis,
It just occured to me....I'm guessing from the references to memory allocation in a previous post you are perusing the Hitachi's data Handbook? IIR, there are several internal memory configs depending on the chip version, Even one w/masked OTP ROM.
I dont recall that the X9000 has that version. Good thing, no telling what we would run into...lol

20220806_211359.jpg

Re: Has anyone fully decoded the X9000 memory mapping?

 

I dont know MP LAB source or Python, or what it would take to port
> Skip's Xcat source to Python.

Don't waste your life trying to do this with python. You want to do it
in C. The timing will be too inconsistent. A Pi is just a Lunix box.

> It just occured to me....I'm guessing from the references to memory
> allocation in a previous post you are perusing the Hitachi's data
> Handbook? IIR, there are several internal memory configs depending on
> the chip version, Even one w/masked OTP ROM.

HD63A03YP has 256 bytes RAM, no internal ROM.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

@ Casey,
So what's the skinny on the DIP socket extender you fab'd up?
My actual develpment ended at that point. I had enough mega code to test the config I was going to use, but I had speed concerns that i think I had a HW workaroud for but I've got to get the bus lines up to a perf board to dev anything further.
Looking at that Pico Pi, that fixes a lot of the workaround HW I was considering, and if I go that route, I'm back to square one.

Either way to test PH I emulation function we've got to get interfaced with the busses.

?I dont know MP LAB source or Python, or what it would take to port Skip's Xcat source to Python.

The detect address and serve data routines should be a good template. Remap the GPIO lines to the X9000's buses and put a valid codeplug in memory should be a solid start.

@ Dennis,
It just occured to me....I'm guessing from the references to memory allocation in a previous post you are perusing the Hitachi's data Handbook? IIR, there are several internal memory configs depending on the chip version, Even one w/masked OTP ROM.
I dont recall that the X9000 has that version. Good thing, no telling what we would run into...lol
Re: Has anyone fully decoded the X9000 memory mapping?

 

I am familiar with squirrels, shiny object and rabbit holes, That's a fair amount of the reason it's taken a decade to get back to this. Seems like getting distracted is my life's motto sometimes...lol

New toys to show new information to process. If it hard to not say What if, or What else.
I believe that comes with the territory for anyone who has a mad scientist's hat on their hatrack.

I think the best time I had w/kids and grands is the 4,5.6 yr age when they ask a question and you cant get it answered before they ask another, and another...lol
It's amazing to watch when those lil sponge minds are soaking up everything in their relm of comprehension..
Re: Has anyone fully decoded the X9000 memory mapping?

 

I'm not trying to distract from the goal here either but have been mulling over other options. I was sitting here thinking what all we need it to do. In reality to me, and maybe I'm wrong, but really?the only thing we need from it is a steerable signal using 5k or 6.25 k stepping, a receiver that tracks just the same and PL/DCS on TX and RX. The rest would be handled by higher level programming of whatever flavor anyone wanted be it C or Python or what not. As long as we can communicate with it using some standard we come up with to package the?data in and out of it to obtain the above we are golden.?

When I made the VCO tuning project using the Arduino I found a low frequency freq counter library made by the PJRC guy I believe. I tapped?into the DETECTED PL line into the uP and fed that into the Arduino and made a table of PLs in something like a switch table. It seemed to work well. I just needed to add in some coasting delay for times voice caused the PL to wash out. I have tried to find a PL/DCS detect and encode library?but haven't been successful. If a good reliable one was found we could still go that route as well then rip out the uP and hijack the SB9600 bus for our own external comms. PA ENABLE, DETECTOR?MUTE, SQUELCH DECISION and other items are available for use still. Heck, we could probably hijack the D0-D7 lines and drive the audio options latch. It's not like anyone would be using the ancient options stuff like the MDC600 options boards and we would not be using the factory control head. At least I didn't intend to.?

MX-COM and later I think CML used to make PL/DCS encoder/decoder chips. Are they still available? If so, what about one of those driven by SPI or i2c or whatever??

Again, not trying to derail the idea because I think using the stuff (existing uP) that obviously works well already is probably best but if in the end the thing becomes too problematic maybe this is another option.



On Sun, Aug 7, 2022 at 4:48 PM Dennis Boone <drb@...> wrote:
?> No distraction at all. It got me thinking about the activity of the
?> firmware eeprom since it utilizes the extra addressing. It might help
?> to paint a more complete picture.

Seems like it might be useful, for example, in working out what i/o
devices are where, and how they work.? Knowing the instruction address
for various things might help with disassembly of the firmware.? Etc.
None of this is relevant to code plug ROM emulation.

The space between the top of RAM (0x013F) and the bottom of code plug
(0x8000) is ripe for i/o devices.? There's also a gap between the top of
the larger code plug ROM (0x9fff) and the firmware (0xC000) that could
have Stuff and Things in.

Again, this is a distraction from Goal A: emulate a code plug ROM, which
I'm most emphatically not trying to derail.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

No distraction at all. It got me thinking about the activity of the
> firmware eeprom since it utilizes the extra addressing. It might help
> to paint a more complete picture.

Seems like it might be useful, for example, in working out what i/o
devices are where, and how they work. Knowing the instruction address
for various things might help with disassembly of the firmware. Etc.
None of this is relevant to code plug ROM emulation.

The space between the top of RAM (0x013F) and the bottom of code plug
(0x8000) is ripe for i/o devices. There's also a gap between the top of
the larger code plug ROM (0x9fff) and the firmware (0xC000) that could
have Stuff and Things in.

Again, this is a distraction from Goal A: emulate a code plug ROM, which
I'm most emphatically not trying to derail.

De
Re: Has anyone fully decoded the X9000 memory mapping?

 

On Sun, Aug 7, 2022 at 02:16 PM, swguest wrote:
"Data on the bus w/o CE low is irrelevant."
I had better qualify this.....

If Skip finds a JMP or JSR in the FW he can redirect to a big enough chunk of unused memory, there is not telling what will come of it.
Gotta love all those shiny objects...
341 - 360 of 646