.cht file structure?

[Ichinisan]

After a little examination here's what I've come up with:

Code: Select all

For every cheat:

1 byte    toggle indicator, 0x00 - on, 0x04 - off
1 byte    cheat value
3 bytes   code address in little-endian
1 byte    previous value
2 bytes   unknown, 0xFE 0xFC seem to work fine
20 bytes  name (ZSNES GUI only allows to input 18 chars, but you can put 20 in the file and seems to work fine)

Now pick apart the structure for GG codes, PAR mirror/reflector codes, etc.

I was kinda expecting a thanks, or a link to somewhere if this had already been done. The technical specs for NES GG can be found here, but I have no idea how much they match with SNES GG. I also have no idea what PAR mirror/reflect codes are.

I found the same information in about 1 minute with a hex editor and made a quickie app in VB for renaming/rearranging cheats and editing PAR cheats. I haven't even bothered to examine how ZSNES stores a GG code, or PAR mirror/reflector codes (mentioned in docs). I just wanted to make sure you knew that PAR cheats are not the only type.

[Shadowbird]

I found the same information in about 1 minute with a hex editor and made a quickie app in VB for renaming/rearranging cheats and editing PAR cheats.

Then why didn't you share the info on the file structure?

I haven't even bothered to examine how ZSNES stores a GG code,

GG codes are automatically converted to PAR codes when entered in the gui.

or PAR mirror/reflector codes (mentioned in docs).

Since I have no idea what PAR mirror/reflector codes are, can't help you there. But I would guess that if they are supported, they are converted just like GGs - in the interface - and then saved as PAR (if possible).

[Ichinisan]

I don't think a real PAR ever supported mirrors or reflectors, it's a feature of ZSNES that accepts a PAR-format code and mirrors a value from another address. I would expect the CHT format to store this as two records with idetifying bits, possibly in the first byte of each record.

I didn't feel the need to share my past observations because what I know about the layout is super-easy for anyone to figure out if they had any intention/capability to create an editor. I could have sworn that it was posted in one of these threads.

I've also noticed that ZSNES ends the description with a null byte (00). I've seen screwy-looking descriptions where the null byte was followed by characters remaining from a previous description. I guess this happens when a cheat with a long description is deleted in ZSNES and the following cheat had a shorter description. Just a tip, anyone making an editor should parse the description by character and stop at the first null byte or the 20th character, whichever comes first. Always reading the full 20 bytes past any null values will result in some confusing descriptions.

[creaothceann]

Just a tip, anyone making an editor should parse the description by character and stop at the first null byte or the 20th character, whichever comes first. Always reading the full 20 bytes past any null values will result in some confusing descriptions.

Or just scan the string for the first null and fill the rest with nulls, too.

Likewise, the string should be filled with zeroes before storing the description in it.

[creaothceann]

*bump*