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 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.
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?
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?
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…