[chirp_devel] Image Format Proposal

[Dan Smith]

> Why don't we just improve match_model() where needed? I've never had
> an issue... it's not apparent to me that the current method is
> breaking down :-)

I present to you, the following:

Exhibit A:
        if len(filedata) == 8192 and \
                filedata[0x60:0x64] != "2009" and \
                filedata[0xf00:0xf05] != "KGUV6":

Exhibit B:
        return len(filedata) in [0x1808, 0x1948]


Exhibit C:
        return filedata.startswith("\x13\x60\x17\x40\x40\x00\x48\x00" +
                                   "\x35\x00\x39\x00\x47\x00\x52\x00")

Exhibits D1 and D2:
        # This is a horrid hack, given that people can change the GPS-A
        # destination, but it should suffice in most cases until we get
        # a rich container file format
        return len(filedata) == cls._memsize and "API880," in filedata

        # This is a horrid hack, given that people can change the GPS-A
        # destination, but it should suffice in most cases until we get
        # a rich container file format
        return len(filedata) == cls._memsize and "API80," in filedata

Exhibit E:
        if not len(filedata) == cls._memsize:
            return False
        return filedata[-16:] == "IcomCloneFormat3"

Exhibits F1 - F5:
        return len(filedata) == cls._memsize and \
            filedata[0x64] == chr(0x00) and filedata[0x65] == chr(0x28)

        return len(filedata) == cls._memsize and \
            filedata[0x64] == chr(0x00) and filedata[0x65] == chr(0x50)

        return len(filedata) == cls._memsize and \
            filedata[0x64] == chr(0x01) and filedata[0x65] == chr(0x44)

        return len(filedata) == cls._memsize and \
            filedata[0x64] == chr(0x02) and filedata[0x65] == chr(0x22)

        return len(filedata) == cls._memsize and \
            filedata[0x64] == chr(0x04) and filedata[0x65] == chr(0x00)

Exhibit G:
        self._isuhf = (ord(self._mmap[0x1930]) != 0)


Several of those are testing user-modifiable data, and most of the rest
are checking things we *think* might be static, but aren't sure. Some of
the chinese radios' memories grow as firmwares improve and features are
added, which makes detecting by file size pretty ugly.

Aside from the need, any comments on the actual format I proposed?

-- 
Dan Smith
www.danplanet.com
KK7DS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20120927/49bd05b3/attachment-0001.bin