Was CGA mode 5 secretly intended for anaglyph 3D?

[ropersonline]

I'm just after looking at the CGA specs, and it struck me how the undocumented mode 5 has, besides black and white, exactly the colours you'd need for anaglyph 3D with those cheap filter glasses. Was this intentionally done or just a happy little accident?

Was mode 5 ever used this way? Is there any software for this? Even just a simple image viewer that can load and display images in mode 5? Does anyone know?

 

[Chuck(G)]

I don't believe so. Mode 5 was intended to give a better gray scale on monochrome displays and, FWIW, got rid of the awful magenta that dominated so many CGA graphics. A little discussion.

 

[reenigne]

I'm not convinced about the monochrome displays argument. It would make sense given that mode 5 is implemented by setting the +BW bit in the mode register, but for the fact that in the first versions of the CGA (before the composite output was tweaked to give different shades of grey on a monochrome display) red and magenta would have displayed identically. If you have a monochrome display connected to the RGBI output, then it's up to the monitor to decide which shade of grey to display for each of the 16 RGBI bit patterns. So it could have been done to give a better grey scale if there was an existing monochrome monitor with TTL input where black/cyan/red/white was a better grey scale than black/cyan/magenta/white (or in anticipation of such a monitor). I think it's equally likely that there were some spare gates and someone thought "we can have more possible palettes if we connect this up to here". Or possibly for testing purposes (to give a visual indication of the state of the +BW bit if you didn't have a composite monitor).

The anaglyph 3D idea is a nice one but I doubt that is what the CGA's designers had in mind. I don't think it would have worked very well with so few colours (at least my own experiments back in the day never gave a convincing effect). I suppose it's possible that they modified the circuit to try it out, found the same thing that I did, and then left the modification in place.

 

[kdr]

The alternate cyan/red/white palette is controlled by using the BW bit to select either the COLOR SEL bit (normal behaviour) or the C0 bit of the current pixel (when BW is set). The logic gates that do this are in U22, which is a 'LS51. This chip is a 3-input AND-OR-INVERT gate, and it comes with a "bonus" 2-input AND-OR-INVERT gate on the extra pins.

The CGA uses four 3-input AOI gates (U22, U27, U47, and U48). Strangely, U27 and U47 are both configured as a 2-input AOI gate by tying one pair of inputs high. Three of the four bonus 2-input AOI gates (U27, U47, and U48) are used to do fairly straightforward stuff.

So it looks like the design required two 3-input AOI gates and five 2-input AOI gates, and that the bonus 2-input AOI gate on U22 was indeed a spare gate.

I'm sure that the designers of the CGA were aware that its palettes were both limited and ugly, and figured this was a brilliant way to hack an extra colour selection into the adapter. It probably happened late in the design process.

 

[ropersonline]

O HAI reengine, good to see you here. I'm not sure we've talked before, but you're just the man I've been meaning to contact sometime.
If you find the time, would you have a look at my effortpost in this other thread and maybe tell me what you think? Especially on whether any of my crazy ideas would be feasible?

The anaglyph 3D idea (...) I don't think it would have worked very well with so few colours (at least my own experiments back in the day never gave a convincing effect). I suppose it's possible that they modified the circuit to try it out, found the same thing that I did, and then left the modification in place.

Oh. Not even for simple wireframe vector graphics?

Also, shouldn't checkerboard-dithered cyan and red have made filled (slightly overlapping) polygons possible?

 

[commodorejohn]

I mean, effectively in an anaglyphic setup you'd be limited to monochrome images (red and cyan being "white" in the left/right images respectively, while white is "white" in both,) which at 320x200 may be a tad limiting, but yeah, there's no reason you couldn't do it. Be interesting to try sometime, but of course I have no depth perception to speak of myself :lol:

 

[T-Squared]

3D Anaglyph only works because the image not only has two differently-colored layers, but mixes those layers together, producing either yellow (in the case of red-green anaglyph) or purple (in the case of red-blue anaglyph). You can only use the Palette 0 Black-Red-Yellow-Green palette to make 3D images. With Mode 5, it's not possible to add the extra purple color you need to make true anaglyph images. (You need 5: Black, Cyan/Blue, Red, White, and Purple) You can only do that in EGA.

 

