How to Save/Run Snes SRM Files w/ Hex Editor?

[simpleman]

So I've done research on when you change a snes srm save file in hex editor, how do you keep the save file from "deleting itself",
after you change it.

I read this guide quite a bit on how to "generate a checksum": http://www.gamefaqs.com/snes/588648-seiken-densetsu-3/faqs/9788

In that game he mentions that you need to highlight offset 70 to 7FD, then generate a checksum-16 and enter them in offset 7FE &7FF.

So I figured this method would be similar for other snes games?

So for example, for Harvest Moon Snes, I used PAR Codes here: http://www.gamefaqs.com/snes/562623-harvest-moon/faqs/18838 to help me figure out what offsets effect different things in the game.

I figured out that offset 0000001A when changed to "13" gives you a Golden Hammer in your inventory.
But of course if I edit that in the srm file in hex editor and try to run the game, it just deletes the save and creates a new save.

So following how the person did it on for the Seiken gamefaq, I looked for two offsets that could represent the checksum..
I noticed that offsets 0000002F & 00000030 always changed when I compared different save files, so I figured those were the checksum.

Now I tried highlighting all kinds of different areas, even like what the person from the Seiken gamefaq did (offset 70 to 7FD),
but I can't get a checksum that matches the ones already generated.

Which brings me to my question of how do you figure out the checksum offsets for snes roms and go about changing them so your game runs correctly?
And did I find the correct checksum location?
Or is there another way to do this and how the Seiken gamefaq person did it is only done for just that game?

I'd appreciate if anyone had the steps I and others could follow to get this to work.
Thank you and I very much appreciate any help.

[denim]

You have two save games in harvest moon. The first uses the 16bit checksum of the first $1000 bytes, i.e., 4096 bytes. The result is stored in the word at offset $002f for the first save and $102f for the second save. The second save uses the checksum of words from $1001-$2000. Important to say that the checksum word can't be added to the result. The game stores a zero in it before evaluate the checksum.

Code Select Expand

$83/BB28 A0 2F 00    LDY #$002F              A:0000 X:057C Y:002E D:0000 DB:00 S:1EFD P:envmxdIZC HC:0144 VC:255 FC:55 I:00
$83/BB2B B7 72       LDA [$72],y[$70:002F]   A:0000 X:057C Y:002F D:0000 DB:00 S:1EFD P:envmxdIzC HC:0192 VC:255 FC:55 I:00  ;the checksum
$83/BB2D 85 7E       STA $7E    [$00:007E]   A:5D9B X:057C Y:002F D:0000 DB:00 S:1EFD P:envmxdIzC HC:0250 VC:255 FC:55 I:00
$83/BB2F A9 00 00    LDA #$0000              A:5D9B X:057C Y:002F D:0000 DB:00 S:1EFD P:envmxdIzC HC:0284 VC:255 FC:55 I:00
$83/BB32 97 72       STA [$72],y[$70:002F]   A:0000 X:057C Y:002F D:0000 DB:00 S:1EFD P:envmxdIZC HC:0332 VC:255 FC:55 I:00 ;store 0000 in the checksum offset
$83/BB34 A0 00 00    LDY #$0000              A:0000 X:057C Y:002F D:0000 DB:00 S:1EFD P:envmxdIZC HC:0390 VC:255 FC:55 I:00
$83/BB37 64 80       STZ $80    [$00:0080]   A:0000 X:057C Y:0000 D:0000 DB:00 S:1EFD P:envmxdIZC HC:0414 VC:255 FC:55 I:00
$83/BB39 B7 72       LDA [$72],y[$70:0000]   A:0000 X:057C Y:0000 D:0000 DB:00 S:1EFD P:envmxdIZC HC:0472 VC:255 FC:55 I:00 ;start to sum all words from save block
$83/BB3B 18          CLC                     A:0200 X:057C Y:0000 D:0000 DB:00 S:1EFD P:envmxdIzC HC:0530 VC:255 FC:55 I:00
$83/BB3C 65 80       ADC $80    [$00:0080]   A:0200 X:057C Y:0000 D:0000 DB:00 S:1EFD P:envmxdIzc HC:0588 VC:255 FC:55 I:00
$83/BB3E 85 80       STA $80    [$00:0080]   A:0200 X:057C Y:0000 D:0000 DB:00 S:1EFD P:envmxdIzc HC:0622 VC:255 FC:55 I:00
$83/BB40 C8          INY                     A:0200 X:057C Y:0000 D:0000 DB:00 S:1EFD P:envmxdIzc HC:0656 VC:255 FC:55 I:00
$83/BB41 C8          INY                     A:0200 X:057C Y:0001 D:0000 DB:00 S:1EFD P:envmxdIzc HC:0674 VC:255 FC:55 I:00
$83/BB42 C0 00 10    CPY #$1000              A:0200 X:057C Y:0002 D:0000 DB:00 S:1EFD P:envmxdIzc HC:0692 VC:255 FC:55 I:00 ;$1000 bytes loop
$83/BB45 D0 F2       BNE $F2    [$BB39]      A:0200 X:057C Y:0002 D:0000 DB:00 S:1EFD P:eNvmxdIzc HC:0716 VC:255 FC:55 I:00
$83/BB47 C2 30       REP #$30                A:5D9B X:057C Y:1000 D:0000 DB:00 S:1EFD P:enVmxdIZC HC:0182 VC:121 FC:57 I:00 ;here we have the final result
$83/BB49 A5 7E       LDA $7E    [$00:007E]   A:5D9B X:057C Y:1000 D:0000 DB:00 S:1EFD P:enVmxdIZC HC:0206 VC:121 FC:57 I:00
$83/BB4B C5 80       CMP $80    [$00:0080]   A:5D9B X:057C Y:1000 D:0000 DB:00 S:1EFD P:enVmxdIzC HC:0240 VC:121 FC:57 I:00 ;compares with the value stores
$83/BB4D D0 12       BNE $12    [$BB61]      A:5D9B X:057C Y:1000 D:0000 DB:00 S:1EFD P:enVmxdIZC HC:0274 VC:121 FC:57 I:00 ;reset block if checksum is wrong

[Jorpho]

If I'm not mistaken, there's no reason to expect Harvest Moon to use the same checksum generation method as SD3.

Which brings me to my question of how do you figure out the checksum offsets for snes roms and go about changing them so your game runs correctly?

As Mr. Denim implies, I think the only way to be sure is to look at the assembly code of the game.  It is not necessarily a straightforward process.

Also note that checksums for SNES ROMs and checksums for SRAM data are two very different things.