5

The control codes (my C64 handbook actually calls them ASCII codes) for color changing on the Commodore 64 are as follows:

Color       Control Code    Color number

BLACK           $90             0
WHITE           $05             1
RED             $1C             2
CYAN            $9F             3
PURPLE          $9C             4
GREEN           $1E             5
BLUE            $1F             6
YELLOW          $9E             7
ORANGE          $81             8
BROWN           $95             9
PINK            $96            10
DARK GRAY       $97            11
MEDIUM GRAY     $98            12
LIGHT GREEN     $99            13
LIGHT BLUE      $9A            14
LIGHT GRAY      $9B            15

So, the command PRINT CHR$(5) for example changes the text color to white. But why are the colors so spread out in the code table? Internally, colors are assigned numbers from 0 (black) to 15 (light gray). The last seven colors from brown to light gray have subsequent codes starting from $95/149, but why has this not been done for all colors? For programming tasks like identifiying a color control code, translating from control codes to color numbers and vice versa this would have been much better.

I first thought that the ASCII standard might have defined places for these control characters, but I could not find color codes in the original ASCII.

Improve this question
3
  • 1
    I strongly suspect that the answer is closely related to retrocomputing.stackexchange.com/questions/15706/… - particularly, the locations of the F* keys in the control code map was probably determined by the simplest keyboard scanning logic. The colours are mapped to the shifted F* keys.
    – occipita
    Aug 6, 2020 at 11:10
  • 1
    @occipita They are an oddity as they weren't added with the PET keyboard. But basically yes. While some are scattered around where holes could be found, the series from Brown to Purple is exactly the function key codes plus 16.
    – Raffzahn
    Aug 6, 2020 at 12:12
  • @occipita: If memory serves, the VIC-20 has tables that maps key positions to character codes when keys are pressed in isolation, or in combination with shift, commodore, or control, and thus the keys could have been mapped arbitrarily equally easy. I wonder if having a single "select color" code which would then be followed by a digit 0-7 would have required more or less code in the kernel than the approach Commodore used (which requires comparing each output character against each possible color code).
    – supercat
    Aug 6, 2020 at 20:20

1 Answer 1

Reset to default
4

But why are the colors so spread out in the code table?

Because these were usable holes in the area of $00..$1F and $80..$9F. Some part was already taken by PET control characters (like Reverse), so everything had to be shifted around - plus, not only colours were added, but function keys as well.

Function keys, BTW, provide the only continuous stretch between $85 and $8C - and so are their colours.

For programming tasks like identifiying a color control code, translating from control codes to color numbers and vice versa this would have been much better.

There's much that could have been improved, but Commodores codes did evolve over several generations always trying to maintain compatibility(*1).

I first thought that the ASCII standard might have defined places for these control characters, but I could not find color codes in the original ASCII.

ASCII was never about colour. Also, most control codes used by Commodore redefine ASCII codes. Not really compatible to start with. Colour only became a standard for text with ANSI escape sequences.

*1 - While this worked mostly, the added complexity is way worse than with IBM Mainframe codes, which are usually blamed for their artefacts. IBM at least stayed compatible all the way, while Commodore switched at will, so is C128 PETSCII in part incompatible with C64, and worse, it's incompatible with itself in 80 character vs. 40 character mode.

Improve this answer
3
  • It is clear to me that usable holes among the existing codes had to be used. But It is still unclear to me why the holes have not been chosen in a more systematic way? For example, 8 consecutive codes from $15 to $1C would have been available in addition to $95 to $9C, which would have allowed at least for a mapping of two times 8 consecutive colors. Instead, the current color code mapping for colors 1 to 9 looks like engineers playing dart trying to hit any available control code for each color.
    – Peter B.
    Aug 6, 2020 at 22:09
  • @PeterB. To start with, $1B would be for example ESC ... not a good choice, like with anything below $20. So the question is rather why White, Red, Green and Blue are coded below $20. Most important, there is not enough room for an unbroken sequence of 16 codes. Thus any attempt to form a sequence becomes irrelevant as a translation (at $E8CB) is needed anyway.
    – Raffzahn
    Aug 6, 2020 at 23:09
  • @Raffzahn: What incompatibilities exist between the 40- and 80-column modes beyond the fact that RGBI monitors have a fixed set of 16 colors that lacks three composite-video colors that are supported by the VIC-II, but includes three colors that are absent from the VIC-II?
    – supercat
    Jun 15, 2022 at 18:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .