1nvader [V1.0]

Ahhhh … what mess I have made!

No worries my friend… Thats why the community is for, for everyone to pitch in and help each other.

The cookie system is for managing the EEPROM - if you are using the SD card to store game state then you manage your own file. There is no risk of conflicts between different games unless someone uses the same file name.

That is my complaint about the Pokitto overall.

It could have been done differently but the initialisation routine allocates enough EEPROM to accommodate the cookie - this might be a single or multiple blocks. Allowing the user to arbitrarily save things could lead to issues with exceeding the size.

1 Like

Which is precisely why, unless there’s a particular speed or size issue or a need for random access, I think using EEPROM when there’s a file system available would be an odd design choice.

Too true.

I’m not saying users should be allowed to save wherever they want, I’m saying they should be allowed to save whatever they want without figuring out how to stuff it into a class. To reserve N bytes and then do with those bytes whatever they choose.

For example:

// The returned object would be a struct specifying
// whether the operation was successful and
// exactly how many bytes were allocated
auto allocation = system.reserve(gameIdentifier, amountOfBytes);

	// Handle error

auto writeStatus = system.write(offset, anyValidObject);

	// Handle error

// If the code has reached here,
// object was written successfully

Thus you could do things like writing an array of bytes without needing to stuff the array into a class/struct first, and writing a variable amount of data (e.g. writing just the high score entry that has changed) instead of writing (or attempting to write) an entire fixed size chunk (i.e. the entire inheriting class) every time.

My point was you can do either … its up to you, If you use EEPROM, you can use the cookie library. If you use SD, its up to you. Your choice.

Any valid object of any size?

Agreed this would work too. However the cookie system say you don’t need to calculate offsets and so forth. It probably works well for most games where you have (maybe) five high scores, five names and that’s about it. Just write the cookie and ignore the implementation below it - the abstraction works nicely for most people.

Anyhow, I know you don’t like the cookie library. I think its quite effective but I have used the SD card for writing files too when needed. Not that they have anything to do with 1nvader.

Providing it fits within the reserved block, otherwise you get an error.

No need to with this arrangement either. If you want to write everything as a single dumb struct, that’s fine too.

system.write(0, plainOldStruct)

There could even be an overload that omits the offset for convenience.


No, but people started talking about EEPROM.
I was going to split the thread, but it’s hard to identify a splitting point that would actually make sense.

Nah leave it … what’s a bit of debate amongst old friends?

1 Like

OK … I think I sorted it out @angelbolanose!


That’s what I ment with four 0 to 1 bit changes. Didn’t want to go into techy details.

I guess it was just a case of replacing the XL version with the Arduboy version? :wink:

I wish … the code I put in to test the EEPROM was dodgy.


Thank you my friend. As always it worked perfectly. Appreciate :slight_smile:

Any way to reprogram an Arduboy once this has been flashed to it?