You can backup / restore your EEPROM using @Mr.Blinky’s Python utilities:
Thanks for your help! Now should I clear the EEPROM and try again?
I’d try to upload the original hex files using the uploader python script first. If that doesn’t resolve the problem. backup the EEPROM and then erase it.
The .hex flashed fine onto the Arduboy but still displaying an error message(load next game!). Backing up and erasing EEPROM now. Thanks for all the help!
Ahhh… Finally working really well! I’ll keep that backup of my EEPROM in a safe place. @crait Circuit Boy is hard! I don’t want to lose my lvl. 20 progress.
@filmote I’m loving your port of Lode Runner!
Thanks @dezli … it is as close as I could make it. Did you play it back in the day? I certainly did.
You could also try clearing the lode runner game data:
Make a copy of your backup and edit it in a hexeditor, change address 0x00AF to 0xFF, save it and upload the copy.
I’m a little bit too young to have played it when it originally came out but family members have and I have played other versions of it recently. It’s a good game where I can turn my Arduboy on, waste some time, and turn it back off again.
Wow … now I feel old! I used to play the original Apple ][ version for hours!
That’s not actually an error, that’s the message you get when you’ve finished one of the level sets so you know to flash the
.hex for the next set.
The reason you’re getting it when you haven’t played the levels is that Lode Runner is misinterpreting save data from one of the games you’ve already played.
It’s taken a while to happen, but this is proof that the ‘2 byte ID’ save method isn’t perfect.
Maybe it’s time to start using 4 bytes to further reduce the collision odds,
or using a checksum (if you can afford it).
Setting and checking a “magic number” ID, no matter how long, only indicates whether the ID itself hasn’t changed. It won’t tell whether any of the actual data has been clobbered. If you have a large amount of saved data, it’s easy for a different sketch to write over some of it without touching the ID.
Using a two byte checksum in place of a two byte ID doesn’t cost any extra EEPROM space but it would probably require more program memory.
I’ve already brought this up once before (in this thread):
In Minesweeper I use a 4-byte hash and a two byte ID.
(Which reminds me, I still need to fix the variable length array issue in the loading function.)
Why even bother with the ID? If another game used exactly the same data length and hash algorithm, you could add a unique “ID” value to the hash. This would save the two ID bytes in EEPROM.
If the ID wasn’t stored with the data and it was just added to the hash value then you can’t tell the difference between a corrupted hash and a hash for a game you don’t know about because any difference between the stored hash and the calculated hash could be a valid game ID.
Using a stored hash you have:
 hash  data length  game ID [*] game data
(The hash value includes the game id in the calculation.)
So if you calculate the hash and it’s correct then you know the data is all correct and the block belongs to the game with the specified game id.
If it’s not correct then you know something is wrong somewhere.
If you do it the other way:
 hash  data length [*] game data
Then whatever value you calculate for hash will have a difference from the stored hash value (and that difference will be the game id).
That difference could be any value,
and without knowing which game ids are valid,
you can’t know whether or not the hash value is corrupt.
I wrote a simple crc-16 routine a while a go. Would be perfect for something like this. now where did I put it…
So why do you care? Aren’t you only concerned about whether the data and/or hash for your sketch has been corrupted after the last time you stored it? You shouldn’t need to know or care about the ID for any other game.
Either the computed hash (adjusted with your game ID) is correct, meaning it’s very likely it’s your untouched data, or it’s incorrect, meaning you should (possibly warn/prompt the user and) reset it.
Personally no, I’m also concerned about being able to tell whether I’d be trampling over another game’s data.
In Lode Runner’s case, perhaps it would only care about its own data.
Originally I’d ideally have liked this to be a part of a more sophisticated system that could identify which parts of EEPROM are in use by games and inspect them,
but I never got round to developing such a system.
That’s why I said
before mitigating the corruption.
Which is what I was assuming. There have been numerous discussions about standardising EEPROM storage across sketches. Nothing has come of it, so detecting corruption of you own sketch’s data is about all you can do, especially this late in the game.
Best game ever!
I agree 100%