1

In extended colour mode:

For characters 32 to 63 on background 1 (53281/$D021 value), I can add 192 to get the same on background 2 (53282/$D022 value). For characters 64 to 95 on bg1, I can add 128 to get the same on bg2

...at least that's the theory. But I'm finding that character chr$(63) is falling in to the second set: so 63 + 128 = chr$(191) prints correctly, but chr$(255) doesn't? Not a biggy, I can workaround, but i'm reluctant to believe that the documentation is wrong especially as 64 seems to be a more sensible cutoff point than 63. This may be a Vice bug?

Simon
  • 567
  • 5
  • 14
  • Your wording is a bit confusing. Are you talking about the 4 different background colors that can be used in extended color mode? – Michael Sep 14 '21 at 11:40
  • Apologies I severely cut down my original and deleted the bit where I explained my bg1/bg2 notation: will fix it up – Simon Sep 14 '21 at 12:01
  • 1
    Note that these days there's a whole stack exchange site http://retrocomputing.stackexchange.com/ that's usually a more appropriate choice for programming questions for now-obscure retro systems. (Not like x86-16 DOS assembly, which is similarly old but for some reason still taught.) – Peter Cordes Sep 14 '21 at 12:06
  • I still find the wording a bit confusing, as saying _"on background 1"_ and _"on background 2"_ makes it sound like you're talking about different background layers. So are you in fact just talking about the 4 different background colors, or is the question about something else? – Michael Sep 14 '21 at 12:22
  • yeah the four different background colours of extended mode, more specifically just the first two (haven't checked this character with the other two... that might be interesting). Or i guess the first background colour 53281 is a layer, and the rest are background colours... – Simon Sep 14 '21 at 13:13
  • and good point on retrocomputing... forgot about that site! Mods: feel free to move it – Simon Sep 14 '21 at 13:15
  • Well, I was under the impression that the 2 most significant bits selects the background color, and the remaining 6 bits selects the character (resulting in 64 possible characters). So 191 would be character 63 with background color 1, while 255 would be character 63 with background color 3. – Michael Sep 14 '21 at 14:10
  • Yeah OK that's interesting. If it was the first 64 characters 0 to 63 that would be nice and clean. But the first 32 characters are all sorts of "exotic" chars like changing colours, clearing screen (i think) and things like that rather than being "actual" characters... so the 64 characters are 32 to 95... and like you say, anything over 63 can't fit in 6 bits so I guess the chr$() function is translating 32 through 95 as index 0 through 63, and then.. hmm.. i need to ponder on this! – Simon Sep 15 '21 at 00:38
  • If you take c64-wiki: it says two most significant bits = background. Bg1 = 00, bg2 = 01. It also says "The remaining six bits indicate which of the first 64 characters [...] appear"... Cool... then it says "bit six is set by holding the SHIFT key"... and concludes "Therefore [bg2] is invoked by typing with the SHIFT key". This doesn't make sense: if shift only affects bit 6, then character 26 (for example) goes from 00011010 to 00111010... the two most significant bits are not affect at all? Later it says for characters without a shifted version "you need to [char code] + 192" – Simon Sep 15 '21 at 01:17
  • ...so 192 would add "11" to most significant, which should select background 4 (according to wiki)... As experimental evidence shows: the first 32 chars AND 11xxxxxx = bg1, and the next 33-63 characters AND 1xxxxxxx = bg1... Which works only if you consider bg1 = "11" (which it's not meant to according to docs) and for some reason char 63 = 191 with bg1 = 10111111: which SHOULD be a different background colour as two most sig bits are different from every other character? I'm clearly missing something important... – Simon Sep 15 '21 at 01:27

1 Answers1

2

It looks like you're confusing the PETSCII values (CHR$()) for the screen codes that are used in display.

Screen codes 0-63 use background 0, 64-127 use background 1, 128-191 use background 2, and 192-255 use background 3.

There is not a 1:1 mapping between screen codes and PETSCII values. You can't take the ASC() value of a character and do something like CHR$(ASC("X")+64) to reliably get a screen code that happens to be 64 more, even though you may find some cases in which that might be true.

BRPocock
  • 13,638
  • 3
  • 31
  • 50
  • Was debating whether to tick or add new answer: you're right: it's the arbitrary mapping that explains the weird "cut off" I found at 63 (rather than 64). The chr$ values for bg 1 range from 191 to 254: 64 values, but a cut off at 254 which is also weird... But considering the screen codes makes much more sense in terms of relying on typical bit-derived norms. Codes 0 to 63 (aah, tidy) have 64 added (ah) to give 64 to 127 (aaaaaah). Much better. – Simon Sep 17 '21 at 03:51
  • 2
    The documentation on c64-wiki.com must be incorrect: where it says (paraphrasing) "characters without a shifted version 32 to 63 need 192 added to the chr$()", it SHOULD say "characters 32 to 62 need 192 added, and character 63 (question mark) needs 128 added (191)". I'll propose an edit. – Simon Sep 17 '21 at 03:52