Help Dialog choose a Commodore 64 color palette!

Technical Development Interpreters
,
1

I’ve had a lot of nervous energy this weekend to pour into Dialog and Å-machine development, so I need to poll the audience one more time. If you just want the poll, without the elaborate backstory, skip to the second post in this thread.

Dialog basically supports two types of text styling. One type uses the full range of CSS, and is basically just for web browsers. The other, inherited from the Z-machine, represents styles with four bits: “reverse”, “bold”, “italic”, and “monospace”. On 8-bit platforms, the CSS is really just a fancy way of setting and resetting those four bits.

“Monospace” is not especially useful on the Commodore 64 or Apple II; currently, the interpreter goes to a great deal of effort to parse the CSS and set or reset that bit, and then ignores it entirely. (I don’t know why it goes to all the trouble, honestly. But it does.)

And in the current release of the 6502 interpreter, the “reverse” bit is completely ignored—just for procedural reasons, because there was no standard CSS property for “reverse the background and foreground colors” until last week.

Now that we’re supporting the Apple II, though, “reverse” is really the only styling an Apple II can manage! (Well, “reverse” and “flashing”, and I think supporting text-decoration: blink is a bad idea.) So the next release of the Å-machine tools will support reversed text on the 6502. That way, the Apple II will have at least a little bit of style support.

The Commodore 64, meanwhile, can’t do reversed text—it has no straightforward way of changing the background color of an individual character, only the whole screen at once. It can’t do bold or italic either, for that matter. But what it can do is change the foreground color of the text. It currently uses this to fake bold and italics: the “bold” bit chooses a lighter color, and the “italic” bit chooses a more saturated color (blue).

normal is black, bold is lighter, italic is bluer
normal is black, bold is lighter, italic is bluer1547×122 38.6 KB

Now that the 6502 interpreter can set and reset the “reverse” bit based on the CSS, it seems only natural to extend the C64’s color-based styling to include it. The question is…how?

2

Well, what we want here is three orthogonal axes: one for “reverse”, one for “bold”, and one for “italic”. If “bold” is lightness and “italic” is saturation, then it makes sense for “reverse” to be hue. So my first thought was to have “reverse” switch to warm colors instead of cool ones.

reverse is orange, reverse bold is yellow, reverse italic is red
reverse is orange, reverse bold is yellow, reverse italic is red1547×219 52.8 KB

If the yellow is too hard to read, we can use brown instead, but I find the brown and orange hard to distinguish, personally.

reverse is brown, reverse bold is orange, reverse italic is red
reverse is brown, reverse bold is orange, reverse italic is red1547×219 53.5 KB

Or, because the orange looks more “saturated” to me than the red, we could do it this way (or with brown in place of orange, as above):

reverse is red, reverse bold is pink, reverse italic is orange
reverse is red, reverse bold is pink, reverse italic is orange1547×219 52.8 KB

Another person on the team suggested that the third axis actually be a reversal: turn black into white.

reverse is white, reverse bold is yellow, reverse italic is red
reverse is white, reverse bold is yellow, reverse italic is red1547×219 76.1 KB

What do you all think about this? Which of these palettes is your favorite? (Or, feel free to suggest something else; these are the colors available.)

  • 1: Reverse is orange, reverse italic is red
  • 2: Reverse is brown, reverse italic is red
  • 3: Reverse is red, reverse italic is orange
  • 3.5: Reverse is red, reverse italic is brown
  • 4: Reverse is white, reverse italic is red
  • 5: Something else!
0 voters
3

Doesn’t the Commodore 64 have reversed characters above 128?

4

It does by default, but the Å-machine interpreter replaces them with the first 128 non-ASCII characters found in the game text.

The name of the virtual machine may show why that was prioritized over reverse-video! :face_with_tongue: Though in fact a special trick is used to ensure that the name “Å-machine” can print properly even if the character “Å” is not in the font. Character $09 is set to an “Å” symbol that’s used for interpreter messages, ensuring that game authors have a full 128 characters available for their own use.

5

Could it be a compiler option to use more of the actual reverse characters if non-ASCII isn’t needed? Or it could leave the alphabetic letters till last to be replaced?

6

The problem there is that it’s difficult to determine statically which characters might be printed in the reverse mode and which won’t.

Also, though, I think a change in foreground color looks better than true reverse-video. The only reason it’s linked to the reverse-video CSS property is because that’s now supported for the Apple II, which means adding it to the C64 is basically free (costs a single-digit number of bytes). Supporting any other CSS property would be much more expensive.

7