[ropersonline]

3D Anaglyph only works because the image not only has two differently-colored layers, but mixes those layers together, producing either yellow (in the case of red-green anaglyph) or purple (in the case of red-blue anaglyph). You can only use the Palette 0 Black-Red-Yellow-Green palette to make 3D images. With Mode 5, it's not possible to add the extra purple color you need to make true anaglyph images. (You need 5: Black, Cyan/Blue, Red, White, and Purple) You can only do that in EGA.

That may be true for colour 3D anaglyph images. Once you're content with essentially effectively monochrome 3D imagery (though not exactly monochrome; perceptions differ and YMMV), then I think it should be possible to make this work. Mind you, the depth information is not encoded in different hues, it's encoded in how far apart those analogous cyan and red dots and lines are. And like I mentioned above, where they really overlap, those two colours could be checkerboard-dithered. EDIT: Or actually, maybe alternating vertical lines would be better than a checkerboard pattern, since our eyes are side by side. I haven't tried this, so I'm not quite sure which would work better.

Or at least that's my understanding. Correct me if I'm wrong.

 

[commodorejohn]

I think the resolution is probably too coarse for dithering to work as a true blending technique, but you could certainly do wireframe vector graphics or simple monochrome bitmap stuff.

 

[reenigne]

Oh. Not even for simple wireframe vector graphics?

Also, shouldn't checkerboard-dithered cyan and red have made filled (slightly overlapping) polygons possible?

Try it and see if you like - perhaps you will be able to get better results than I did. I was pretty young at the time - my assumptions about why it didn't work (too much light from the red areas leaking through the blue lens and vice-versa) may have been naïve or otherwise surmountable. I don't think I persisted with it for very long.

 

[ropersonline]

That reminds me, I need to put my 5150 back together and need to get it back in working order, hopefully without any new 'splody surprises from old tantalum caps or maybe RIFA caps or similar (in case there are some of those in the PSU).

Btw., I recently read this in an old post in an old and closed thread over on VOGONS:

Is it possible to get the unofficial cyan, red and white palette by bit manipulation?

Would anyone still like to hear a response to that? Because I think I might have a response to that in case people are still interested. Anyone? Great Hierophant? Bueller?

 

[kdr]

Would anyone still like to hear a response to that? Because I think I might have a response to that in case people are still interested. Anyone? Great Hierophant? Bueller?

I can't imagine that you could get cyan/red/white in 4-colour graphics mode except via setting the BW bit in the mode control register. Ordinarily, in graphics mode the two bits (C0 and C1) from the display RAM correspond to the R and G video outputs, while the B and I video outputs come straight from bits 4 & 5 of the colour select register.

But perhaps there's another way?

 

[ropersonline]

Btw., I recently read this in an old post in an old and closed thread over on VOGONS:

Is it possible to get the unofficial cyan, red and white palette by bit manipulation?

Would anyone still like to hear a response to that? Because I think I might have a response to that in case people are still interested. Anyone? Great Hierophant? Bueller?

I can't imagine that you could get cyan/red/white in 4-colour graphics mode except via setting the BW bit in the mode control register. Ordinarily, in graphics mode the two bits (C0 and C1) from the display RAM correspond to the R and G video outputs, while the B and I video outputs come straight from bits 4 & 5 of the colour select register.

But perhaps there's another way?

I take that as a yes.
Actually I understood Great Hierophant's question to mean, "Is it possible to get from a simple 2-bit truth table to the mode 5 palette in a really simple way?"

I think that's also a yes to that:
I initially thought this had been done by XORing R with 1 and rearranging the colours, but I now believe it's simply B=G:

2-bit truth table:
------------------
00
01
10
11

SHL of the above:
-----------------
000
010
100
110


B=G:
----
RGB
=========
000 = blk
011 = cyn
100 = red
111 = wht

So simple once you see it.

 

[reenigne]

I now believe it's simply B=G:

That is essentially how it's implemented by the logic on the CGA card, as kdr said earlier on the thread. Pins 2-6 of U22 and pins 5-6 of U20 give +SEL_BLUE = (+COLOR_SEL AND -BW) OR (+C0 AND +BW). +SEL_BLUE is B, +C0 is G, +COLOR_SEL is bit 5 of the palette register, +BW is bit 2 of the mode register and -BW is +BW inverted.

 

