[chirp_devel] Wouxun KG-UV6D memory map available
I would love to participate. I am not all familiar with the existing codebase and conventions, byt I know a bit or two about programming (major hobby of mine for more than 30 years).
Is there som git/cvs system set up for cooperative coding, or am I supposed to check out a newish version, transplant my patches, run a new diff and post the result?
I started a new project, mapping the areas that are still unknown to me for different models/firmware for a chance to spot differences. Basically I make a hexdump using xxd for the unknown areas, making it easier to run a diff without being confused by any known setting being different. The files are uploaded to the issue section, I guess, so look for the there.
I may not find it a bit useful myself, but it would be a nice hack to implement (at least) read support for Wouxun proprietary .wx format. The KG-UV Commander has it. there is some information available in Yahoo groups.
Regards, Johan Adler
On Thu, Nov 1, 2012 at 9:26 AM, Johan Adler johan.adler@gmail.com wrote:
I would love to participate. I am not all familiar with the existing codebase and conventions, byt I know a bit or two about programming (major hobby of mine for more than 30 years).
Is there som git/cvs system set up for cooperative coding, or am I supposed to check out a newish version, transplant my patches, run a new diff and post the result?
http://chirp.danplanet.com/projects/chirp/wiki/Developers
You pull code from the Mercurial reposititory, and submit new code as patches to this list. Mercurial's mq extension makes managing your patches simple, then you can send them with the Patchbomb extension.
I started a new project, mapping the areas that are still unknown to me for different models/firmware for a chance to spot differences. Basically I make a hexdump using xxd for the unknown areas, making it easier to run a diff without being confused by any known setting being different. The files are uploaded to the issue section, I guess, so look for the there.
I use hexdump+diff for initial analysis, then move to Chirp's "show raw memory" as soon as possible. This doesn't really apply to settings--Dan, is there a show raw memory equivalent useful for settings?
I may not find it a bit useful myself, but it would be a nice hack to implement (at least) read support for Wouxun proprietary .wx format. The KG-UV Commander has it. there is some information available in Yahoo groups.
I found the format used by the VX-* Commander programs is identical to Chirp's .img format (clone dump) for the corresponding radios. This made it very easy to support in Chirp. Maybe .wx is the same?
Tom KD7LXL
Dan, is there a show raw memory equivalent useful for settings?
No. We could add it, I guess, but it's just duplicating hexdump, which every self-respecting OS should have. The memory diff utility is very specifically useful, which is why it's there of course.
On Thu, Nov 1, 2012 at 10:07 AM, Dan Smith dsmith@danplanet.com wrote:
Dan, is there a show raw memory equivalent useful for settings?
No. We could add it, I guess, but it's just duplicating hexdump, which every self-respecting OS should have. The memory diff utility is very specifically useful, which is why it's there of course.
The "show raw memory" feature tells me two things that hexdump doesn't: - the I'm seeking to the right position - that I have correctly defined the structure in Chirp's bitwise syntax
It's more of a Chirp integration test than an exploration tool.
Tom
The "show raw memory" feature tells me two things that hexdump doesn't:
- the I'm seeking to the right position
- that I have correctly defined the structure in Chirp's bitwise syntax
It's more of a Chirp integration test than an exploration tool.
Sorry, I misinterpreted. You mean something to take an existing setting and dump the raw memory for it? I thought you were talking about just replacing hexdump functionality for whole-image diff'ing.
Settings are not directly mapped to a chunk of memory in the same way, so I don't think there's any reasonable path to go from the abstract setting object to the memory chunk it represents. If you can figure out a way (or a reasonable change) then that might be doable.
I would find usefull having a way to inspect full _memobj content, I mean see how the full MEM_FORMAT apply to actual memory contents.
my two cents ...
73 de IZ3GME Marco
On 01/11/2012 17:19, Dan Smith wrote:
The "show raw memory" feature tells me two things that hexdump doesn't:
- the I'm seeking to the right position
- that I have correctly defined the structure in Chirp's bitwise syntax
It's more of a Chirp integration test than an exploration tool.
Sorry, I misinterpreted. You mean something to take an existing setting and dump the raw memory for it? I thought you were talking about just replacing hexdump functionality for whole-image diff'ing.
Settings are not directly mapped to a chunk of memory in the same way, so I don't think there's any reasonable path to go from the abstract setting object to the memory chunk it represents. If you can figure out a way (or a reasonable change) then that might be doable.
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
participants (4)
-
Dan Smith -
Johan Adler -
Marco IZ3GME -
Tom Hayward