>The idea is to hex edit the data for the "VFO" mode on the fly.? This
>is based on my current belief that single bytes in EEPROM can be
>written via SB9600.? This is the key.
If you can find a means to write select single bytes via SB9600 that will be a game changer. Even with expected re-writes in the 10k plus range before failure, I think VFO/FPP changes will wear hard on (presuming) mode 1 byte locations and even harder on the CS locations. The CS locations will be hit the most since it changes with every edit (unless you are REALLY lucky).
I've given some thought to a means similar to how the Spectra CS cheat is done? by doing differential CS calc and changing "some unused byte(s)" inside the CS field to value(s) that negate having to actually change the real CS.
At one time I loosly coded a differential CS calc The only test were POC for "the math". I never made any hardware POC tests. Too many other irons in the fire...
When we were "in the box" the wear could be easily managed since we could pull CS values from anywhere the code designated in the Pico's memory, and feed them to the radio uC on demand.If a location was to become unreliable or otherwise compromised, the code could be revised to revector to new locations for that address and it's good for another 10k plus writes. Rinse, lather, repeat as needed.
Yes parallel EEPROMs are still out there. When I started out looking at creating an FPP system for this radio I actually had in mind putting an SRAM on the bus to program and "swap in", leaving the OEM config as undisturbed as possible.
Yes it would need a battery to retain info when 5v (unswitched) is lost but based on my experience with Motorola Digicipher receivers and VC II sub boards, the backup batteries for the sub/UID data chips can last up to 20 years. I'm pretty sure that's not the battery I'll be worried about 20 years from now...lol ?
>So frequency / PL / DPL data comes into the "xcat 9k" via some means
>(Doug Hall, CI-V, keypad, morse code, DTMF, voice recognition...)
>which the"xcat 9k" converts to edits of the VFO mode via SB9600.
>Additionally the EEPROM checksum would be adjusted as needed.
>RSS could still be used in the usual manner.? It should be easy to
>write a new script to upload code plug binaries using a modern
>computer to avoid the timing issues with RSS.
>An ESP32 is certainly doable as easily or easier than a RPI Nano.
>
>For the record the 3 GPIO lines are for Busy in, Busy out and Write
>enable EEPROM (by grounding Mic high!).
>
>Of course additional GPIOs or serial ports (or Bluetooth radios or
>something) are needed to get information into the box on what to do!"
You left out "mind meld"..lol
Yeah, ATTinys might not make the cut for GPIO. I mentioned the ESP32 mostly because it had potential in the beginning. I've never messed with one so I cant speak to it's features or failings.
The RPI Pico may be overkill as well, but are super cheap. The Arduino Nano checks most of the boxes,size,GPIO and tried and proven Uno development so it is very versitile and lots of misc code snippets and routines "out there" that others have already worked out the function(s).
Price point is => than the ESP32 for a lot less horsepower and features though.
Truth is, once(if) the SB9600 routines are mastered sufficiently a UI/"client" to the Xcat9k can be platform independent and as complex or simple as needed.
??
>Reprogramming mode names in the control head might be doable, but as
>with the radio the code plug format would have to be understood first.
>I've been disassembling the radio's firmware to understand things.
>I'm not sure how accessible the control head firmware is ... it isn't
>EPROM based is it?"
Yes there are EEPROMs for FW and "codeplug" data. The chip package and memory size depend on which model. The 1033 series was the earlier gen workhorse and probably the most popular. They have 28C16 or optional 28C64 EEPROMs for the CP data. Mike B.'site has a great breakdown of System 9000 stuff.
?Maratracs use a 1032(?) I think it is. Same clamshell/similar look...DO NOT CONNECT to your X9000! It is completely different inside.
I've only breifly looked at a .CDT in hexview.
IIRC, the alpha tags for mode names and MPL are in plain text. I dont know if the starting point is static and fixed to a given mode/MPL but if so, byte level editing of these parameters should be trivial if SB9600 support is sucessful. As you said the codeplug layout is TBD.
I suspect the CS exisits and is similar in nature to the .RDT files ?
Button/function assignment, VIP programming, etc would require real RSS or a much more complex set of routines than would be needed to edit some ASCII values.
I'm of a mind that a? full-fledged replacement for the RSS is a project all in itself. ?
>BTW Much to my total shock and amazement AT28C64 EEPROMS in a DIP
>package are still
>readily available!? Both Mouser and digikey have them in stock for around $6."
Yeah, that does surprize me too, considering the "chipdemic" has shorted so much of the other components. Must be a serious surplus of the DIP stuff yet to be used.
That kind of stuff and more like it is always on Ebay too. I think most of that is salvaged from crap we dumped on China or ex eastern block countries that arent under RoHS directives.
I've always been quite the PCB scrounger. Before I retired, electronic recycling (aka E-waste) came thru our shop for evaluation. Guess who got to dig in the "scraps" before they met their doom?
I got to pick thru lots of boards etc, saving EEPROMs and SRAMs and such with "potential" from their untimely demise...lol
