Shared EEPROM storage management across multiple apps

Wouldn’t it be better to get a list of addresses, so there’s less requests?
It’d also be better if addrs went via POST, since games that write to the entire EEPROM would send a really long URL and some browsers won’t like that.

1 Like

Sure, I was typing a dumb example. eepromstats.php does not exist :stuck_out_tongue:

1 Like

I know, it’s just that the example had more stuff in it and I was wondering if it was like that for a reason. It looked like you were thinking of making an EEPROM backup service, since the actual values are there too.

Not really, but it would be nice to integrate everything even with the arduboy hardware. Imagine getting savegames from other users haha xD

But it could be really simple for the first version, just to collect the accessed addresses. Even using ranges for longer blocks ?addr=c8,ca-d0,d2.

1 Like

If done well, this can enable multiplayer games. Imagine, for example a 2 player version of “Hello, Commander”. Player A does a series of moves, saves, and that save gets synced to player B.
We’re going to need authentication though.

For the first version, addr=c8,ca-d0,d2 looks good.

They serve separate purposes. Arduboy is the WHOLE shebang… a ton of stuff you might not need if you want to do something realy low-level or creative, do your own screen buffering, etc… core.h gives you JUST what you need to boot the raw hardware itself, turn the screen on… ie, the minimum to make the hardware itself work.

1 year, 6 months and 26 days.
I’ll say no more.

1 Like

What if a system like the Uzebox was used?

32 bytes blocks of which the first 2 bytes are an ID code.
Some games require multiple IDs so maybe a 3-bytes code:
2 bytes reserved game ID

  • 1 byte game’s sub ID or free to use if only 1 block needed

EEPROM/Flash manager would scan and keep all the blocks with the same gameID (and a different sub ID) when swapping out blocks.

make 0xFFFF code a free block
make 0x0000 code a deleted block so overwriting backed up eeprom blocks with ~(gameID) marks the block as obsolete without having to erase an entire flash block every time. It’ll clear the bits that weren’t cleared on the flash (as long as each bit is written to zero only once between erases it should be fine but needs to be confirmed.)

Once a flash block is filled with data (or deleted-blocks) round-robin to the next flash block reserved for eeprom swapping.

needs to always keep 1 flash erase block available to collate.

@Mr.Blinky Just thought of something a bit ugly but would have nearly zero cost…

Those reserved interrupt vectors are a waste of PGM space, we could pack EEPROM needed size + offset variables in there.
I don’t think anyone has used those few bytes for anything so far.


Can you read minds? :smiley:

I was planning to store a signature + address offset in another reserved vector (like I already do for FX gamedata and FX save data). The EEPROM addressd and size would be stored in the 4K eeprom backup flash block.

1 Like

*Reserved for Arduboy

.section	.text.__vector_5,"ax",@progbits
.global	__vector_5
	.type	__vector_5, @function
	.string "Potatoes"

We can use it to store some metadata too right in the ROM (tho it will cost a bit of space if we do that) and point to it. Which if we’re careful can still be expanded later.

I got about 396 bytes left in the Turbo version :stuck_out_tongue:

1 Like


vectors at word address 0x000A, 0x000C (and now 0x0010) are reserved by Arduboy FX :wink:

1 Like

Let me know once we have a finalized format so I can implement it in the ArduManFX tool. Eventually I aim to translate the cpp/python parts into something simple like javascript (which Qt already has built-in functions for) so that the way it processes games can be altered without requiring a complete recompile. This will in turn make it easier to update them since it can auto-update more easily.

If there’s an easy way to scan the hex to determine the EEPROM space used I can incorporate that into a GUI so as you add games to a custom flash cart you can see a graphical representation of the EEPROM usage for each game. If a game supports changing the EEPROM area used then I can incorporate that into the GUI as well so users can easily change where the game’s will save their data.


Is JavaScript the only scripting language Qt has support for?

Not necessarily. Qt has built in javascript capabilities because it uses it for QML (a way of writing quick and basic apps using UI files with javascript). However, being c++ I can use any scripts that cpp supports, but javascript is the easiest to implement since Qt has built in support for it so there’s no extra libraries needed. The benefit to Qt’s javascript part is it already has the ability to translate between Qt types (such as QString or QByteArray) into javascript types.

Qt has python bindings but these are for writing Qt apps in python not extending Qt apps using python. The problem with using python is there isn’t any easy way to distribute a single program that doesn’t require the user to then install python and any necessary libs. With pure c++ I can build binary packages for Windows, Linux, and Mac that require no installation.

Unfortunately there isn’t. my method relies on data included in the csv file.

That’s one of the big reasons I tend to avoid Python scripts if I can help it.

I prefer Lua - it can happily live on a USB stick with libraries and it doesn’t need a package manager, you just dump libraries either next to the lua executable or in a subfolder of the executable’s path named lua.

It’s also embeddable, has a REPL, and it’s really tiny - a bare-bones Windows version is just under 800KB and half of that is the manual.

The main reason I asked was because I think JavaScript is a pretty terrible language (implicit casts everywhere and they had to introduce let because of how terrible var was),
but obviously if that’s the only thing Qt has access to by default then using another language would be a lot of effort to go to.

Is there no obvious “write to EEPROM” instruction sequence?

Yes there are and they’re pretty easy to track down. I used this initially until I realized I got too many false positives because of the EPROM usage in Arduboy2 library :smiley:
The problem is you can’t easily find out (reliably) what the EEPROM start and size/end are.

The games can be rebuilt with the EEPROM code edited to read a 16bits offset from PGM before accessing EEPROM.

we just need a small struct in PGM ROM with the size (for the tool) and the offset (default), and have one of the reserved vectors point to it.

We can add a small header to it just so it can be extended with additional info later.

uint16_t offset = pgm_read_word_near(&game_info.eeprom_offset);
1 Like