0

I’ve just come to working on a c64 in the retro gaming area.

I’m wondering why on the c65 a character is 8 bytes but anything else like modern web development, say in php, a character is only 1byte

Is this something to do with how the c64 display works? That it needs all that data to generate the character on screen?

Glen Elkins
  • 867
  • 9
  • 30
  • 2
    Seems more fit for [Retrocomputing Stack Exchange](https://retrocomputing.stackexchange.com/) than here. – Alejandro Dec 22 '20 at 12:15
  • 2
    The only reference to characters being "8 bytes" on C64 is [this answer explaining how the font is stored in C64 ROM](https://retrocomputing.stackexchange.com/a/8278). If that's what you mean then that's just the graphical representation of a character taking up 8 bytes. That doesn't mean that a single character in a string takes up 8 bytes at all! – Joachim Sauer Dec 22 '20 at 12:17
  • Ah yes I see what you mean. That clears it up thanks @joachim sauer it’s a bit like how a sprite is stored? Except that uses 64 not 8 - same concept I mean – Glen Elkins Dec 22 '20 at 12:25
  • @GlenElkins: I'm not really an expert on C64 and how it implements all those details, but yes, generally speaking I would consider that a 8x8 sprite with 1 bit "color depth" (i.e. monochrome). – Joachim Sauer Dec 22 '20 at 13:26

2 Answers2

5

You are not doing an apples to apples comparison.

A character on the C64 takes up a single byte, just like a modern system (simplifying here; I am not sure of the size of a unicode character). But for display purposes there are a number of options:

  • The regular text-mode screen is 25 rows by 40 characters characters, or 1,000 bytes. When you write a byte to a position (say, [5,2] which is row 5, column 2), the system will display that single character.
  • In a bitmap setting, you can either use hi-res (200 rows by 320 columns) or multi-colour resolution (200 rows by 160 columns); the difference in these two is that in hi-res you can have only two colours per 8 columns (i.e. on or off state), but in multi-colour you can have four colours (by allowing each "column" to be represented by 2 bits, and with 2 bits you can have four states). In both modes you need roughly 8k of memory (8000 bytes to be precise). When using bitmapped graphics you would "draw" each character to the screen, and that would require your 8 bytes per character (since a normal font on the C64 is 8x8 pixels, which equates to 8 bytes).

These are not sprites. In a vanilla situation you can have 8 sprites and control their position, overlaid on top of the bitmapped (or text based) display. Sprite resolution (i.e. 2 colour or multi-colour) follows the same logic as hi-res or multi-colour resolution for bitmapped graphics.

tendim
  • 447
  • 3
  • 10
2

You have to think in terms of "character graphic data" vs "text data"

The Arial true type font is 756kb, and has data for 3,988 characters: that's about 194 bytes per character

PC standard ASCII text files = 1 byte per character = any 1 of 128 total characters (the 8th bit is unused). The text file doesn't store the actual characters themselves, just a reference to them.

c64 uses a character set called PETSCII which is derived from ASCII and has two modes: upper & lower case, and upper & graphical characters. They're only 128 characters each plus 128 reversed versions. So 255 characters for each set/mode, so PETSCII text files (if there is such a thing?) would be 1byte per character too (and I guess you could use the 8th bit for defining reverse on/off? Not sure about that!). The characters themselves are defined in memory using 8 bytes for a raster 8x8 graphic: a lot less data than a PC font.

Simon
  • 567
  • 5
  • 14
  • Good answer, and to your question: Yes, there are PETSCII text files. In fact, CBM-DOS puts aside an entire file type (SEQ) just for them. PETSCII files are most often used by word processors and BBS server software. – Bo Zimmerman Oct 04 '22 at 23:54