4 ms·

> Using the hexadecimal system contributed to save ROM space by minimizing the size of the graphical data at a time when it was very expensive. This is incorre

> Using the hexadecimal system contributed to save ROM space by minimizing the size of the graphical data at a time when it was very expensive. 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.

nightcracker 6y ago
Having a clear understanding of what is data, and what is a representation of that data (and being able to grok and manipulate both) is probably my #1 indicator of who is or isn't a good computing engineer. This is a primary example of a failure of this.
- jimbob45 6y ago
  Would you care to enlighten us dentheads on the difference between the two?
  - makapuf 6y ago
    Not OP, but 255 and 0xFF represent the same data, but the representation is not the same. Same for A and 65 in ascii by example. Edit: typo.
    - cpeterso 6y ago
      so same bit patterns, different meaning?
      - Doxin 6y ago
        I could draw an A on a piece of paper and it'll have the same meaning too. There's a near infinite amount of ways to "encode" the letter A. Same thing goes for any data. the more complex the more ways to represent that data. 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.
  - ramses0 6y ago
    Pi (π) can't be stored on a computer b/c it's infinitely long, it would run out of memory! 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?
  - nightcracker 6y ago
    Suppose my data is a single letter, the letter 'x'. I might represent this data as (for example): 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.
yorwba 6y ago
Hexadecimal definitely saves space if you compare it to binary-coded decimal. You might think that obviously nobody would ever use BCD because it wastes so much space, but lots of people used it anyway.
- colonwqbang 6y ago
  You can describe BCD using hexadecimal notation. You can describe binary data using decimal notation. Notation is orthogonal to storage format. 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".
  - megameter 6y ago
    On the other hand, bitmaps stored in planar form were supported by many hardware systems in the time frame of the article(the Amiga, for one, used a planar scheme). This did allow for bitdepths other than powers of 2 with the requirement of resolutions being multiples of a byte or word(so, 8 or 16). This is particularly useful when considering overall asset storage constraints - 8 colors(3bpp) is often plenty for small sprites.
ridaj 6y ago
I think the real space saver is not necessarily "hexadecimal system" per se but the "bitmapped graphics" technique that they seem to be referring to. Nowadays, graphics information doesn't tend to be packed in bitmaps, either manually or otherwise. It's pretty inconvenient for processing to have everything bitmapped (compositing, collision detection, etc.) and they probably wouldn't do it if it weren't for the space savings
- bitwize 6y ago
  Bitmaps do not save space relative to, say, a vector representation -- but they do save CPU time. And they were hella convenient to work with for compositing and collision detection because there was specialized hardware to do just that. The sprite hardware in the video unit of most game consoles could draw bitmaps with transparency just as the electron beam arrived at the affected pixels. And it would signal an interrupt when two sprites collided (and often alert the CPU via registers which two sprites collided).
- BurningCycles 6y ago
  Yes you are correct. Take something like the Super Nintendo, it typically displayed hundreds of colors on screen, however each graphical element could have a maximum of 16 colors (4 bits). 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.

nightcracker 6y ago

Having a clear understanding of what is data, and what is a representation of that data (and being able to grok and manipulate both) is probably my #1 indicator of who is or isn't a good computing engineer. This is a primary example of a failure of this.

jimbob45 6y ago
Would you care to enlighten us dentheads on the difference between the two?
- makapuf 6y ago
  Not OP, but 255 and 0xFF represent the same data, but the representation is not the same. Same for A and 65 in ascii by example. Edit: typo.
  - cpeterso 6y ago
    so same bit patterns, different meaning?
    - Doxin 6y ago
      I could draw an A on a piece of paper and it'll have the same meaning too. There's a near infinite amount of ways to "encode" the letter A. Same thing goes for any data. the more complex the more ways to represent that data. 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.
- ramses0 6y ago
  Pi (π) can't be stored on a computer b/c it's infinitely long, it would run out of memory! 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?
- nightcracker 6y ago
  Suppose my data is a single letter, the letter 'x'. I might represent this data as (for example): 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.

yorwba 6y ago

Hexadecimal definitely saves space if you compare it to binary-coded decimal. You might think that obviously nobody would ever use BCD because it wastes so much space, but lots of people used it anyway.

colonwqbang 6y ago
You can describe BCD using hexadecimal notation. You can describe binary data using decimal notation. Notation is orthogonal to storage format. 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".
- megameter 6y ago
  On the other hand, bitmaps stored in planar form were supported by many hardware systems in the time frame of the article(the Amiga, for one, used a planar scheme). This did allow for bitdepths other than powers of 2 with the requirement of resolutions being multiples of a byte or word(so, 8 or 16). This is particularly useful when considering overall asset storage constraints - 8 colors(3bpp) is often plenty for small sprites.

ridaj 6y ago

I think the real space saver is not necessarily "hexadecimal system" per se but the "bitmapped graphics" technique that they seem to be referring to. Nowadays, graphics information doesn't tend to be packed in bitmaps, either manually or otherwise. It's pretty inconvenient for processing to have everything bitmapped (compositing, collision detection, etc.) and they probably wouldn't do it if it weren't for the space savings

bitwize 6y ago
Bitmaps do not save space relative to, say, a vector representation -- but they do save CPU time. And they were hella convenient to work with for compositing and collision detection because there was specialized hardware to do just that. The sprite hardware in the video unit of most game consoles could draw bitmaps with transparency just as the electron beam arrived at the affected pixels. And it would signal an interrupt when two sprites collided (and often alert the CPU via registers which two sprites collided).
BurningCycles 6y ago
Yes you are correct. Take something like the Super Nintendo, it typically displayed hundreds of colors on screen, however each graphical element could have a maximum of 16 colors (4 bits). 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.