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
toggle quoted message
Show quoted text
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
