EPROM year is ambiguous
michaesc opened this issue · comments
The Readme.md file states:
DC Year: Use 0x1B for DC27
...however Defcon is occurring more than once per year (for example Defcon 1.0 is in Beijing in the year 2019.)
The flawed EPROM identification design seems to assume that all Defcon occurrences outside of Las Vegas are invalid? Let's fix this, but how?
Implementation
I'm about to implement your AT24C32 based design for DC 1.0 (Beijing), so it would be great to help me avoid hundreds of loss or a flawed identification config.
Good point. Perhaps we register specific values to specific conference occurrences? Same way we picked 0x49 as our maker ID.
Limited to 256 possible values but exhaustion of this value is a good problem to have.
It's really too bad to lose the simple (math is in your head) year field, but I can't think of a more natural method than to map values as @ANDnXOR suggests. An alternative but weaker solution involves maintaining the ambiguous year only value and assuming the maker assigns a different Type ID according to Defcon location. I don't like the Type ID resolver much.
That leads to the next question, 'Where do we track values and mappings of all kinds?'
Can I haz ID 0x42 and claim it here?