I’d probably map bold to reverse video on Apple ][ and call it a day. Anything else would require rendering all text in the high resolution graphics mode, eating 8k of memory.

C64 does have an extended video mode where the upper two bits of the character code control which of four possible background colors are used, but it limits the core character set to 32-95.

It’s rather hairy, but you could theoretically implement dynamic character set updates on C64. You have 256 possible character codes, so treat it like a cache; the only limit is you can’t have more than 256 unique characters (where a “character” includes its style - normal, italic, bold, underline) on screen at once.

Bold can be done by just shifting once and OR’ing (things like W and M might not look great though). Italic can be done by shifting the first four rows right once (depending on whether the gap for character spacing is on the left or right). They won’t be perfect and you might need to code up a few special cases that are done manually.

If you implement scrollback the code will be that much more complex; you’d need to remember the original style of each character somehow.

EDIT - Realized I’ve overcomplicated it somewhat. Bold can almost assuredly be done entirely with a color change instead of actually doing an entirely new font. That means that bold and one other character style (probably italic) could be applied orthogonally. The downside of using color attributes in general of course is that now you have to “scroll” attribute memory too, not just character memory.

-Dave

8

Dread Ramsberg made a full, text-adventure-specific color example grid that might prove really useful here: https://ozmoo.online/colours/

Also: when/where is the Apple II interpreter news?!

9

It got kind of buried under the AI-generated documentation discussion, but it dropped with little fanfare last week—one of my IFComp entries comes with an experimental Apple II port as a result, and I’m going to try to draw more attention to it with a separate thread tomorrow night once the IFComp games drop! Since the Apple II and the Commodore 64 both run on the 6502 processor, most of the code works exactly the same between them; Steven Hugg wrote a new frontend that replaces the C64 kernel calls with Apple II ones, and fixed some bugs in the underlying engine in the process, and now Apple II disk images are on the table!

10

Wait, that Steven Hugg? I have all of his books. Small world!

11

I think so, yeah! He’s been fixing all sorts of issues with the 6502 interpreter; his expertise is really a godsend, because I don’t think I could have handled any of them alone.

12

I would certainly not be opposed to proper bold and italic on C64, but I’m afraid I also don’t have the skills to make it happen. I can (barely) maintain the 6502 interpreter and keep it updated as the Å-machine develops, but an overhaul like that is beyond me.

13

When I was doing research for my Lanthorn interpreter to support native disk formats and the original color schemes I took a bunch of screenshots from various emulators (and borrowed a few screenshots from the web or YouTube walkthroughs). The screenshots are all here if you need references for various platforms: lanthorn/machine-screenshots at main · sharkusk/lanthorn · GitHub

one note, the C64 colors looked different depending upon the release (see the screenshots). And C128 in 80 col mode was also unique.

14

I’ve managed to re-learn the 6502 expertise I’d last used in the 80’s writing a z3/z5/z8 interpreter for the Apple 2 so I’m happy to take a look if it’s not something either you or Steven are interested in. The biggest issue is whether the interpreter supports scrollback or not. If it does, it’s a much harder problem because we have to remember the character code and style in the scrollback buffer. (This could be done by reserving part of the character range to represent style changes which are never actually displayed though).

The overhead would be the size of the code and probably two 128 byte LUT’s which map a character code (assuming no more than 128 characters including accented characters etc) to the correct 8-bit slot, or a sentinel value if it’s not correctly allocated. This assumes bold is done with color, and italic is done with a unique glyph. If bold was done as a glyph as well (and was orthogonal to italics) then we’d need twice as many LUT’s.

If 64 unique characters at once on screen were enough (it would be close!) then reverse video (common for status lines) would be “free”.

We might need some reverse LUT’s as well to speed up keeping track of which characters are in use.

The other possibility is if the special styles are never dynamic and the exact letters we need are known ahead of time, the font is computed at story generation time.

Depending on the number of accented characters needed, and whether we needed lower case or not, it could be possible to statically break up the character set - 0-31 special symbols and numbers, next 32 is upper case letters, next 32 is lower case, next 32 is upper case italic, next 32 is lower case italic, next 32 is reverse color upper case, etc.

As an Apple 2 person, I was always a bit jealous of all the cool stuff the C64 could do in hardware. The only saving grace of the Apple 2 is that it seems somehow to be slightly faster because it doesn’t have “badlines” and video update is strictly in the “other” processor phase.

-Dave

15

No scrollback currently. A 16-bit Å-machine file can have just under 256 printable characters in it ($23 of them are reserved control codes, but 5 of those control codes need to be printable because the interpreter uses them for its own purposes).

I definitely feel you on the Apple II vs C64! It hurts not being able to style anything beyond reverse-video, but I do like how much faster my games play on it.

16

Random thought I just had – use Markdown syntax for styles on Apple ][.

So when somebody requests italic style, print an _ and then another one when they turn it off. When they request bold style, print an * and then another one when they turn it off.

Better than nothing, I guess.