Originally I was going to wait until tomorrow to try to fix this,
but I decided to have a quick shot at it and this is the result:
I decided to do a bit of drastic redecorating, but the code is now both simpler and smaller,
in terms of both source code and progmem.
eeprom_update_block as special kinds of eeprom-to-ram and ram-to-eeprom
memcpy_P found in
<avr/pgmspace.h> ought to have been called
It would be a single entity to worry about saving (i.e. a simple
EEEPROM.put) rather than having multiple arrays to save.
The only downside is that it forces you to save the entire state at once,
but that’s not a particularly big downside unless you really need to save only part of the state.
The use of ‘update’ will avoid unnecessary wear on the chip.
The system I invented for Minesweeper has both backwards and forwards compatibility as well as better protection from corruption than a simple 2-byte id.
(If I were to write a program that saved data at
EEPROM_STORAGE_SPACE_START + 375 at the moment then it would mess with your game’s save data and you’d never know a thing about it.)
However it’s a lot more complicated and still has one thing I need to fix.
(The variable length array allocated on the stack is non-standard behaviour, I ought to swap it for a
I could adapt my Minesweeper system if you’re interested,
but frankly it’s probably a bit overkill for your needs.