Shared EEPROM storage management across multiple apps

I guess so.

I don’t know if eeprom backup is a feature of any of the game loaders, but it should be. The only thing out of all of the above ideas, that really should be suggested is that the game uniquely identifies itself, either by some sort of code, or just a plain filename, so that any backup method would know what to name the save file, and that to load.

Arduboy Manager does! So long as you use the Arduboy Assistant along with it! :smiley:

indeed it does, however i cant get the arduboy manager to work with anything besides the screen mirror :stuck_out_tongue:

Was there any decision made as to the standard? Or at least a location to figure out where various Arduboy applications store their EEPROM data as to not overwrite it?

Also, sorry for awakening the dead.

Nope, nothing.

There’s a few best practices though.
Mainly don’t stick your data right at the start of EEPROM because too many games do that already and it wears the lower block out quicker.

Also make it configurable by changing a value in the source code so people can move it if they want.
I’d recommend using a const (and ideally constexpr) variable for that, but most people just use #defines (much to my sorrow).

I think it’s too late in the game to create a standard API that sketches would use, especially considering the number of sketches out there that do their own thing and would have to be modified.

I was thinking of creating a wiki in this forum that anyone could add to or modify, to list the EEPROM area that each sketch uses. The format would be kept simple, containing:

  • The name of the game. If different versions of the same game were released that used different areas (start or size), a separate listing would be made for each version.

  • A URL for the location of the source code, if available.

  • The start and end addresses of the EEPROM space used, the same as what would be provided in the info.json file of a .arduboy file. The entries would be kept sorted in order of start address, and secondly size (largest areas first) for ones that start at the same address. Sorting this way would make it easier to find if an area had been used, and help to locate an unused or little used area.

  • If possible, notes on how to modify the source code to change the area used.

I haven’t created the wiki yet because I wanted to provide a few entries, to get things started and as examples of the format. However, I haven’t found the time to research the information to create these entries.

If anyone wishes to get the ball rolling by providing the information for their game or someone else’s, as a reply in this topic, I’ll create the wiki once the info for a few entries is available.

If this idea proves to be useful, there’s the possibility that the wiki could be moved to somewhere on the main Arduboy web site, where it would be easier to find.

@MLXXXp The wiki part would be helpful, as of the last hour I’ve been playing with the idea of trying to go through and list the EEPROM addresses the popular programs use, although that would be a LOT of work for one person especially if it was a personal project as opposed to a public wiki where developers could openly add the info.

I’ll try to refine what data I already have and post it as I didn’t note some aspects that would need to be displayed, hopefully that will get the ball rolling like you say.

Out of curiosity are you going to use MediaWiki?

1 Like

No. This forum has the ability to make a Topic a wiki. That’s what I was planning to do.

If people have been putting the correct addresses in the info.json in their .arduboy files then it should be possible to make a web crawler to walk through all the games on and scan the info in (it would need to be able to unzip the .arduboy files and parse the json).
That would serve as a good initial pass.

It might also be possible to programmatically scan the source code of sketeches to look for EEPROM writes and try to extract the addresses that way, though it would only manage a handful without more complicated logic. At minimum it would need to be able to identify variable/define names used in the EEPROM writes to figure out the base address.

Unfortunately, there are no .arduboy files there, only .hex.

This is on my heap of future projects, in the form of a headless variant of ProjectABE.

For now there’s this: if you open your browser’s devtools and type EEPROM in the console, you’ll get a sparse array with whatever the currently running game has written to it so far.

As an example, here’s what I get if I simply start 1943 and toggle the sound:

[empty × 2, 0, empty × 197, 52, 51, 0, 0, 0, 0, 0, 0, 0, 0]

Which means the game writes to addresses:

0x2, 0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd1

The former can be converted into the latter like this:

Object.keys(EEPROM).map( k => "0x" + parseInt(k).toString(16) ).join(", ")

If it’s of use, I can easily make ProjectABE output something with some other format.

1943 writes from byte 200 onwards - the first byte is the sound on / off.

Hrm, I misremembered that.
That makes things a lot harder.

If you have the means of being able to identify a program that’s loaded to the emulator then you might be able to make all the instances “phone home” and store what they send back in a database, that way you could leverage the power of people playing games to log EEPROM writes on a larger scale (like recaptcha does for books).

If you further limited it to unmodified .hexes acquired from @eried’s repo then you could eliminate some of the ‘noise’ and just focus on the ‘published’ games.

Just a thought.

That would be good. The only problem is that there’s currently no home to phone to. The service I use as a compiler back-end can’t store data.

That’s unfortunate. I wonder if @eried’s server could?

If not, maybe something could be arranged with @bateske - rent a database server for a month and start a community-wide “help us figure out the EEPROM addresses” thing.

(Admittedly you could gather a bunch of people and ask them to sit and read the source code of all the games, but telling people “all you have to do is play video games in a browser” is probably a better motivator.)

1 Like

My server is quite crappy ($24 USD a year/ shared thing) but it is available for anything.

Something simple like could work.

1 Like

Wouldn’t it be better to get a list of addresses, so there’s less requests?
It’d also be better if addrs went via POST, since games that write to the entire EEPROM would send a really long URL and some browsers won’t like that.

1 Like

Sure, I was typing a dumb example. eepromstats.php does not exist :stuck_out_tongue:

1 Like

I know, it’s just that the example had more stuff in it and I was wondering if it was like that for a reason. It looked like you were thinking of making an EEPROM backup service, since the actual values are there too.

Not really, but it would be nice to integrate everything even with the arduboy hardware. Imagine getting savegames from other users haha xD

But it could be really simple for the first version, just to collect the accessed addresses. Even using ranges for longer blocks ?addr=c8,ca-d0,d2.

1 Like

If done well, this can enable multiplayer games. Imagine, for example a 2 player version of “Hello, Commander”. Player A does a series of moves, saves, and that save gets synced to player B.
We’re going to need authentication though.

For the first version, addr=c8,ca-d0,d2 looks good.