I have a patch pending. I have something which works for at least some, but not all frequencies. I believe it improves the coverage of the driver, but I know it leaves some still missing, though I'm not sure I have time to fully figure everything out, so I'll leave my notes here:
Details:
It turns out the first three bytes of each memory location includes some flags. I believe the first 6 bits are flags, and here are what the masks seem to mean:
0x08 = frequency multiplier is 6250 (default is 5000)
0x10 = frequency multiplier is 25000/3 (~8333) (not entirely sure)
0x01 = offset multiplier is 6250
The remaining 16 bits are the steps on that multiplier.
For example, if the first five bytes are 0x205a010079, this breaks down to flags of 0x08, for a frequency multiplier of 6250 and default offset multiplier of 5000. The remaining frequency bytes are 0x05a01. 0x05a01 * 6250 = 144006250 for a frequency of 144.00625 (note this requires a TS of 6.25). The offset is 0x0079, with a multiplier of 5000 = 0.605 (non-standard, I was testing).
Another example: 0x245a010061. The frequency flags are now 0x09 = 0x08 | 0x01, implying a frequency and offset multiplier both of 6250. Remaining frequency = 0x05a01 * 6250 = 144.00625 still, but now offset . 0x0061 * 6250 = 0.60625.
The flag of 0x10 for a frequency multiplier of 25000/3 is a bit tricky, though, because not all bytes correspond to the exact multiple, in terms of displayed frequency, so I haven't fully figured out what's going on there. For example, I notice it seems to use that representation for a lot of the really low frequencies the radio can handle (e.g. 118.000 MHz).
For example: 0x483750. Flags are: 0x12. The remaining frequency is 0x3750, and 0x3750 * 25000/3 = 118000000 = 118.000 MHz. But, go up to 118.005, and the frequency bits stay the same: 0x483750. But, the TS and mode bits change. Go up past that, and it seems to regularly increment the frequency flags: 118.010 = 0x483751, 118.015 = 0x483752, etc. The frequencies are not exact multiples of 25000/3, though, but are close. So, this needs more research to figure out how this is being encoded.
I've also discovered while doing this that the modes the memory supports includes at least AM and narrow AM, so I'm adding that in my patch too. I just don't have time right now to figure out exactly how the TS, mode and frequency bits all work together to encode these lower frequencies.
If you play around and find other frequency/TS/mode combinations the radio doesn't support in the ham bands, though, let me know (new bug, I guess) and I can try to figure those specifically out, at least.