[Discuss] Arduboy Saved EEPROM Format (.ase) Guide

Until we have such a guide, we can start with discussing what this should be. The file should hold the follow things ?

  • EEPROM Addresses
  • EEPROM Stroge
  • game title
  • game version
  • author
  • ?

What exactly is being discussed here? A new file? Where is this file to be located? Does it contain data for one game or multiple games?

Does it involve the actual layout of the EEPROM storage used by a game? If so, I wish you luck but I fear that getting consensus on an EEPROM storage standard, and then having that standard be used by a majority of sketches, it going to be a difficult battle. For reference, here’s a link to the main previous discussion on this:

I know, BUT if every game with an .arduboy file using EEPROM used the fields to fill out start and ending address, you would be able to store those numbers in a file: a saved game file. if you use the file to put back your saved game, it would do so in the correct location.

Besides I’m willing to set a standard, don’t like, don’t use it, but we will not be able to backup your saved game data.
standard = set a start EEPROM and an end EEPROM address, provide it with the .arduboy file.

(Self regulating save to EEPROM has never been a good idea).

@JO3RI, Thanks for the clarification. So isn’t there enough information in an info.json file to accomplish this without needing a new .ase file?

You just provide your EEPROM load/save utility with all the .arduboy files for the games you wish to handle. Why store redundant information, already available in info.json, in a new file?

Well, you might want to SAVE the file to a “disk”, so you will have to create an game.ase file … So what needs to be in that file ?

A “disk” on a computer, or a “disk” on the Arduboy itself? If it’s on a computer, for the benefit of an EEPROM save/restore utility, then just let that utility store the information in whatever format and filename it wishes, after having extracted it itself from .arduboy files.

Yes, BUT if we agree to do it all in the same way, we can exchange the SAVED files between loaders.

OK, thanks, I get it now. This is so a particular user’s scores, etc. in EEPROM, for a particular game, can be downloaded and saved by an EEPROM management program, and then that data can be uploaded back into a (possibly different) Arduboy by a different EEPROM manager.

I assume then, that a .ase file would hold saved EEPROM info only for a single instance of a single game. Correct?

Indeed, exactly as you say!

Then I suggest that, in addition to all the information proposed in the original post, we also include:

  • Save date and time
  • User name. (The person who played the game.)
  • A “notes” field that can contain anything the user wishes to add.
1 Like

If considered to be off-topic, a new topic can be created for further discussion of this:

In addition to the format of a .ase file, maybe we should also discuss a standard protocol for save/restore of EEPROM data between an Arduboy and a PC over USB.

Having a standard protocol means that it could be included in a game itself (space permitting), so that a separate sketch wouldn’t have to be loaded to save/restore EEPROM for that game. Functions for this could be added to the Arduboy2 library, to make it easy for games to include this functionality, or for manager sketches to use. A manager sketch could be included as a library example.

The protocol doesn’t have to be overly complicated:

  • A specific standardised baud rate is used.
  • The Arduboy is the slave. It listens for a save or restore command from the PC master.
  • If no response is received within a specified time, the PC should retry until a retry count expires.

To save data from the Arduboy:

  • The PC sends a save command with a suggested start address and length.
  • The Arduboy replies with a start address, length, and data. The Arduboy can override the suggested address and/or length if it knows they are wrong. This reply probably should also contain a flag indicating that the location used by this game is variable (e.g. It searches for an unused area or allows the user to select a slot).
  • The PC can use the returned information, along with data from a .arduboy file and/or user input, to create a .ase file.

To restore data to the Arduboy:

  • The PC sends a restore command containing the start address, length and data.
  • The Arduboy replies with a message indicating:
  • Success. The data was written to the EEPROM area specified.
  • Wrong address. The actual start address used by the game is included. The PC could try again with the included address, possibly after prompting the user for confirmation.
  • Invalid length. The length didn’t match the size of the save area used by the game.
  • Invalid data. The data didn’t contain the proper “magic number” or other pattern required to be valid (as determined by the game itself).

For a separate “EEPROM management” sketch, the start address, length and data specified by the PC would be blindly accepted. If the game itself is handling the save/restore, it has the option of using the more intelligent replies.

For my two cents worth.

I really think we should just partition the EEPROM into say, 8 blocks of ‘save area’ and have a header area that has a single byte indicating if a save area is ‘full’ or ‘empty’.

Each game then can check a single byte to find if there is a save slot available. If there is not, it is up to that game to play nice and inform the user or blast someone elses save slot.

Each slot can have a couple bytes at the start used to store some sort of id, eg, enough for say, 12 ASCII characters. the rest is for you to use for storage.

The benefit of this is we can have a single sketch that can be used to manage saved games (eg, present them as a list, back them up, delete them, etc). This sketch is analogous to the ‘explorer’ or ‘finder’ on Windows/Mac etc.

The second benefit of this is the power of constraints. If you cannot fit your save game in a save slot, you either need to redesign it, or split your save file over two slots and deal with that.

From reading the other discussion, there seemed to be a lot of talk about trying to give each game exactly what they require, and then manage that. I believe it makes more sense to treat the EEPROM as a file system with 8 blocks of a certain size, instead of a contiguous block where you try to fit yourself in.

Of course, I am not an Arduino heavyweight, and I have not programmed games before where this has been a problem. I am just approaching this from the POV of things like the early memory cards on things like the PS1, where you could very quickly fill it up with save files and would have to clear some out if you wanted to save your game.

Also, this method avoids any annoying issues with fragmentation, overwriting, etc.

Why do we need anything other than the raw binary data? How would we even retrieve the titles for the savedata? What would we even do with it?

If you have a save EEPROM fucntion in your Game Loader, you will have the game in that loader too. The game holds the correct addresses used in the EEPROM and so you can backup game title, addresses and the actual data. Hence the reason why we have EEPROM info in the .arduboy file.

If you’re able to backup EEPROM, you don’t even have to manage EEPROM at all.
In a loader one could just pick a game and choose “backup saved data” or “restore saved data”


Please take this kind of discussion here:

1 Like

So that we can correlate the data with a particular game, user, etc., which could be displayed to the user to help with selecting what they are restoring. This way multiple datasets for the same game could be saved.

I could play Circuit Dude for a while and achieve level 25. I could back up my EEPROM for this game with a user field set to MLXXXp. I could then reset the game and let my friend Crait play without being able to “cheat” using the levels I’ve accieved. Crait could then save the EEPROM for his achievement under his name. I could then restore mine to continue at my achieved level. Etc… Etc…

Data for both MLXXXp and Crait could be saved, and selected for restore, in the same EEPROM manager. And, if the data were saved, or could be exported, in a standard format (a .ase file), restoration could be done by a different PC running a different O/S or even a different EEPROM management program.

Note that if a particular game itself doesn’t have the capability to transmit and receive EEPROM data, a separate EEPROM manager sketch would have to be loaded as an intermediate step, between games, to facilitate EEPROM data exchange. (See my earlier post)