I can’t say this for certain (because in this instance I can’t speak for anyone but myself) but I think that the reason nobody can agree is because everyone’s needs, or imagined needs, are different. The reason I said it is apparent is because it reminds me of my first experience I had in drafting a design document for a game with others. We were working on a survival game that takes place in a space ship. You hear an explosion. Immediately your communications are shut down, so you are unaware that you are being boarded as you try to get around the ship and make repairs. As we were talking about the game, we agreed on high level mechanics. We all had a general idea of the game we wanted to make, yet none of us realized at the time we were talking about completely different things! I was talking about making a Metroid style game, another person was talking as if it was a top-down shooter. To me, this discussion parallels that. Here, we are talking about highly optimized implementations, yet the applications are going to be different for everybody!
I can’t even pick a single proposed format that works for all the projects that I’m working on! For example, some games will work fine with using small blocks because they store a simple high score table or auto save (like glove and Arduboy gamepad). Other programs like my on-Arduboy game editor will need almost all of the memory for its images, “constraint classes,” and levels. My other program, the Arduboy virtual machine for learning about assembly language, needs only 256 byte blocks for each program. Then I have my prototype Metroid Fusion/Amnesia game, which “installs” the levels to EEPROM and modifies them as you play.
So basically, even if an on-Arduboy management system of EEPROM was picked, it would not be able to satisfy the applications of all developers for the unit. A way to make EEPROM management universally supported would be to handle it on the computer’s end. Developers could simply specify what ranges they needed. They would not have to worry about overwriting other applications’ memory, and they would be able to reserve all the space they need, without worrying about an Arduboy with full memory.
Here’s another argument against on-Arduboy management: compiled code size.
What happens when there’s not enough free space? First, the game needs to have code that checks for free space, however the EEPROM standard is organized. Well, OK, there isn’t enough space. Will the Arduboy just delete the oldest file? Hopefully not, I don’t want my RPG (as an example of a highly valued save file) progress to be deleted and replaced by a win/loss record from just testing out a little tic-tac-toe game (as an example of a not-so-valued save file) just once. So to avoid this, probably some save manager screen needs to appear. That’s more code compiled in. Also a print library of sorts needs to be bundled. And applications need readable names, so that’s more EEPROM used.
The overhead in programming in EEPROM management in the device is much higher than simple dump and restore routines through the serial port.
Out of curiosity, can you tell me about the mentioned (Harvard architecture?) game systems that share small amounts of data in a non-removable memory location?