Eeprom collision

Sometimes useless trivia about historical games comes in handy.

Anything not currently loaded into the game will be present in the ‘newer’ save block, so you should be able to just copy data from the ‘newer’ save block to the ‘older’/‘current’ save block.

As you say, it’s impossible to load an entire 4KB into RAM, so any save data that’s being modified will be smaller than that.

The hard part is specifying where in the 4KB block the data needs to be saved to.

If a game’s save data were only ever contiguous then it wouldn’t be a problem, you could just do (pseudocode):

uint8_t oldPageIndex;
uint8_t newPageIndex;
uint32_t saveIndex = findPageIndices(&oldPageIndex, &newPageIndex);

auto currentPageIndex = oldPageIndex
erasePage(currentPageIndex);
// saveDataIndex is the first address after the 'save index'

// Copy data from 'new' page to 'old' page
for(uint16_t index = saveDataIndex; index < startOfSaveBlock; ++index)
	write(oldPageIndex, index, read(newPageIndex, index));

// Write save data to 'old' page
for(uint16_t index = 0, writeIndex = startOfSaveBlock; index < saveDataSize; ++index)
	write(oldPageIndex, writeIndex, userData[index]);
	
// Finish copying data from 'new' page to 'old' page
for(uint16_t index = endOfSaveBlock; index < endOfPage; ++index)
	write(oldPageIndex, index, read(newPageIndex, index));
	
writeSaveIndex(oldPageIndex, saveIndex + 1);

But if save data doesn’t have to be contiguous then it becomes difficult.

But not so time consuming that EEPROM can’t do it?

I’ve been informed @Mr.Blinky is going and doing this all by hand for existing games on the “Goldcart”, from there we will have a table of available spaces left over after that.

1 Like

That’s impressive, @Mr.Blinky! :clap:

1 Like

My Shattered Lands engine uses 52 bytes of storage shared between each entry in the series. The games use the first 3 bytes to indicate the game ID. First 2 bytes is the game ID (SL for Shattered Lands) and the third byte for the game number in the series (1, 2, etc). So the planned 5 games in the series will share the same 52 bytes of EEPROM. Currently the engine just uses EEPROM_STORAGE_SPACE_START but can be modified to include an offset from there.

The save format allows for additional games/series to be made using the same engine and just change the 2 bytes for the game ID.

1 Like

What games are being included on the ‘Gold Cart’?

1 Like

To clarify with the help of community user @mameise I’m making a list of EPROM usage in programs based on @erieds repo and scanning the source files. With a complete overview of EEPROM collissions. It can be better decided what to do to limit the collisions.

1 Like

This is great. Could you put this up as a Google Doc spreadsheet? This would let active developers fix problems proactively. Would you also consider letting community contribute?.. (though I understand why you might want to curate this). :slight_smile:

2 Likes

A few years ago, I offered to set up a public wiki in this forum to maintain a record of EEPROM use. I got almost no responses or interest for it.

1 Like

His repo does not include my games, yet. :thinking: Also, it might be a good idea to just scam through this forum for other games which may not have been added.

Yes of course i searched for other games as well. Yours are also there. I am also not finished on adding and still searching. :wink:

They are too good to be left out :slight_smile:

Going to make a post about the “Goldcart” soon, @mameise has a github repo of it, so adding your game should be as simple as doing a pull request, it also will allow you to change the .png image that will show in the FX bootloader.

Standby…

2 Likes

Good Idea. I was already thinking about how to publish it as I doubt a single post here can contain all the data.

Too bad it didn’t work out back then. Would have saved a lot of time. But I’m gonna make the list.

From the list of 80-ish programs that use EEPROM I’ve checked 13 sofar and there are several collisions of which 3 overwrite Arduboy2 system settings and bootloader menu setting(I’m gonna claim the last EEPROM location for bootloader menu now :slight_smile: )

Don’t worry mine aren’t either. but they’re on our working list :wink:

for those of you who made programs using EEPROM it will be appreciated if you could post your EEPROM usage on this thread.

1 Like

@Mr.Blinky Let me know what you’ve got I’ll host the google spreadsheet.

I strongly suggest you use the first location, EEPROM address 0, for this, as we’ve been discussing. People are already aware (or should be or will be) that the first 16 bytes of EEPROM are for system use and off limits for sketches. I’ve already made changes for the next release of the Arduboy2 library giving you full control of address 0 (and it’s not being used now anyway).

I can think of two reasons for not using the last EEPROM address.

  1. It hasn’t been off limits for Arduboy sketches in the past so some may be using it legitimately. You won’t be able to check/modify all the sketches out there. You won’t even be aware of many. As I indicated above, no Arduboy sketch has “legally” been able to use address 0 since the first 16 bytes were reserved by the original Arduboy library in a commit on May 29, 2015, which is before the first Kickstarter shipments in February 2016.

  2. Using the last address could make things a bit difficult for porting to a new architecture with more EEPROM. Your last address might end up in the middle of the new EEPROM space. The first address is always going to be the first address, so porting would likely be less painful.

Edit: 3. You would have to document the fact that the last address is now off limits in a way that the word gets out. Address 0 is already documented as reserved in both the Arduboy and Aruduboy2 libraries.

1 Like

I think this is how you strongly suggest something, by the way.

and after you opposed to using one of the unused system flag bits. I modified the bootloader in homemade package 1.2.8 accordingly. However seeing several games corrupting the first locations I’m concidering moving the location to the end to reduce the risk of corrupting the boot menu flag. It would be annoying when suddenly the menu doesn’t show up after switching power on when it should or appear when it’s been disabled by the user.

I’'m still working on making the EEPROM usage list. When that’s complete I’ll get a better picture of what to do. If it remains with just a few games I’ll relocate their EEPROM addresses and I’ll stick with location 0 and revoke my claim. If the isue can’t be solved that easily and I can’t find another solution then I’ll probably use the last EEPROM location.

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