Arduboy Semi-Official EEPROM Table

A post was merged into an existing topic: Shared EEPROM storage management across multiple apps

It’s not quite exactly the same topic / issue from 5 years ago tho.

But this topic should be used only for maintaining and discussing the spreadsheet, not proposing new EEPROM management methods.


Updated my list with Puzzle category. Scanned a total of 242 programs of which 119 use EEPROM now.


What are the chances of not being able to support all the games’ use of EEPROM, considering we have games like MicroCity that uses all of it? (From my understanding.) Or my game, that uses like 420 bytes? What’s our plan for dealing with this?

Well what we already can tell from the unfinished list is that there are quite a few games that corrupt the system settings and those have to be fixed (preferable) or excluded (doesn’t solve corruption on manual upload). Then there a quite a few programs that use a lot of EEPROM and easily cause a collision

Since we’re recompiling everything, could we have different EEPROM banks? At the start of each sketch, we could add a line of code in setup() that would dictate the EEPROM bank being used, then swap it in/out of memory as part of the load/boot process? I know there was some discussion, but it seemed like the discussion was about saving EEPROM to a different memory space every time. This way would be only once a game loads.

In the library, it could look something like this…

void load_bank(int new_bank_location) {
    int current_bank_location = get_current_bank_location_from_EEPROM();
    if(new_bank_location == current_bank_location) {

In the sketch…

void setup() {

@Mr.Blinky - I’ve just added in your latest ‘puzzle’ additions. Great progress! :slight_smile:
Our details disagree on 4 games by @obono, see:

  • Chie Magari Ita
  • Psi Colo
  • Reversi
  • Stairs Sweep

Here the author (Obono) created the entries… Perhaps it’s worth discussing the details in the specific game threads?

It’d be awesome if you wanted to directly add to the GoogleDoc- it’s open for the whole community.


@crait After seeing the large number of programs (and their sources) it would be very time consuming to add some kind of management system to games. besides that games that use a large portion of EEPROM would still have collision issues.

So I’ll be focusing on my backup/restore idea for the bootloader again.

Relocating games is still recommended though to reduce the wear on the same EEPROM locations and a backup / restore will also use the EEPROM location size info for a partial backup / restore to reduce wear

I guess @obono was misled by his own remarks in the source. Which do not match the actual record sizes used. He probaby forgot to update them.

I’m working with an offline excelsheet which works better for me and I’m not done with the list yet.

1 Like

I think this is where it would be helpful to have my sorting done, because in practice you could focus work on just the top few on that category with the understanding that carts below a certain point are “not optimized and may corrupt EEPROM (save games)”.

This kind of flag, or sorting would be helpful for certain games like microcity that take up most of it anyways.

I am not sure where this is going.

Are you trying to understand what each is using in order to alter games to avoid collisions? If so, you will obviously have to decide which games to focus on as you will not be able to cater for all the games in the limited EEPROM available - especially if some use a lot of EEPROM.

Are you looking to change some of the games to ‘even’ out EEPROM usage? Again, what games are you / we focusing on?

Are you / we looking to change the FX cart system to back up the EEPROM before switching games? In this case, you probably want to move all of the data to the same spots in the EEPROM so that the backup / restore routine can be simplified. (I assume backing up the entire EEPROM is inefficient but I know little of the FX mod to comment).

One great outcome of this exercise is to identify the games that overwrite the reserved EEPROM or sections of it.

Thats what I mentioned, creating a sort order for the categories so that the “favorites” are picked, and we try to make a best effort to prevent the EEPROM collisions from the “greatest hits”.

Developers will also be encouraged to make edits as well.

I mean, I’m pretty sure we can do this tens of thousands of times without issue, but in general I think if the top 50ish games don’t cause collisions I will say we have done a good job. Anything more than that I think will be really amazing. None of it is that “necessary” I don’t think, because I don’t get a lot of complaints of people going “oh my save game is corrupted”… however the likelihood of that goes up when people are encouraged to swap between games in rapid order.

I knew as I was writing this that someone would mention the read / write limits … these are really not an issue if we are talking about normal use.

Having only 50 really good is better than having 50 good games buried amongst 200 half finsihed finished games, IMHO. Of course, the 50 good games is subjective.

It’s not misled. :slightly_smiling_face:
RECORD_T remark in common.h is correct, at least under my environment.
It may be affected by the build condition.

to infinity and beyond
I wanted to get a clear picture of the EEPROM collisions.

It’s clear that I’ll not be altering 150+ games.

Nope not anymore. It would take me too much time and can’t prevent collision with the bigger games. I leave that to the authors. I’ll be focusing om backup/restore. But reducing collision willstill be beneficial for EEPROM wear and Non FX Arduboys.

I’ll be looking into that. But I’ll also need the EEPROM usage values for that.

That exactly what I do not want.

The intention is to only backup and restore what is actually changed not the 1K (- system bytes). Both for wear leveling and speed.

I agree on that.

My sincere appologies @obono :pray: :bowing_man: I now realize that your using bitfields! How silly of me not noticing that :man_facepalming:

Do you mean that your sources on Github Master branch are out of date?

I based my findings on that.

* Chie Mari: My appologies :pray: :bowing_man: I miscounted there.

* Psi Colo: I count 30 (6 * 4 + 5 * 1 + 1) for record size not 22. With u32 signature and u16 checksum thats 36 bytes.

* Reversi: I count 32 ( 8 + 8 + 5 + 2 + 3 + 4 + 2) for record size not 26. With u32 signature and u16 checksum thats 38 bytes.

* Stairs Sweep: I count 46 (5 * 8 + 4 + 2) for record size not 26. With u32 signature and u16 checksum thats 52 bytes


I thought I was the only one who had attempted to use checksums to protect save data,
I didn’t realise @obono had done it too.


LOL …        

Yes! Bitfields! :smile:

Yes! Checksum!! :smile:

1 Like

I’ve mentioned it in another thread but alternatively we could find some way to make the FX-ROM-packing tool patch the ROMs to move the EEPROM range around.

Most games have enough PGM bytes left to add EEPROM offset code from a “variable” read from PGM ROM.
Not sure how easy it’d be to fix all their savegame code for it, but surely we can patch a few and that would help.

The tool could check for conflicts and requirements, we can also put requirements for games that aren’t relocatable in some INI file.

As a user I’d want to assemble a custom set of my favorites without having to go through the trouble of rebuilding every game and resolve conflicts by hand.

1 Like

Is this really that difficult to do? We could put all games into their own bank and then the ones that use huge chunks of memory and put them into their own banks since there’s only a handful of games that do that. Perhaps we could bake this into the bootloader, itself?