add support for user options

[makapuf]

user options in flash would be settable in 2nd bootloader
they will be stored in second page of flash
they can include:
keyboard type (1word)
a flag to check if data has been initialized (1word)
gamepad button mappings, default player name (1word)
maybe game specific data ? should reserve IDs in flash.

[pulkomandy]

For game specific data it woudl be possible to implement a "cookie jar" system. Some inspiration: http://toshyp.atari.org/en/003007.html

[makapuf]

well, I did implement a system like this, (lib/eeprom.c/h) but I never used it, too complex.

Couldn't we use a simpler system with a fixed array of u16 values in flash with identifiers set in a header in the main repo lib ?
example of a options.h file :

#define OPT_PACMAN_HISCORE 12
#define OPT_BITBOX_KEYBOARD 1 // useful values : 0xffff=EN, 0001 : FR, ..
#define OPT_PULKOTACKER_THEME 5 

directly reading flash_options[OPT_SYSTEM_KEYBOARD] and set_option(OPT_SYSTEM_KB, 2) to set those ?

Or maybe I'm missing a function of cookie jars ? (we're using a fixed size here anyways)

[pulkomandy]

In the cookie jar, you can allocate tags for a lot of applications, possibly more than you have bytes in the flash memory. The idea is that users will never run ALL the apps on a bitbox, so they will only have the cookies of applications they already used. And if they run out of space, user can identify each cookie and decide to keep or remove it.

However, maybe we don't have plans for that much apps on the bitbox?

[makapuf]

well, it was basically the eeprom thing (that+flash wear levelling). I
don't think it will be useful before long :) 4k with u16 data is 2048 slots
! if we use 4 per prog that's 512 games. I think we're set. If a program
needs to store some fat data, just use the SD card !

2015-07-17 14:29 GMT+02:00 Adrien Destugues notifications@github.com:

In the cookie jar, you can allocate tags for a lot of applications,
possibly more than you have bytes in the flash memory. The idea is that
users will never run ALL the apps on a bitbox, so they will only have the
cookies of applications they already used. And if they run out of space,
user can identify each cookie and decide to keep or remove it.

However, maybe we don't have plans for that much apps on the bitbox?

—
Reply to this email directly or view it on GitHub
#34 (comment).

[makapuf]

Well, I think I forgot something: we're not rewriting flash at will, we
need to erase flash before we write it.
So the eeprom.c were made from this need: if you need to rewrite a value,
you need to load the whole sector, erase it, modify it where you want in
RAM and then rewrite it with the new value - which not fast ! So a growing
list of key/value pairs are much faster if you rewrite the same value ten
times (and wears less the flash) - like in a game when you're beating
scores repeatedly, and you can compress it from time to time.

2015-07-17 14:39 GMT+02:00 mak apuf makapuf2@gmail.com:

well, it was basically the eeprom thing (that+flash wear levelling). I
don't think it will be useful before long :) 4k with u16 data is 2048 slots
! if we use 4 per prog that's 512 games. I think we're set. If a program
needs to store some fat data, just use the SD card !

2015-07-17 14:29 GMT+02:00 Adrien Destugues notifications@github.com:

In the cookie jar, you can allocate tags for a lot of applications,
possibly more than you have bytes in the flash memory. The idea is that
users will never run ALL the apps on a bitbox, so they will only have the
cookies of applications they already used. And if they run out of space,
user can identify each cookie and decide to keep or remove it.

However, maybe we don't have plans for that much apps on the bitbox?

—
Reply to this email directly or view it on GitHub
#34 (comment).