When using a 135 degree offset to test Tandy 1000 colors, I noticed that the chroma colors get tinted as well, though they're not supposed to. This in turn affects the artifact colors and overall the results look wrong.

Oh yes, you'll have to use a different color_burst array for Tandy 1000 as well as changing hue_adjust so that the chroma colours remain unchanged and only the artifact colours are colours are shifted through 135 degrees.

I'm not sure offhand if the right color_burst array for Tandy 1000 is:

1            int color_burst[8][8]={
2                {0,0,0,0,0,0,0,0}, /* D0 */
3                {1,1,0,0,0,0,1,1}, /* D1 */
4                {0,1,1,1,1,0,0,0}, /* D2 */
5                {1,1,1,1,0,0,0,0}, /* D3 */
6                {0,0,0,0,1,1,1,1}, /* D4 */
7                {1,0,0,0,0,1,1,1}, /* D5 */
8                {0,0,1,1,1,1,0,0}, /* D6 */
9                {1,1,1,1,1,1,1,1}};/* D7 */

or

1            int color_burst[8][8]={
2                {0,0,0,0,0,0,0,0}, /* D0 */
3                {1,1,1,1,0,0,0,0}, /* D1 */
4                {0,0,0,1,1,1,1,0}, /* D2 */
5                {0,0,1,1,1,1,0,0}, /* D3 */
6                {1,1,0,0,0,0,1,1}, /* D4 */
7                {1,1,1,0,0,0,0,1}, /* D5 */
8                {0,0,0,0,1,1,1,1}, /* D6 */
9                {1,1,1,1,1,1,1,1}};/* D7 */

So just try both and use whichever one gives the right set of chroma colours.

reenigne wrote:

Can you take a picture of what those same Mask of the Sun screens look like on your TV? I'm interested to see what it makes of them.

I'm on a little vacation for Easter. Will try when I get back. Since I'm not much of a photographer, I'll have to fiddle with my (oldish) cellphone's camera and hope the resolution is good enough, so no promises.

reenigne wrote:

Actually I think this sort of filtering is doable - it's just a different FIR filter, which requires a bit more code to set up but actual inner rendering loop is the same. Take a look at Blargg's NES libraries at http://blargg.parodius.com/ntsc-presets/ to see what sort of things have been done in the past.

NewRisingSun's old post ( Re: 40 Column Text Mode Issues ) indicates that he was using wide-angle color demodulation for his filtering, though his webpage is no longer available nor archived.
About the vertical stripes that show up in Servo's screenshots, in some cases they seem to actually reduce the clarity somewhat... if this is just a way to artificially increase sharpness, then yeah, I don't think it would be too beneficial to implement in this case.

re: Tandy -

reenigne wrote:

So just try both and use whichever one gives the right set of chroma colours.

Thanks - the second one did it; shifting the hue adjust 135 degrees retains the solid cyan and magenta (see image). Assuming that the Tandy 1000 didn't fiddle with anything else, I guess the rest of the colors (chroma+artifact) should also be considered correct. They don't line up with NRS's Tandy results; but at this point, I'd say the only way to prove reliability would be to test this on an actual Tandy 1000.

NewRisingSun's old post ( viewtopic.p...ight=66515 ) indicates that he was using wide-angle color demodulation for his filtering,

I read through the thread (again!) and came to these conclusions:
* Wide-angle color demodulation is a hack which some TVs implemented to make the picture look "better" (warmer) in the shop compared to the other TVs, at the expense of colour accuracy.
* It's easy to implement - just a slightly different matrix to convert between YIQ and RGB.
* It's not a particularly desirable feature to implement, being yet one more knob to adjust and not adding any accuracy (unless your composite monitor happened to be a TV which implemented it).
* Being purely a colour transformation, it's nothing to do with the "fringing" artifacts mentioned earlier in the thread - it's completely orthogonal to that.

the CGA2NTSC converter from the previous page has gotten a few downloads... so for anyone interested, here's a bugfixed and improved version.

Program is attached. Changes:

- Can simulate a newer CGA model (P/N 1501981) as well as the old one (P/N 1501486)
- Can do gamma correction
- Fixed minor bug w/ color #8 (with color-burst off it's now dark grey, not white)

all of these are courtesy of reenigne, so full credit goes to him - I'm only "repurposing" his code.

The newer CGA revision generates a different composite signal (by adding the R, G, B components to the chroma/luma output). For artifact colors produced by white/grey pixels - i.e. pretty much every 640x200 game - this doesn't change a thing; but solid chroma colors are affected, and so do the resulting artifact colors (or monochrome shades).

The technical lowdown can be found in this thread over at VCF. But this is the effect on the palette of "solid" colors:

The "new" CGA (1501981) colors are very close to NewRisingSun's images at Wikipedia and to most hardware CGA captures I see around the web, which sort of hints that this CGA version is more common in the wild.

It also gives us distinct levels of grey in monochrome mode. The RGB version of Tapper sets the cyan/red/white palette on level 1, which disables the composite output's colorburst signal. The "new" CGA code (middle) shows it in different shades, but the "old" one (right) wouldn't:

