开云体育

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

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





Join [email protected] to automatically receive all group messages.