Eeprom collision

But I think it would be considered just a minor, and likely rarely occurring, annoyance. The same risk applies to the existing system EEPROM settings in the first 16 bytes. A garbage user name could start appearing at the end of the boot logo sequence or a legitimately set name could be corrupted. The sounds in all games could stop because the audio mute flag gets set. The boot logo or RGB LED could start appearing on power up after the user has set the flags to disable them. Etc., etc…

It would also be annoying for someone to see their high score or level achievement corrupted because you suddenly started using the last location, that a game (any game) was previously legally allowed to use. Like I said, you can’t police all the games that are already out there. You don’t even know about the existence of some of them. And, you can’t prevent EEPROM corruption due to errors made during program development.

Keep in mind too, that there are utilities written for the Arduboy for clearing out EEPROM. Unless you can find them all (which, of course, you can’t) and alter them, someone using one could cause your issue. Some of these utilities, such as the Arduboy2 library’s setSystemEEPROM, give the option of only clearing the user area and leaving the system area unchanged. Unless the utility is altered, doing this would wipe out the last byte of EEPROM, thus affecting your bootloader flag(s), but not the first byte, so you wouldn’t have this problem if you used it instead.

In one way, having these minor annoyances could be considered a somewhat good thing. It highlights when a sketch is using the reserved area, allowing the author to be made aware of it, and (or at least) get the problem corrected. At the same time, if the discussion is public, it educates other developers about the existence of system EEPROM and it being off limits.

Also you were concerned about wasting EEPROM space (like using a whole new byte when you only needed a one bit flag). By using the last byte of EEPROM you’re not only taking over a byte that a sketch could use, or is already using, you’re also leaving the first EEPROM address still unused and “wasted”.

And I have to ask, how do you plan to document the fact that the last byte is now off limits, in a way that a good majority of developers are made aware of it?

All this because using the last address may have less chance (but not no chance) of being corrupted than the first.

Well, if the issue can’t be solved easily for any sketches that corrupt more than just the first byte of the first 16 bytes of reserved EEPROM, then there’s still a problem in regard to the Arduboy and Arduboy2 libraries, as I previously described.

In addition to posting the EEPROM usage in a google table, maybe we can list a start and end address to the csv table that is used for creating carts? If for no other reason it would be a useful way to catalog them, but one could also compare the addresses and look for collisions when creating the .bin file.

3 posts were split to a new topic: Arduboy Semi-Official EEPROM Table

41 posts were split to a new topic: Adding Hashing Capabilities to EEPROM

@filmote & @Mr.Blinky,
As developers switch to an exciting and shiny new :sparkles: EEPROM API :sparkles:, it’s an ideal time to look at EEPROM start and end addresses (esp. if we’re adding +4bytes for the hash).
Is it feasible to allow Developers to (conveniently) add this to your cart tool? It seems like the best, centralised repository we have. …In time it may warn of conflicts too :slight_smile: …?

@Pharap - sorry to keep adding to your pile! (The curse of capability!?)… I’m actually super excited that you’ve done this really important (and, perhaps, thankless!) task.

Yes … it could be added pretty easily.

What do we need - a start and end address … or a start address and a length?

A far more web-savvy person than me could easily look at a cart and render a mud map of the addresses used and highlight potential issues.


Inclusive start and end address (in decimal) was the most popular.

Edit for pedants: Ignoring any read/writes to the system area (e.g. sound flag, unit ID, etc.), as this is not game specific and may be accessed by all programs without collision. Obviously at this stage, no one should be accidentally writing in the reserved first 16bytes. Perhaps if the reserved address range is included, a warning could be issued?

And maybe a flag to say whether there it is using this or another hash system / guard system.

It would be pretty pointless unless the bulk of the games had the information. Would you like to take on the initial population?

I’m happy to copy and paste from the first survey. I’m not sure how accurate it is now… but should be good enough for a first draft…?

Not sure how the ‘hash’ flag is useful TBH. Could we agree to set to 0 so far and it will be 1 for future games using the new hash system? AFAIK essentially no-one is using a decent hash (apart from @Pharap’s ‘Minesweeper’).

My games have a rudimentary guard check.

Ok, so:


First, please can you accept the PR I created to deal with CSV line-endings :pray:

– Do you mean the 2 character magic signature?.. Since that only protects the first 2 bytes from collision (not the actual data), I don’t think its worth documenting. I haven’t looked at recent PPOT updates- sorry if I missed something.

No … a couple PPOT games have my own hashing algorithm.

Originally, I had in mind with the ‘magic signature’ that games would pick a ‘page’ - blocks of 16 or 32 bytes - and align with the start of them. In that way the signature would be good enough to protect the data as well. Bu then I started saving large things into EEPROM (much larger than a page) and realised the guards were not enough. Now I just use them to determine whether it is the first time the game has run or not.


1 Like


Did I mention there is a .csv for the XL, the PPOT selection and my curated list? They all need the fields.

Also, do we want to distinguish between those that do not use the EEPROM at all and those that may have settings but have not yet been entered?

Sorry - I don’t understand?

Sorry, a flag to say ‘this game does not use the EEPROM’ versus 'this may use the eeprom but the settings are not yet known.

“na” = not applicable (examined and doesn’t use EEPROM).
“” (blank) = not yet determined.
“0” = actual address 0; or FALSE for hash.

na na na na na na,
I, I, I ain’t gonna play Sun City

Sorry I didn’t see these in the commit you made. This is perfect.

1 Like

Done (with the data I had) :partying_face:

:sweat_smile: …If it’s ok, I will wait to see:

  1. If and how the data is used. Whatever you implement may need different formatting/ data, etc.
  2. How you will solve syncing other details; e.g. I don’t think you added ‘Site’ and ‘Source’ info to the other CSV’s(?)… This feels like a problem to solve with a script rather than human labour. I deliberately didn’t fix any issues with ‘Title’ or ‘Author’, in case you wanted to use those as a key to keep things in sync… :crossed_fingers:


PS- This was based on the initial survey. I think some issues have been fixed since, so consider this a ‘worst case’ starting point!..

I can’t help but feel that having something unconventional rather than the traditionally expected null is going to trip someone up later down the line.