Ah yes the Quake palette.

As a side note:
On a PCJr's or Tandy's enhanced CGA, you can remap the palette entries to arbitrary (CGA) colors using BIOS calls.
On an EGA or VGA, the same BIOS function exists, but does not work in CGA modes, because IBM apparently wanted to annoy people.
You can still remap the colors that an EGA or VGA use in CGA modes via direct programming, though.
A traditional CGA could be expanded with a relatively primitive set-top box, that does the translation externally, outputting the result either as RGBI or analog RGB signal.

IIRC, there is a TSR named CHGCOLOR for EGA cards.

...so, we have three ways to change colors:
CHCOLOR util for EGA and newer(?) cards
ANSIPLUS driver controls over VGA/EGA palette
and ANSI Code Table
which is works/better/easier and real hardware compatible ? (none of those works with real CGA card, right?)

here is another example with original cga palette colors (not real screens)

boobee wrote on 2020-02-09, 05:55:

(none of those works with real CGA card, right?)

Correct, but you should be able to get your second palette (Space Quest III, Prince of Persia) with a real CGA by wiring it up like this:

1CGA        CRT
2 R ─────┬── R
3 G ──┐  └── G
4 B   ├───── B
5 I   └───── I

That could be done in a pass-through connector, perhaps with a 4-polar toggle switch to switch this mod on and off.

EDIT: A 3-polar toggle switch should be sufficient, because R stays the same.

Digger and the shareware version of Jill of the Jungle had near ideal CGa pallets.

You'd hope so, since Digger was a CGA game.

i can`t say Jill`s palette "near ideal"... i prefer next:

If palette changing tricks worked reliably, and could be done on a per-scanline basis, you could at least use some of the tricks that the console guys used to switch palettes for sky/ground. Or, borders, heads-up displays, dialog windows, etc.