Gamma correction decodes with a gamma value of 2.2, to more accurately reproduce the output from a TV screen. The result may appear "too dark" in many cases, especially when a low intensity palette is set, but most games that targeted composite displays didn't do that.
The below images all use the "new" CGA code, so you can compare with the "old" CGA ones on the previous page. Left = original, middle = non-gamma-corrected output, right = gamma corrected.

composite version of Tapper (being mode 6/white) looks the same as it would with the "old" CGA code; compare with screencap on Mobygames:

Murder on the Zinderneuf (compare with this one):

Ancient Art of War:

Below the Root (vs. more screenshots on MG):

Dig Dug gets hit hard by gamma:

Shamus:

Jungle Hunt (yes, another one to compare with a MobyGames capture):

if you find this code useful, let me know. At the very least, it gives us the basics for a DOSBox patch.....

Thanks. Always nice to see a different implementation.
From a quick look, gamma would be easy to add to the dosbox code as it can go into precalculation function.

Not sure why, but in the code from my last post I defined SATURATION=0... should be 1 for most "normal" testing, for anyone wondering why all output is grey. 😉

@Qbix -

Thanks. Always nice to see a different implementation.
From a quick look, gamma would be easy to add to the dosbox code as it can go into precalculation function.

True. The color encoding/decoding could go into the precalculation function too - let the new code compute the 16 colors for the current mode + color register, and set the internal vga palette accordingly. This way the existing line-drawing routine should work as-is... not sure how precise it would be, but it should cover most games, except those that modify the color register in mid-frame (e.g. Jungle Hunt).

The real question is how to let DOSBox differentiate between normal and composite output in mode 4. Most obvious solution is a new machine type, but in that case, composite output would need to be removed from machine=cga for consistency's sake...

VileRancour wrote:

Not sure why, but in the code from my last post I defined SATURATION=0... should be 1 for most "normal" testing, for anyone wond […]
Show full quote

Not sure why, but in the code from my last post I defined SATURATION=0... should be 1 for most "normal" testing, for anyone wondering why all output is grey. 😉

@Qbix -

Thanks. Always nice to see a different implementation.
From a quick look, gamma would be easy to add to the dosbox code as it can go into precalculation function.

True. The color encoding/decoding could go into the precalculation function too - let the new code compute the 16 colors for the current mode + color register, and set the internal vga palette accordingly. This way the existing line-drawing routine should work as-is... not sure how precise it would be, but it should cover most games, except those that modify the color register in mid-frame (e.g. Jungle Hunt).

The real question is how to let DOSBox differentiate between normal and composite output in mode 4. Most obvious solution is a new machine type, but in that case, composite output would need to be removed from machine=cga for consistency's sake...

Yeah. Why IBM would need OUT &H3D8, &H1A: OUT &H3D9, &H3F to go to composite mode if the composite monitor can do that without those codes?

It are more than 16 colours of course. If were exactly 16 colours then the red bleeding and thing like that didn't exist. (that are precalculated)

The mode 4 is indeed a thing to consider, but at the moment I am not really willing to add another machine type.

Is it worth to make a patch then?

Not sure if it'll make any difference, but my vote is for a new machine type or other config switch.

My reasoning is that composite isn't a "mode" of the CGA card, it's a completely different type of monitor (which connects to a different port on the back of the CGA card). All modes can display on each type of monitor or even on both at once (though any given mode will look different on the different monitors - some modes will look more different than others).

The reason that the port writes are used for most CGA composite games is that one of the bits in the mode select register is the "color burst disable" bit, which the PC BIOS sets by default for 640x200 mode, and which yields a black and white image on composite monitors if set. Composite CGA games also generally set the palette register to 15 to make the colours brighter than the default 7. However, if you think that it's not meaningful to have composite output in modes other than 0x1a (or indeed RGB output in mode 0x1a) you're labouring under a miscomprehension.

If that's not your argument and instead (for UI simplicity reasons) you want DOSBox to automatically select monitor type based on a heuristic (i.e. 0x1a in port 0x3d8 means use the composite monitor, other modes mean use the RGB monitor) then that's harder to argue against, but know that with this heuristic some games will not be displayed the way their designers intended.

Perhaps a good compromise would be a "composite=yes|no|auto" switch in the config file with "auto" (the current behaviour) being the default. This would allow users to force composite decoding to be enabled or disabled, and I think that would make almost everybody happy. If that patch would be accepted I'll even volunteer to write it myself.

(Though what I really want is to be able to display CGA composite, CGA digital and Hercules/MDA all at once, but I know that's quite a bit more work and I don't know of any games for which that would be required!)

Are there Games that:

• 1.) Want to display CGA RGB mode 4 graphics, and
  2.) don't work with machine=ega or another newer type, and
  3.) don't look acceptable with composite rendering?

Probably there are... But if not, composite mode could simply be made the default for machine=cga and mode 4, no? Or would that break too much precedent?

