@ Dennis,
Yeah, it's squirrelly.
For a 2k codeplug, the beginninf of the MPL data storage offset is 0700h, and goes for 64 bytes, ala 4 bytes (2 for RX,2 for TX) per MPL unit X 16 MPL units.
That is where the RSS begins to assign offset values for mode slaved PL data (in byte 7 of a mode's 24 byte set), referenced to the BEGINNING of the MPL storage location, ala 0700h.
This beginning addr is set on zero page and can be changed, but the stock RSS ALWAYS puts the 1st mode slaved PL values 17 MPL sets above the MPL data start (0700h default for a 2k EEPROM).
So... the OEM calculated offset for the 1st mode slaved PL is 11h (17d, 17th PL set). This doesnt have to be mode one. If the 1st mode slaved PL created is say, mode five, mode five will have 11h in byte 7 and reference the 4 bytes beginning 11h above 0700h.
Each PL set is two sets of two byte values, even if either is carrier squelch. Any mode(s) that use the same mode slaved PL data, get the same offset value in byte 7.
Each PL offset counts in two, two byte steps. so 11h references data in offset positions (bytes) 1,2(RX) and 3,4(TX). The 2nd created mode slaved PL will have an offset value in byte 7 of 12h and will reference data in offsets positions (bytes) 5,6,7 and 8.
There is another value on zero page that tells the RSS how many MPLs you have. Stock RSS allows it to be set to 10h(16d) max by default. Changing that to 20h (32d) forces the RSS to allow 32 MPL units to be entered and makes the 1st mode slaved PL offset to be 21h (33d),
....BUT each mode slaved PL created after that gets an offset value that is less by one...20h,1Fh,1Eh, etc until it gets back down to 11h.
If you have any MPL data in MPL units in MPLs 17-32, they are overwritten.
Edit or delete a mode slaved PL an it gets really interesting...Unique PL data values are copied/shufled down toward the expected beginning offset, if shuffled/moved, all byte 7 offsets are re-calculated and re-referenced, and as for the data that is copied, the original values are de-referenced and abandonded as clutter. That makes it really difficult to sort out what belongs and what is clutter.
I'm still not out of ideas for work arounds, but if the codeplug is to be extracted to be modified and re-inserted in the Pico, then using the RSS will destroy the work around structure...so far.
I really think the future of codeplug editing is going to be via a Java or VB runtime that can export a format that can be (re)integrated into the Pico possibly as a secondary step. I can provide structure/format information but writing such an application is beyond my skillset.
