This is incorrect, hexadecimal is just a different notation for binary information. It saves space when written down on paper, not in the actual ROM image.
This is incorrect, hexadecimal is just a different notation for binary information. It saves space when written down on paper, not in the actual ROM image.
Importantly none of the representations are A. A is a concept and doesn't exist as a real tangible thing in the way paper, bits, or other encodings do.
The map is not the terrain.
data != the representation of that data
Can you suspend pedantry long enough to calculate the area of a circle? What about the approximate area of a circle? Did the addition of the word "approximate" make a difference in how you interpreted the request/statement?
1. The integer 24, as x is the 24th letter of the alphabet.
2. A picture of a handwritten x.
3. The symbol x, as I did above.
4. The integer 120, as in ASCII.
All of these represent the same data, despite being different.Data representation often has multiple layers. For example that integer 120 from ASCII is then often represented as a single byte containing bits 01111000. The 'symbol x' has some unspecified representation. The picture might be represented using vector art, or an array of pixels, each with a color (which then requires[1] a representation for the colors).
Now suppose I'd want to write a function that gives the next letter after the symbol I'd give in. Choosing the right representation for your data can make this easy or hard.
For the example above, representations 1, 4 are very easy (simply increment the number of the representation by 1), 3 is somewhat easy, and 2 is highly impractical.
---
[1] I said something requires a representation. But this is only true when creating a concrete implementation. But while designing algorithms or systems it can often simplify things to simply think of the data, and not its representation.
The way they solved this was by having CLUTs (color lookup tables), so for the Super Nintendo (if my memory serves me) you had 16 different CLUTs that you could assign to a graphical object, each able to contain 16 unique colors.
This is what made something like the Super Nintendo graphics look so much better than say the Amiga 500, both used bitmap graphics, but the Amiga did not have a CLUT solution, so you were stuck with 32 colors except for more advanced graphic modes which weren't really usable for games.
I don't think storing bitmap graphics in ROM as BCD was ever really a thing. If you had reserved space for 4 BPP, would you really say "nah I don't need 16 colours, 10 is enough for me".