@ Casey,
Unless your LA tests determined otherwise, I imagine the refresh is from data stored in the uC for that mode to the divider.
Infact, that might explain a lot of the buss activity you were seeing since the divider FF/register is fed from the addr and data lines
?To emulate the EEPROM in mode based operation the uC will have to be commanded to re-read the EEPROM (ie:via a mode increment cmd) and it is multiple memory locations so it will step thru at least 16 (probably all 24) addresses to get the data it wants for a complete byteset.
You have to decode the addr lines to know what it is asking for, so you might as well associate all that data to that address request in memory anyway.
VFO mode is something that needs to be evaluated. I dont know of a single SB9600 or other cmd that will initiate a re-read of the EEPROM for the same mode. It would still be a 16 or 24 byte read regardless.
Maybe a macro of the SB9600 commands that perfoms the random access to mode selection function....sel/keypad1/sel or whatever the actual sequence is...I dont recall ATM
Repeating that macro should force the uC to re-read of the same place(es) in the EEPROM's memory, until a COS (in the case of a search feature, another input needed for non OEM scan function) or an end routine command is received.
You would have to inc/dec or encode FPP input and write that data to the address of the 3 bytes used for rx VCO frequency in the Pico (or whatever is used) memory of the mode you are re-reading before each execution of the SB9600 macro. Likely doable, but could get complex.
