Re: Has anyone fully decoded the X9000 memory mapping?
|
Good points. We really need to figure out how to get something usable from this LA data. I assumed for whatever reason, the radio just iterated over the mode data again and again refreshing itself to make sure nothing was inadvertently corrupted along the way. I guess I got this mental picture?from the synth refresh description and likely incorrectly applied it to everything else. So, how do you suspect scan works? You are saying the radio reads the modes into the uP from the EEPROM all at once along with the PL data then executes operations using that data stored internally? I assumed it read in some codeplug structure info, determined what size of chip was on board, how many modes there are and then made the decision as to what EEPROM data locations to go and grab the freq an PL data, obtaining it on the fly based on scan flags in the codeplug and ultimately doing operations with it in a just in time manner by manipulation of the PL output lines, synth divider lines and other associated?functions.
We really have to map out the order of operation before we can do anything else or it's all just speculation.?
@ 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.
|
