But it would be good to document the origin of the values. What do you think of Belmont's ideia?
The usual thing to do (as per e.g. NES) is to have PALETTE_INIT actually calculate the palette from the YUV values so it's documented where they come from.
By the way, Curt, there's also the fact that although the MC6847's specs (TABLE 3 — DETAILED DESCRIPTION OF VDG MODES) says its Resolution Graphics
modes' background is BLACK for both values of the CSS pin, in fact it is DARK GREEN when the pin CSS = 0 (i.e. when the foreground color is GREEN).
Check out the videos, taken from a real MC-1000:
- Alternating between Resolution Graphics 6 mode with MC6847's pin CSS=0 ("BLACK"/GREEN) and CSS=1 (BLACK/BUFF). The change in background color is perceivable.
- Alternating of Resolution Graphics 6 mode with CSS=0 and Alphanumerics Internal mode with CSS=0 (GREEN text, not ORANGE) and INV=0 (bright chars on dark background). No change in background color is observed.
So on mc6847.c
, instead of:
M6847_RGB(0x00, 0x00, 0x00), /* BLACK */
M6847_RGB(0x00, 0x7c, 0x00), /* GREEN */
we should have:
M6847_RGB(0x00, 0x7c, 0x00), /* DARK GREEN */
M6847_RGB(0x07, 0xff, 0x00), /* GREEN */
(Note that the GREEN color was wrong here.)
PC-6001VW vs. MESS MC6847 color comparision:
Well... ORANGE in PC-6001W is so whitish, almost pink... And DARK ORANGE is just plain orange there. That simply is NOT what I see on my real-life MC-1000.
[whiner]Oh... Green and orange text, normal and inverse, on the same screen... Damned MC-1000 designers, didn't wire MC6847 smartly to mix its screen modes. Since its BASIC is similar to Apple II's, probably they wanted to make it visually similar to Apple II on screen too (and that explains why the default text is bright on dark), so we have no block characters, no color, only inverse. So boring, booohooohoooo... :'(