Linked how though?
Do the 7 bits of a crumb/block table entry indicate which key they correspond to?
crumbTable == 5 does that correspond to the crumb being owned by the key at
In your system, are blocks allocated contiguously or can a game have its blocks spread out?
In my system all the allocated blocks are contiguous and a game can claim more than 32 bytes.
So if a game claims 32 bytes (1 block), the header size means they only get 16 usable, but if they claim 64 bytes (2 blocks), they get 48 usable. If a game claimed 512 bytes (16 blocks), there would be the constant 16 bytes for the header and the remaining 496 bytes would be usable etc
Maybe this will make it clearer:
checksum (4 bytes)
id (4 bytes)
size (1 byte)
reserved (9 bytes)
data (((size * 32) - 16) bytes)
So to find a block by traversing the allocated blocks:
EeepromPointer findBlock(SaveId saveId)
EepromPointer pointer = pointerToFirstByte;
if(settings.saveId == saveId)
pointer += settings.size.getSizeInBytes();
Most likely an id of 0 would be used to indicate an unused block.
Hopefully we will have a system for backing up entries to SD card so you can treat the EEPROM as your active data and the SD card as your archived data.
Or manually to organise before loading a new game.
Essentially that kind of is what we’re doing.
These ideas are similar to how file systems usually work.
@jonne’s proposal is similar to the FAT family of file systems because it uses a table to track the block entries. Mine is closer to an algorithm that’s sometimes used to implement
malloc (it’s more of a bare bones linked list with offsets instead of pointers).
After looking at FAT, one other idea I had was to have a table that stores the game id, an index and a size, with index and size being multiples of the block size.
Then it could fit 64 entries in 512 bytes (or 42 for the extra 2 bytes in the name).
This would probably be a much easier system to perform reconfiguring operations on.