Arduboy Semi-Official EEPROM Table

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?