From reviewing the screenshots above, I would suggest that most developers or porters had the early cards in mind when they designed their graphics for composite video. Shamus and Jungle Hunt are almost too dark to play, and even the tree in Below the Root seems somewhat more appropriate in more orangish brown than the reddish brown. However, the clothing of Sun Zu in The Ancient Art of War in the darker screenshot matches his clothing in the EGA screenshot.

Digger is good example, its directly write to cga port than using INT 10H,
thats why it show grabled screen on real EGA/VGA card, yeah i've experience this myself.

Luckyly the cards come with utility to set into CGA operation mode (with optional /reboot for booter-games)

Afaik, digger was designed for cga rgb mode 4, and not the composite monitor, its qutie similar to Dig-Dug afterall...

From reviewing the screenshots above, I would suggest that most developers or porters had the early cards in mind when they designed their graphics for composite video. Shamus and Jungle Hunt are almost too dark to play, and even the tree in Below the Root seems somewhat more appropriate in more orangish brown than the reddish brown. However, the clothing of Sun Zu in The Ancient Art of War in the darker screenshot matches his clothing in the EGA screenshot.

TeaRex wrote:

Are there Games that: […]
Show full quote

Are there Games that:

• 1.) Want to display CGA RGB mode 4 graphics, and
  2.) don't work with machine=ega or another newer type, and
  3.) don't look acceptable with composite rendering?

Probably there are... But if not, composite mode could simply be made the default for machine=cga and mode 4, no? Or would that break too much precedent?

I think Dig Dug is a good example of a game that satisfies 1 & 3 and maybe even 2. For that, why not use machine=tandy, since that does not support composite video at all. Of course, if the game supports Tandy 16-color graphics, then you would not get CGA 4 color. I am sure there are many games that simply do not display as well in composite but utilize CGA in some way incompatible with EGA and VGA.

nikiniki wrote:

Is it worth to make a patch then?

Why not? It would be really nice to have this in official builds, but if it's not accepted, that's what open-source is for. Unofficial builds (ykhwong's, etc) could benefit as well.

reenigne wrote:

Perhaps a good compromise would be a "composite=yes|no|auto" switch in the config file with "auto" (the current behaviour) being the default. This would allow users to force composite decoding to be enabled or disabled, and I think that would make almost everybody happy. If that patch would be accepted I'll even volunteer to write it myself.

Another approach would be to keep the current "auto" behavior, but add a keymapper event to toggle composite decoding on and off at will. This would auto-detect composite output in mode 6, the same as now; in mode 4, you'd only need to hit a key to switch to the composite monitor.

That would keep the UI as simple as possible, and could also work on top of a config file setting as you suggest.

TeaRex wrote:

Are there Games that: […]
Show full quote

Are there Games that:

1.) Want to display CGA RGB mode 4 graphics, and
2.) don't work with machine=ega or another newer type, and
3.) don't look acceptable with composite rendering?

Probably there are... But if not, composite mode could simply be made the default for machine=cga and mode 4, no? Or would that break too much precedent?

Plenty - any game that writes directly to CGA registers won't work correctly with another machine type (e.g. Digger), and most games that were made for RGB monitors won't look as good on composite displays. Forcing it as default definitely wouldn't be the right approach.

Great Hierophant wrote:

From reviewing the screenshots above, I would suggest that most developers or porters had the early cards in mind when they designed their graphics for composite video. Shamus and Jungle Hunt are almost too dark to play, and even the tree in Below the Root seems somewhat more appropriate in more orangish brown than the reddish brown. However, the clothing of Sun Zu in The Ancient Art of War in the darker screenshot matches his clothing in the EGA screenshot.

The images in the last set I posted were all generated with the "new CGA" code - gamma is the only difference between the light and dark variations. Gamma correction applies to the "old CGA" code as well.

See the attached comparison for Below The Root:
first row = old CGA
second row = new CGA
left column = gamma correction off
right column = gamma correction on

I like the last picture because it's most like screen 3 on PCjr in Basic.

I'm working on a game with CGA Composite in mind.

I want to be sure the colour would be fine with the game.

Since Dosbox has different colour in cga composite, making games like this could be a problem.

@nikiniki: if you stick to mode 6 in white, DOSBox's current colors are not very different from the proposed new implementation (see the Tapper comparison on the previous page).
Looks nice, by the way!

DOSBox used to get by with a humble machine=vga config setting, and now it has several VGA machine sub-types to choose from. With that in mind, and that Qbix wrote "at the moment", I think that a separate machine setting is not permanently off the table. But in any case, how RGB or composite output is selected is such a minor piece of the overall development puzzle that it can be decided after the fait accompli of functional composite output for lo-res CGA graphics.

I suggest using a separate machine type, at least initially, because it's very straightforward; and then focusing on the hard part of drawing. I think it's possible to continue using the current approach of a pre-calculated palette (calculated when there are palette or background color register writes) for speed, but the proposed algorithm obviously needs significant refactoring for that.

In the current Dosbox CGA composite, there are 3 viersons of green and no darker gray.

Is it suppose to do that on mode 6?