Can we just reserve a section of the flash chip to retain the EEPROM contents for each game? When flashing a new game it could first save out the existing EEPROM data to a slot for the existing game, and then flash the new game and load the EEPROM data from the new gameâs slot. I think this is what the Gamebuino did (except with SD card instead of a flash chip). You would just need a mechanism to tell which game is currently loaded first (could be an id in a reserved section of EEPROM)
This way the games can use (almost) all the EEPROM storage without any issues as it is essentially sandboxed for each game.
Yes. This seems the simplest way ⊠Even if the EEPROMs are aligned, optimised,etc there will still be clashes and some games use a lot of EEPROM so will never play nice. It is important to make sure that the games do not overwrite the reserved areas of course.
Iâm happy to support whatever developments occur but officially Iâve not put EEPROM management on the goals list for the production version of the software.
A lot of people come up with ideas like âall we would have to do is⊠[insert massive amount of work project]â and then nobody ever actually does it.
Iâm not going to ask @Mr.Blinky to do any more work right now to the bootloader or cart system. He has already done more than we could ever hope and dream.
I have been experimenting with bountysource for another project and it seems like a nice way to get things done. It just links to github so there is nothing to do really: https://www.bountysource.com/teams/portapack-mayhem the moment the issues are closed the money is released to people who solved them.
Also is a good way to catch the features that people actually want (even with 5 USD) vs just noise of complainers/cheapos
The idea is that each game can have a EEPROM save block added. This is determined in the CSV file.
The flash builder (script) will patch a hexfile on the fly with a magic key and the (page) address of the 4K aligned flash block (4K is smallest erasable block). The magic key and page address are stored at unused space in a program: a reserved interrupt vector.
This page address will be used by the bootloader to determine if the current loaded program needs EEPROM backup prior to flashing a new program (upload over USB or menu selection). If it does then EEPROM is backed up to the FX EEPROM block.
If a program was flashed from the menu a check is made to see it has an FX EEPROM block. If so the FX EEPROM block is copied to EEPROM.
Sofar this is still in the idea phase only cause other projects have a higher priority.
Sorry @bateske didnât work, these were the words to let the magic @Mr.Blinky out of his lamp.
So you put him back in
Iâm beginning to wonder is @Mr.Blinky a real person or a piece of code roaming these forums who begins to compute whenever a problem is presented.
Mr. Brainy Logic Instruction Network Koding Yenie.
I cannot think of any other EEPROM hogs besides Circuit Dude and Micro City. What if Howard and I work together to hold data in the FX chip for a special Circuit Dude FX and Micro City FX version? That should mostly solve the prob, right?
Its more than that though ⊠games would need to be changed to prevent collisions. IMO, we need to either warn the Arduboy owner that this will happen or fix it completely.
Yes, sorry/ Your post sounded to me like fixing Circuit Dude and Micro City would âmostly solve the probâ. My point really is that with so many games competing for the EEPROM space there will be collisions and the result might be unsatisfactory.
A few games look for some known bytes at the start of their data to determine if the saved data is valid - mine do this - but its a half solution as some other game could have written over the tail. Other games, like @Pharapâs, use a checksum or similar to ensure the integrity of their saved data,
The worst example might be that a game starts but fails miserably because its expecting something in the EEPROM but that is corrupted.
Would it not be easier to create a ini file on the flash memory chip wich holds the games settings/scores?
Say next to the bin file containing the games, i know the Arduino can write to that fairly easy, or does this mean al games have to be rewritten?
Iâm a total noob when it comes to game coding so forgive me if this a stupid remark.
Edit, Oops saw in the first post that this was (sort of) the idea, got on the wrong foot with all the eeprom talk. SorryâŠ
Edit again, a standardized save game setting (mmm say a ini) was not mentioned yet.
So my comment still holds, if valid that isâŠ
The FX chip doesnât actually contain any files. Itâs all a bunch of data stored in there. The BIN is the only data being put onto the chip. Once a game loads, it determines whatever it wants to do, including where it saves data. The chip cannot interfere with the game deciding where to store its data.
Yeah, you have to allocate available space to the game at the time you build the .bin. The CSV stores a start and length information about the âexternalâ memory available to the game, and patches that back to the games .hex file
So, no dynamic memory management, itâs all fixed. Although, you can read and write from that fixed space however you want.
USB sticks and SD cards are just blocks of flash memory managed by a small processor that handles the communication protocol and provide wear levelling.
All files are just sequences of bytes and the medium on which theyâre stored is mostly irrelevant, what makes them âa fileâ is being stored as part of a file system.
In theory we could have a file system, though certain quirks of how flash works would make it difficult to design one thatâs practical and not wasteful.
While theoretically you could structure the data a game uses as an .ini file, plaintext formats would be a somewhat wasteful way to do it, not just because of the unnecessary characters, but because of the complexity of the software needed to read them.
When I say âcomplexityâ, I donât mean that reading an .ini file is a complex task in itself, I mean that itâs sufficiently complex that it would probably chew up a large chunk of progmem.
Having the FX chip allows people to offload large amounts of data, text and graphics onto the FX chip, but program code must still be kept actually on the Arduboyâs processor, in the on board flash memory (âprogmemâ).
Using something like UBJSON or Minecraftâs NBT format would be an improvement, but those would still have the issue of being reliant on strings for naming data.
Ideally youâd want to just use plain integers to identify the type of data, or to make the type of data implicit in how the structure is formed, as you would if it were being stored on progmem.
In the interest of being open and informative,
can we call it something more descriptive than âmagic keyâ?
âMagic keyâ says absolutely nothing about what it does.
E.g. Is it a unique game identifier?
Mmm hope i interpreted this remark correctly butâŠ
The FX chip seems to be the next level for the arduboy.
Switching between games who keep scores or levels in eeprom is somewhat of a spoilsport .
The arduinoâs eeprom is not that big, so game data canât be that much.
Is it possible that when the game bin file is created thereâs some way to reserve a portion of the flash (in respect to the number of games) wich can hold game data.
I realise there has to be some kind of index off where a game can put itâs data (so not overwriting other games data).
So technically the game does what itâs supposed to do, only when the FX chip is present it saves data on flash instead of eeprom (in the same small manner).
Like i said, noob here and must agree with Bateske that some thing are easier said than done or as he put itâŠ
I have been experimenting with bountysource for another project and it seems like a nice way to get things done. It just links to github so there is nothing to do really: 
.