This is the balance between a large block and small. Having ‘variable’ sized blocks introduces lots of complexity as you need to a way to navigate between blocks - either a BAT (that’s a block allocation table) at the start of the EEPROM or a pointer from one block to the next. The issue with the second approach is that EEPROM ‘blocks’ will not be contiguous so it would be impossible navigate.
If you get it right, the system could and should be used by all games. You could have a game look for the next available block and if none are found, start cycling through old games and (arbitarily) claim an old, used block. Maybe a low (one of the reserved ones?) EEPROM byte could store a pointer to the ‘oldest’ block.
Not really. If you encode the size of the block into the header of the block then you know how far to step until you reach the next one.
Sort of like having a one-way linked list.
That’s how some implementations of malloc work (or at least partly how they work).
This problem is actually quite similar to the one malloc has to solve,
so looking at malloc implementations is a reasonable approach.
That’s an option, though it does take space in itself.
(Reducable by allocating blocks as a multiple of a certain size, e.g. 8 bytes)
Blocks are only non-contiguous if you chose to allocate them that way.
Gaps from deleting can either be fixed by shuffling blocks or by having a flag to mark the block as unallocated (or both), so games that are looking for a block can sometimes take one that’s between two other blocks but has been deallocated.
To get it right I’d have to be attempting to solve it for all games from the start.
Minesweeper doesn’t need a complex block system.
Even if I came up with a system to solve the issue of multiple save blocks, it would probably wouldn’t be suitable as a universal system for managing save blocks because it would be founded on different assumptions.
Deleting a variable sized block and reusing the space with a smaller block will make them non-contiguous.
Anyhow, it was just an idea that has been floating around for a long time and contributed to by greater minds than I. Due to the various opinions, it would almost take someone to write something ‘definitive’ and let the objectors pick over it. If the solution addresses most cases, then people can adopt it. If a developer chooses not to go with the ‘recommended’ or preferred way, then they run the risk of alienating owners by not caring about their other games.