Most of my games use EEPROM, This game is using 2 bytes located at 989 and 990. All of my games are between 974-990 currently. I have tried to limit my footprint in EEPROM in the hopes i won’t step on another program. The arduboy file shows the EEPROM locations i am using so the user can see if it might clobber another save. In the case of Leanna the Lion the game asked if it was allowed to save on every boot.
I currently have no problem making the source code for my games available for those who want to compile themselves or those who want to learn.
I suspected that would be the case.
Glad to know my suspicions are correct, I will keep up the habit of checking EEPROM locations.
Glad to hear you’re cautious about EEPROM.
I wasn’t trying to acuse you of anything, it was merely a blanket statement.
(Come to think of it, I haven’t got round to picking an EEPROM location for either of the games I’ve been working on, so I’ll make sure to do that later.)
Come to think of it, @eried, do you keep statistics about your game repository?
I’d be interested to know what the spread of EEPROM usage actually is, to find out just how many games put their EEPROM writes at the start.
(If it’s a lot maybe come January we ought to start a ‘reassign your EEPROM’ campaign to try to level it out a bit.)
Check out Harambe’s Revenge for EEPROM usage that wear levels and validates the save using a crc. That strategy starts at the beginning of usable EEPROM(skips the arduboy2 save data) and will fill the entire EEPROM if enough saves accumulate and then it rolls back over.
No I do not keep anything besides what is on the git repo itself. Maybe I could use a modified version of @FManga emulator to list the accessed EEPROM addresses. It wont be perfect, but it will provide some insights
One of the reasons that the EEPROM fields were added to the info.json file in a .arduboy file was to allow an uploader/manager to parse and summarise, and possibly highlight conflicts of, the EEPROM usage of all the sketches in a repository. This is why handling .arduboy files is recommended over raw .hex files.
If people are using proper .json files then it would just be a matter of taking the EEPROM records from that (assuming people are filling that information in properly).
I think you already parse the .json at some point to get all the game info.
For something more accurate it would be necessary to inspect the source or the hex, but that’s probably more effort than it’s worth.
If I had the power, I’d branch it off into a new thread to avoid the derailment.
That was my goal. I want to set a precedent of using the entire EEPROM. I see no way to prevent collisions in the long run and there has been no consensus on how to share by allocating static addresses. Even if there was eventually there would be more games than EEPROM space. If you look at my strategy I believe it could be adapted to arbitrary size payload. If one were to add an identifier in the payload they could confirm that it was their save and if everybody used the same strategy the EEPROM could be not only shared but wear leveled.
I downloaded the V1.2 source as a zip file (under ‘XTRA FILES’) and the game freezes after a few moves. I thought it might be a fluke, but it happened three times in a row all within a handful of moves. Also, the theme on this game is making me hungry