Yep, definitely possible. I think that is what the leading idea is we have had for a few games.
Actually it does. It contains a linked list of files. Each file has a
- 256 byte header
- a 1K splash screen in raw binary format
- optional hex file in raw binary format
- optional game data in raw binary format
- optional save data in raw binary format (4K aligned)
- optional eeprom save slot (4K aligned)
All files are static meaning you can’t change / add / remove any parts.
It is stored in the programs code and is already unique as you can only have one program loaded into the Atmega.
The library checks if there a RETI instruction at the reserved vector address(normally there is a JUMP instruction). If there is then the library fetches the page address stored at the vector address + 2
It contains files (including filenames and meta data)? Or it contains the data from the files? I think it is the latter, right?
The header can contain those those but are not relevant for the loading by the bootloader. (more interesting for a file manager)
you could look at the header as a directory entry.
I was doing fine until the second paragraph…
So the ‘magic key’ is the RETI instruction?
Or is it the page address stored in the vector address following the RETI instruction?
Just to check that my assumptions are right (and perhaps this may help other people):
The 256 byte data contains…
- Some offsets indicating the relative position of the 4 optional sections if present
- A flag to indicate whether the game needs its EEPROM backed up when it’s unloaded/overwritten
- Apparently a file/game name?
- Presumably other stuff that I can’t currently fathom
- The splash screen is a 128x64 image to be displayed by the bootloader
- The ‘hex file in raw binary format’ is the actual progmem image to be loaded onto the Arduboy
- The game data is a pool of general purpose data for the game to read as it pleases
- The save data is a block of flash allocated to the game for use as an extended/larger save area, as an alternative to EEPROM
- The eeprom save section stores (at least) one copy of EEPROM, as recorded by the last time the bootloader unloaded that particular game
Hence a normal Arduboy game would not include the game data and save data sections, only the header, the splash screen, the progmem data and (optionally) the eeprom section.
Have I even hit the target or did I shoot a pedestrian by mistake?
Well you asked for it
Technical: The space for a vector is 4 bytes so a (long) JMP instruction could be used to jump to code beyond the (relative RJMP) 2K limit.
A RETI instruction takes 2 bytes so there are 2 spare bytes which I use to store the page address at.
More detailed info can be found in the 1st flash cart post
Correct. the games virtual read only memory
Correct however it doesn’t work as convenient as EEPROM Still need to figure a convenient system out.
Stores only the EEPROM part that is used. The flash image determines the default contents. When the current program is about to be overwritten with a new program the bootloader copies the used EEPROM area to this space.
Correct only FX games may have game and/or save data. A normal Arduboy game may use an EEPROM save. Note that that this EEPROM save feature is not yet implemented. This is a future feature.
Ok, that all makes sense. Just one problem remains:
Presumably that was supposed to be a URL and not just a sequence of hexadecimal digits?
In other news: I am a simple man, I enjoy being told I’m correct.
I think the main limitation of using the flash storage for save games is the limitation with the chip that when erasing you have to erase a whole 4K page at once. This means that even when making a small modification to the save game, the entire contents of the save game need to be stored in RAM so that the flash space can be erased and re-written with any updates. This is probably ok for most games that just track a high score but might be tricky for more complex games. The alternative solution is to reserve two pages and copy from one page to another with the necessary modifications made, but this complicates things a lot!
None of this would be a problem for MicroCity as ~1K of RAM is used for the city state / game state which is currently just copied to / from EEPROM when saving / loading. If I wanted to add additional save slots then there would need to be a 4K page for each slot (even though only about a quarter of each page would be used so somewhat wasteful)
@Mr.Blinky Are there any technical reasons why the backing up EEPROM to flash is a problem (e.g. limited program space) or is it just a case of not having the time to implement yet?
Yes savedata requires at least 4K extra space. As a conveniece rule the save data should be twice the size (rounded up to 4K) that is actually used. I’d like to implement
some form of EEPROM emulation so it will be easier to write to save data.
It’s not really a problem. There’s currently 1K free space in the bootloader and I think I’d need half of that or less. It’s just not having/making the time for it yet as I’m Working on other FX related stuff that has a higher priority for the Launch and then people start having gamejams too
What about just making it’s own simple app an EEPROM manager that has a bunch of chunks allocated to it within the CSV file. And then you can save little memory carts, like save states.
I know this is a bandaid solution but it would work.