i know it's almost impossible, or too tricky to change colors to any combination i want ...and the limit of 16 colors that fixed because of digital signal ... and the fact is that IBM PC was developed not for games ... and so on... i wonder why so many games were developed in palette 1 ? yeah, it's default in bios but other palettes and tweaks are also available and officially supported and switching between them not so hard, game devs was lazy back then? ...probably, or maybe ibm pc market was too small in compare of home-game pc`s, and who cares about colors. So why make games for business platform at all?
Anyway, never thought magenta/cyan palette is ugly, but it was used too often and almost always graphically unlogic, for example use of palette 1 to represent tropics entourage... why??? obviously - the palette 0 is better choice, but not, cold colors for hot environment, nice...

I'm reminded a bit of Microsoft Decathlon's composite colors

ah... i was wrong, Jills of the Jungle was really good, palette 0 with blue background, a bit toxic but...

Something I've been wanting to try is a TSR similar to CHGCOLOR, but with a few enhancements:

- Target VGA rather than EGA (so the 4 colors can be selected from the full 6-bit/channel range)
- Support a separate mapping for each CGA palette (for cases where colors are switched during a game, using BIOS calls)
- A visual "palette editor" UI for color assignment

Not that I'll get to this in the foreseeable future, but all of these are possible.

Benedikt wrote on 2020-02-09, 13:01:

Correct, but you should be able to get your second palette (Space Quest III, Prince of Persia) with a real CGA by wiring it up l […]
Show full quote

Correct, but you should be able to get your second palette (Space Quest III, Prince of Persia) with a real CGA by wiring it up like this:

Copy code to clipboard

1CGA        CRT
2 R ─────┬── R
3 G ──┐  └── G
4 B   ├───── B
5 I   └───── I

Not sure about that. If "I" is disconnected, then the "yellow" (R+G) is the same as IRGB color #6, which a CGA monitor internally converts to brown by reducing the G level.

From the monitor's point of view "I" is not disconnected, but connected to the CGA's "G" output.
IIRC an average TTL output should be able to drive at least two TTL inputs, so all should be well.

By the way: This is my color remapping code for Tandy/PCJr., EGA and VGA that changes CGA mode 5 to shades of gray:

1        MOV     AX,1000h                ; Set palette register (on PCjr, Tandy)
2        MOV     BX,070bh                ; Remap light cyan to light gray
3        INT     10h
4        MOV     BX,080ch                ; Remap light red to dark gray
5        INT     10h
6        CLI                             ; Do the same on EGA and above
7        MOV     DX,3dah                 ; (Attribute controller)
8        IN      AL,DX                   ; Reset write mode to 'address'
9        MOV     DL,0c0h                 ; (DX = 3c0h, palette reg.)
10        MOV     AL,1
11        OUT     DX,AL                   ; Set color 1...
12        MOV     AL,7
13        OUT     DX,AL                   ; ...to light gray
14        MOV     AL,2
15        OUT     DX,AL                   ; Set color 2...
16        MOV     AL,56
17        OUT     DX,AL                   ; ...to dark gray
18        MOV     AL,3
19        OUT     DX,AL                   ; Set color 3...
20        MOV     AL,63
21        OUT     DX,AL                   ; ...to white
22        MOV     DL,0dah                 ; (DX = 3dah, attr. contr. reg.)
23        IN      AL,DX                   ; Reset write mode to 'address'
24        MOV     DL,0c0h                 ; (DX = 3c0h, palette reg.)
25        MOV     AL,20h                  ; Set bit 5 of address register
26        OUT     DX,AL
27        STI

Benedikt wrote on 2020-02-17, 14:26:

By the way: This is my color remapping code for Tandy/PCJr., EGA and VGA that changes CGA mode 5 to shades of gray:

Nice - yep, that's probably the most compatible way to go about it. I did something similar in this old video which goes through a bunch of different tweaked 4-color palettes (some of them nice, some less so).

Of course, extending the CHGCOLOR concept for VGA means you could also do the same with EGA games... 😉

Something that is never done on CGA but done on a variety of monochrome platforms is to flicker between the two pallets on every vertical blanking.

Takes zero programming skill and minimal cpu overhead
You would still get 4 colors but they would be brand new (not very good)

But not the normal 16 colors, and only one color can be controlled independently so not super useful but still better than nothing.

Flickering between two CGA palettes might not be the most practical solution for the reasons you already mentioned.
This technique would be much more useful in combination with text mode based pseudo graphics.

One variant that I personally experimented with a while ago is a text mode with 40 by 100 characters cells of 8 by 2 pixels, each.
With this mode, one screen page is exactly 8000 bytes large, which means that you can fit two pages in the 16384 bytes of screen memory that the CGA has.

If you then swap them in every vertical retrace period, the result looks like this:

The screenshot shows a hacked Planet X3 that still believes that it is running in low-res Tandy mode, i.e. there is no proper asset conversion, which is why everything looks so chunky and garbled.
What the screenshot cannot show is the brutal flickering. To mitigate that, one would have to make sure that the colors in the two pages do not differ too much.
You therefore cannot expect to get all the 136 colors that would theoretically be possible. It is also worth pointing out that this trick depends on knowledge of the ROM font, which the system cannot read out.

I figured cyan and magenta were chosen because they had a good contrast on amber/green/monochrome screens. (I have no idea if that's actually the case, though.)

Benedikt wrote on 2020-02-20, 19:51:

One variant that I personally experimented with a while ago is a text mode with 40 by 100 characters cells of 8 by 2 pixels, each.
With this mode, one screen page is exactly 8000 bytes large, which means that you can fit two pages in the 16384 bytes of screen memory that the CGA has.

Isn't that fairly similar to what they did in fancy demos like 8088 MPH?

Jorpho wrote on 2020-02-20, 20:38:

I figured cyan and magenta were chosen because they had a good contrast on amber/green/monochrome screens. (I have no idea if that's actually the case, though.)

In fact, cyan and magenta were not really chosen.
It is just that you only have two bits per pixel in that mode and since the card outputs an RGBI signal, i.e. one bit for red, green, blue and intensity, respectively, IBM simply made the red and green bits selectable per pixel and the blue and intensity bits selectable for the entire screen, only.
This really primitive solution worked without additional ICs.

Jorpho wrote on 2020-02-20, 20:38:

Isn't that fairly similar to what they did in fancy demos like 8088 MPH?

It has virtually nothing in common with 8088 MPH.
8088 MPH uses composite video, this approach uses RGBI video, instead.
One relies on the color smearing and artifact generation of the composite screen's NTSC decoder, whereas the other uses temporal dithering to get beyond the ordinary 16 CGA colors.
The main difference from a user's point of view is the type of screen you view it on: One strictly requires a composite screen and does not work on an RGBI screen, at all, the other does work on an RGBI screen, but does not have any advantages on a composite screen and will rather introduce unnecessary flickering.