Kooky Kookies - Neo Retro Game

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.

1 Like

There is no built in EEPROM wear levelling. For a given specified address it will always write the same physical cell, and each cell is limited to a certain amount of write cycles.

1 Like

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.

1 Like

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

I’m planning on showing what addresses are used and how many times they’re overwritten so the user can be aware of the wear.
Maybe we could add a flag to the URL to send the statistics somewhere?

It’ll probably have to wait until the end of the jam, though.

1 Like

That would be perfect. I was thinking on just sending random keystrokes to your emulator. Maybe you can add a “input simulator tab” so it is easy to test games with a simple script


Or maybe that is overkill :smiley: and sending random keystrokes is good enough if we have eeprom (ram?, cpu cycles?) access stats

PS: This topic is drifting too much :stuck_out_tongue:

This would be really useful for general testing/debugging. Will add to to-do list.

We totally derailed this thread. Sorry, @shdwwzrd!


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.

Thus clobbering the saved data of any other sketches previously uploaded :frowning_face:

Not a problem, I find the discussion interesting and needed.

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.

Think i will add the “ALLOW SAVING OF GAME DATA TO EEPROM?” to the beginning of the game for those who do not want the game to save to EEPROM.

Should the game state the EEPROM locations it will be using?

Suggestions are welcome.

Make a new topic for code testing and eeprom discussion!

Don’t admins have the ability to split all comments after a certain point off into a separate thread?
(I’ve seen that done with other sites running on Discourse.)

Probably better to use the existing topic. Although it’s a long thread, it will keep the discussion in one place and much of what’s being discussed here has already been talked about there:

1 Like

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 :yum::yum:

Strange behavior, I’ll check it out as soon as I get home. Thanks, I thought the theme fit well for the game type.

i am unable to duplicate your issue. What version of Arduino IDE are you compiling with?

1 Like