[reenigne]

+SEL_BLUE = (+COLOR_SEL AND -BW) OR (+C0 AND +BW)

It's a shame IBM didn't make it +SEL_BLUE = (+COLOR_SEL AND +C0) OR (+C1 AND +ENABLE_BLINK). That would not have required any additional gates, would have given us all the current palettes plus a new one (green/magenta/white), and made them work independently of the +BW setting so that they could all be displayed in either colour or monochrome on composite monitors.

 

[Trixter]

Meanwhile, I ordered some Chromadepth glasses on a whim and will be curious to see how well the effort works with the CGA 16-color palette.

 

[ropersonline]

Ordinarily, in graphics mode the two bits (C0 and C1) from the display RAM correspond to the R and G video outputs, while the B and I video outputs come straight from bits 4 & 5 of the colour select register.

Did you mean C0 is R and C1 is G?

Pins 2-6 of U22 and pins 5-6 of U20 give +SEL_BLUE = (+COLOR_SEL AND -BW) OR (+C0 AND +BW). +SEL_BLUE is B, +C0 is G, +COLOR_SEL is bit 5 of the palette register, +BW is bit 2 of the mode register and -BW is +BW inverted.

If I understood you both correctly, then you're saying C0 is G, but kdr is saying C1 is G. Who is right?
If you're right, then what's C1? Is it red? So just the other way around? I.e. C0 is G and C1 is R? (Now where was that circuit diagram again? Slightly above my pay grade, but still.)

 

[ropersonline]

Meanwhile, I ordered some Chromadepth glasses on a whim and will be curious to see how well the effort works with the CGA 16-color palette.

Oh, so not anaglyph 3D glasses but actual chromadepth 3D glasses? To try on an RGBI monitor or colour composite display or both? I imagine having a lot more colours available on the latter (and I realise I'm talking to the people who proved that ) would work rather better than just 4 or 16 colours on the RGBI display. If redder hues are more upfront and bluer hues down back, then I imagine chromadepth glasses might cause any dithering between e.g. cyan and magenta to "fall apart", especially on a less blurry and non-artifacting RGBI display. Correct me if I'm wrong and please let us know the results.

 

[Trixter]

They were ordered on a whim, so testing will be quick and silly. I was only going to test with RGBI 16 colors.

 

[kdr]

Did you mean C0 is R and C1 is G?

If I understood you both correctly, then you're saying C0 is G, but kdr is saying C1 is G. Who is right?
If you're right, then what's C1? Is it red? So just the other way around? I.e. C0 is G and C1 is R? (Now where was that circuit diagram again? Slightly above my pay grade, but still.)

I wasn't being particularly precise...

You can follow along by looking at Sheet 2 of the schematics for the CGA, which is where the video data is generated by combining 16 bits of data from video RAM with the MUX A and MUX B signals that control the current video mode.

C0 is the output of the '166 shift register U7 that handles the even bits from graphics mode (bits 0, 2, 4, 6, etc...) and C1 is the output of the '166 shift register U8 handling the odd bits. So each C0/C1 pair is (in sequence) bits 0+1, 2+3, 4+5, etc. C0 and C1 are then wired up to the '153 dual 4-to-1 mux at U9 that outputs the R and G bits; C0 goes into 2C2 and C1 goes into 1C2. When in graphics mode, the mux takes the inputs on xC2 and puts them on xY -- so 1C2 (which is the C1 bit of the current pixel) goes to 1Y (which is the R video output) and 2C2 (the C0 bit of the current pixel) goes to 2Y (the G video output).

Which is all to say that, yes, reenigne is correct that C0 is Green and C1 is Red.

Incidentally, this is where the ugly palette comes from: the other mux U10, which generates the B and I video bits, is fed from the SEL BLUE and BACKGROUND I signals in graphics mode. And these are 'global' signals, i.e. they don't come from the pixel data in video RAM but rather originate from the mode control and color select registers.... there is absolutely no way for the bits that come out of video RAM to influence the B or I video output when in graphics mode. That's why the 160x100 "16-colour graphics" mode is actually a text mode: it's the only way to hook up the data in video RAM to the B/I video output.