I think it’s increasingly important to simply convey if / what games may have an EEPROM collision.
It’s not intuitive (esp. for non-programmers) to understand what is meant by ‘EEPROM’ and then to look at ranges of hexadecimal addresses and understand if there will be a problem…
My suggestion is to agree a very straightforward labelling convention.
Rather than ‘EEPROM’, I think it’s easier to communicate: ‘Save slot(s)’, or simply ‘Saves’ (?).
Hexadecimal addresses should be communicated as ‘slots’, that are simply labelled
Z. This is worked out as follows:
- The first 16 bytes of EEPROM is system reserved.
- The remaining 1008 bytes is divided into 25 slots (
Y) of 32 bytes* each, and the final block (
Z) is 208 bytes (32 + remaining 176 bytes).
- We should report the first and last slot (inclusive) that is used by the program.
Note: * Analysis of existing games’ EEPROM usage showed the median is ~22 bytes per game. If we start to add Checksums, I think the 32 bytes blocks are reasonable. Not sure if this helps or hinders @Mr.Blinky’s plan for backing up EEPROM to the FX chip(?)… Concerns are whether authors use just the first few bytes of a given slot, accelerating wear of the EEPROM.
Game 1 ~
Game 2 ~
Game 3 ~
Game 4 ~
Game 5 ~
It’s much clearer that Game 2 will clash with Game 1, whereas Game 3 should be fine. For Game 4, with no EEPROM usage, we don’t need to worry. Finally Game 5 is a hog(!) and we might want to avoid, or backup our EEPROM before playing.