robertmo wrote:

Take any game with red/blue/white palette and you will see. For example quest for the timebird.

How many have you tried? SubLogic Jet in RGB mode, Avoid the Noid, Popcorn -- they use mode 5 and don't change background color with F10/Alt-F10 like Quest for the Time-Bird does. In Popcorn F10 is the Boss Key, with a fake spreadsheet (in French). 😉

i tried also north & south, but now i notice not every n&s version does that 😉

BTW updated the chart

BTW troll's tale has at the beginning some fun with colors - hit space to see green - but on the pcjr blue appears (green is on cga only). I wonder why. Does it mean cga version was first and later ported to pcjr?

VileRancour wrote:

nikiniki wrote:

Tried Rambo 3 on pcjr mode with CGA mono: - You can hear the song but the screen is black. […]
Show full quote

Tried Rambo 3 on pcjr mode with CGA mono:
- You can hear the song but the screen is black.

Space Quest 3 on Pcjr using cga 2 colors
- Dosbox freezes

On real PCjr, both games run fine.

Strange enough, Qbasic and Basica seem to work, using Screen 2.
PcGammon works on PCjr mode on Dosbox too.

Isn't a bit off topic with PCjr emulate problem?

Might want to make a new thread in the development forum. Better chance of getting it noticed, and since you tested on a real PCjr, that would be useful.

Done: Mode 6 on PCjr issues

VileRancour wrote:

2. In mode 4 the colors are changed as well, but again the change is almost imperceptible with cga=new and very apparent with cga=old. See attached image - in particular, some of the blue shades in this specific palette are now green.
If there's a game that uses these colors for e.g. sky or water, that could hint at which card type it was targeting... can't think of one off the top of my head (looks like the cyan-magenta palette was far more common), but could be useful for testing.

Can brown salad be a proof of that too? Why to choose brown when you have dark green in the same palette?

ripsaw8080 wrote:

I was referring to the high-contrast single-pixel transitions, such as on the leading and trailing edges of the wings. In the KQ1 booter most of the transitions from one solid color to another are at least a couple of pixels wide. No doubt it's more noticeable with the sharp pixels of a digital flat panel display than the smeary scanlines of an old CRT; so applying a bit of blur might help.

I see now - yes, I agree. This is something else that using a (1,4,7,8,7,4,1) kernel would help with. I think that would be quite easy to do with the 640x200 mode (it would need 128 palette entries) but more difficult with 320x200 (the same technique would need 512).

ripsaw8080 wrote:

BTW, a 135 degree hue offset for Blue Angels in DOSBox's current composite algorithm has similar colors to a 230 degree offset in your algorithm. Is there a different scale?

It seems the direction of the hue offset has somehow got switched around, so Tandy 1000 games need a -120 degree offset now. I can't believe I never noticed that!

robertmo wrote:

reenigne wrote:

robertmo wrote:

Looks like another not configurable game:
I, Damiano: The Wizard of Partestrada

I mean that this game doesn't look ok in like any hue setting, but maybe the hue 0 is the right one... (Similarly to Boulder Dash 2, Donkey Kong and Turbo Champions)

Not sure what that author was trying to do: in the beginning location there are two areas which alternate between black and magenta but in the Apple II version those areas are not the same colour (one is black and one is orange) so there's no way it looks the same as the Apple II version on any hardware.

robertmo wrote:

Can brown salad be a proof of that too? Why to choose brown when you have dark green in the same palette?

Burger Time was a 1982 release, so it's safe to say it was geared for the "old" CGA type, which actually shows this color as closer to brown. No idea why they did that... maybe the "other" dark green was too dark on the display they were using.

reenigne wrote:

I see now - yes, I agree. This is something else that using a (1,4,7,8,7,4,1) kernel would help with. I think that would be quite easy to do with the 640x200 mode (it would need 128 palette entries) but more difficult with 320x200 (the same technique would need 512).

Comparing with this - http://www.mobygames.com/game/dos/blue-angels … meShotId,32947/
Here the same clashing transitional pixels are visible, just wider and slightly less prominent due to the smear effect. I don't think the difference is all that huge, but that's just my subjective take.

reenigne wrote:

robertmo wrote:

I mean that this game doesn't look ok in like any hue setting, but maybe the hue 0 is the right one... (Similarly to Boulder Dash 2, Donkey Kong and Turbo Champions)

Not sure what that author was trying to do: in the beginning location there are two areas which alternate between black and magenta but in the Apple II version those areas are not the same colour (one is black and one is orange) so there's no way it looks the same as the Apple II version on any hardware.

I guess it's just another false positive, like the other games mentioned (uses mode 4 and has vertical stripe patterns, but evidently meant for RGB).

By the way, regarding my comment from the previous page, about the changed colors: I just compared that 16rows screenshot with your TV photo for reference (the 0A10 one), and for what it's worth, colors 1 and 3 look more blueish than greenish - closer to the old (delay-less) algorithm than the new one. Don't know how significant that is, though.

ripsaw8080 wrote:

In Popcorn F10 is the Boss Key, with a fake spreadsheet (in French). 😉

the French sure love their F10 boss keys, it seems - Prohibition does the same, except that the music keeps playing (unless you turn it off with F1). 🤣

reenigne wrote:

because of the reduced chroma amplitude in the new card there's almost no relative delay between the pixel clock and the chroma signals, so the two cards do differ in hue by about 13 degrees.

Why is the delay a function of the chroma amplitude?

NewRisingSun wrote:

reenigne wrote:

because of the reduced chroma amplitude in the new card there's almost no relative delay between the pixel clock and the chroma signals, so the two cards do differ in hue by about 13 degrees.

Why is the delay a function of the chroma amplitude?

Because the final output signal is a weighted sum of the chroma and +I (intensity) signals (and, for new CGA cards, the +R, +G and +B signals as well) and these signals have different delays.

For mode 6 palette 15, the chroma signal has a delay of 39.5ns, the +R, +G, +B and +I signals have delays of 15.5ns and the color burst has a delay of 21.5ns.

For old CGA, the chroma amplitude is 0.72 and the RGBI amplitude is 0.28, giving a final relative delay of 39.5ns*0.72+15.5ns*0.28-21.5ns = 11.28ns = 14.6 degrees.

For new CGA, the chroma amplitude is 0.29 and the RGBI amplitude is 0.71, giving a final relative delay of 39.5ns*0.29+15.5ns*0.71-21.5ns = 0.96ns = 1.2 degrees.

Oh, we calculated the same amplitude values independently of each other. I am so proud of myself.

By the way, I have a Tandy 1000 TX on which I can do some tests, if desired.

reenigne wrote:

Because the final output signal is a weighted sum of the chroma and +I (intensity) signals (and, for new CGA cards, the +R, +G and +B signals as well) and these signals have different delays.

But it is the voltages of the respective signals that are weighed, not the delays. Or why does one automatically imply the other?

NewRisingSun wrote:

By the way, I have a Tandy 1000 TX on which I can do some tests, if desired.

Oh, awesome! Can you try running http://www.reenigne.org/misc/chart.com on it and take pictures of the results? (It cycles through all 8 possible CGA mode/palette combinations on a keypress.) It would be good to get another datapoint about what Blue Angels looks like as well (I think Servo's screenshot was taken using CGA cardware with a hue shift, but it might look different on an actual Tandy).

NewRisingSun wrote:

But it is the voltages of the respective signals that are weighed, not the delays. Or why does one automatically imply the other?

It's an approximation valid for small angles. The actual formula is a*sin(x+b)+c*sin(x+d) = A*sin(x+atan(((a*sin(b)+c*sin(d))/(a*cos(b)+c*cos(d)))) for some amplitude A but if b and d are small (as they are here) then sin(b) ~= b, cos(b) ~= 1 and atan(b) ~= b so that gives (a*b+c*d)/(a+c) for the phase.

You will notice that my Sony TV doesn't show the monochrome modes as monochrome. That may either be the fault of the Sony TV, or there's some 3.58 MHz signal leakage in the Tandy's composite output, which the TV takes as a very weak color burst signal.

And as you can tell, this TV has no comb filter, either. 😀

Anyway, for what it's worth, here goes. These pictures turned out a lot worse than I hoped. I will repost better versions once I either get a proper camera or figure out how to disable automatic brightness. Apart from being too bright, the hues are reproduced accurately though.

NewRisingSun wrote:

How about variations in the color burst amplitude? 😀

I couldn't get my sync separator IC working properly, so I ended up doing some minor surgery on my CGA card's composite output resistors, replacing them with pots.

NewRisingSun wrote:

I'm quoting from SMPTE-170M: "A gated and filtered signal derived from subcarrier, called the burst, shall be added in the horizontal blanking interval of each line, excluding the nine-line vertical sync interval, as a synchronizing signal and amplitude reference for the chrominance signals. The burst signal shall be inverted in phase from the reference subcarrier."

My TV does use the color burst amplitude as an amplitude reference, but not just for saturation purposes - it uses it to normalize the gain for the entire signal. So when I change the value of the chroma resistor it (for most of the range) has no effect on the chroma colours 1-6 at all (since the ratio between their amplitude and the color burst amplitude is a constant - i.e. 1). But increasing the color burst amplitude does make the luma colours darker (by luma colours I mean those you see in mode 6 palette 😎. Since they're darker they're also lower saturation (lower amplitude). And decreasing the color burst amplitude makes the luma colours brighter.

I tried the same experiment with a capture card and saw the same thing.

So that explains why I needed to turn the brightness and contrast right up on my TV to be able to see all the different colours in my chart properly - the chroma signal is much higher than NTSC spec (by a factor of about 2.6 - which explains why they reduced it by a factor of about 2.5 in the new CGA card) so my picture was too dark by that same factor. Of course, when you correct for that by turning up the contast you are essentially also turning up the saturation as well (the entire signal is multiplied by the contrast value) so you never see colours getting closer to grey as the result of the color burst amplitude being too high (unless you have some weird TV where increasing the contrast reduces the saturation by the same amount to keep the color amplitudes the same).

Nevertheless, I think we do want to do something about the high saturation in DOSBox - clearly real TVs don't behave the way that DOSBox is behaving at the moment. Look at the difference between the two blues in the title screen aeroplanes in Blue Angels, when the hue is set to -135 degrees. In your picture, the lighter one is definitely lighter but in DOSBox the hues are almost indistinguishable due to the clipping against the sides of the RGB colour cube. Reducing the saturation fixes this.

It would be nice to have a saturation control similar to the current hue control. From the point of view of the decoding algorithm this change would be very easy - just multiply I and Q by the saturation value. The problem is what keys can we assign to them? The same applies to brightness and contrast.

If there's too much resistance to adding a saturation control, I'd be happy with just hard-coding a lower saturation than we currently have. Just as we currently implicitly set the brightness and contrast to values which make black come out as black and white come out as white, we could also implicitly set the saturation to make the colours not clip (too much).

You can make it this way:
f12 - toggles emulated monitor type (composite, rgb, auto)
f11 - toggles hue/brightness/contrast/saturation/cgaversion
ctrl-alt-f11/ctrl-alt-12 - adjusts what was chosen by f12

(as alt-f11/f11 the way it is now is hard to tell which option goes which direction without actually pressing the key at least twice to see the results)

This would also allow adding some more options in the future (pallette change/background color change or sth else). And leaves alt-F11 free for sth else.

What are the exact disadvantages of not having control of saturation (also brightness and contrast)?

reenigne wrote:

My TV does use the color burst amplitude as an amplitude reference, but not just for saturation purposes - it uses it to normalize the gain for the entire signal

That's what I found, too. Because the Tandy outputs the same too low burst amplitude as the new CGA, the TV amplifies the signal like crazy, making the intensity colors all white, unless I turn down the contrast to its minimum.

Check again with an RF-modulated signal. There, because of negative modulation, the sync tip should be used as a reference for the composite signal amplitude, and the color burst amplitude should either affect nothing or only saturation.

reenigne wrote:

(by a factor of about 2.6 - which explains why they reduced it by a factor of about 2.5 in the new CGA card)

In the old CGA, burst is too large, so saturation (or composite) should be reduced to 56% of the original. In the new CGA, it is too small, so saturation should be increased to 143% of the original, making mode 6 games extremely oversaturated.

reenigne wrote:

by turning up the contast you are essentially also turning up the saturation as well (the entire signal is multiplied by the contrast value)

The problem is that saturation is a quadratic, not linear, function of the composite signal. But on my TV, the contrast control changes only the amplitude of the final RGB signals, not the input signal, so saturation stays constant throughout all contrast levels.
.

reenigne wrote:

In your picture, the lighter one is definitely lighter

The problem is that it's oversaturated on the TV as well, for the reason stated above. It's just that the TV has a strange way of dealing with oversaturation, doing something different than just clipping as we do. Although I have to say that the picture exaggerates the difference between the lighter blues and the darker blues, although in reality it's definitely more pronounced than in DosBox.

reenigne wrote:

when the hue is set to -135 degrees.

I'm not sure that the difference is really 135 degrees for all modes. It seems to be that it's 135 degrees for mode 6 (I'm not sure where the 15 degrees delay go here) but 315 degrees for mode 4. That's what I have to do to get my algorithm to look like the Tandy.

reenigne wrote:

If there's too much resistance to adding a saturation control, I'd be happy with just hard-coding a lower saturation than we currently have.

I'm against a saturation control as well; the algorithm should bring it to reasonable levels by itself. That means for mode 6 games, existing saturation should just be reduced to 56% regardless of CGA setting, then the NTSC-to-709 transformation applied. For mode 4 games, I'm less certain, but I tend to favor taking the unadjusted old CGA amplitudes.

A very nice example of a game designed for old cga
http://www.mobygames.com/game/sorcerer-of-cla … eCoverId,91255/

VileRancour wrote:

2. In mode 4 the colors are changed as well, but again the change is almost imperceptible with cga=new and very apparent with cga=old. See attached image - in particular, some of the blue shades in this specific palette are now green.
If there's a game that uses these colors for e.g. sky or water, that could hint at which card type it was targeting... can't think of one off the top of my head (looks like the cyan-magenta palette was far more common), but could be useful for testing.

That was a very good tip 😀
http://www.mobygames.com/game/c64/tournament- … eShotId,259537/

robertmo wrote:

You can make it this way: f12 - toggles emulated monitor type (composite, rgb, auto) f11 - toggles hue/brightness/contrast/satur […]
Show full quote

You can make it this way:
f12 - toggles emulated monitor type (composite, rgb, auto)
f11 - toggles hue/brightness/contrast/saturation/cgaversion
ctrl-alt-f11/ctrl-alt-12 - adjusts what was chosen by f12

(as alt-f11/f11 the way it is now is hard to tell which option goes which direction without actually pressing the key at least twice to see the results)

This would also allow adding some more options in the future (pallette change/background color change or sth else). And leaves alt-F11 free for sth else.

That's a pretty good solution.

NewRisingSun wrote:

Check again with an RF-modulated signal. There, because of negative modulation, the sync tip should be used as a reference for the composite signal amplitude, and the color burst amplitude should either affect nothing or only saturation.

I don't have an RF modulator at the moment so I don't have an easy way to do that. How does the TV know whether to use composite or RF mode? Or does it go by which input is selected?

NewRisingSun wrote:

In the old CGA, burst is too large, so saturation (or composite) should be reduced to 56% of the original. In the new CGA, it is too small, so saturation should be increased to 143% of the original, making mode 6 games extremely oversaturated.

Don't forget that the color burst signal generated by the CGA card is a square wave and not the NTSC standard sine wave, so there's an additional factor of sqrt(2).

NewRisingSun wrote:

The problem is that saturation is a quadratic, not linear, function of the composite signal.

What do you mean by that?

NewRisingSun wrote:

But on my TV, the contrast control changes only the amplitude of the final RGB signals, not the input signal, so saturation stays constant throughout all contrast levels.

It amounts to the same thing. Consider a dark yellow, RGB (0.5, 0.5, 0). That has a peak-to-peak saturation of 0.5. When you adjust the contrast control to multiply by 2 and get RGB (1, 1, 0) the peak-to-peak saturation becomes 1. If you define saturation to be what I'm calling the peak-to-peak saturation divided by the luma then yes, adjusting the contrast won't affect the saturation but the gain normalization done by the TV to correct for the color burst amplitude won't either.

NewRisingSun wrote:

The problem is that it's oversaturated on the TV as well, for the reason stated above. It's just that the TV has a strange way of dealing with oversaturation, doing something different than just clipping as we do.

Agreed. It could be mapping to some kind of curve which levels off as it approaches the limits, or there could be leakage into other channels when the RGB values are too high or low.

NewRisingSun wrote:

I'm not sure that the difference is really 135 degrees for all modes. It seems to be that it's 135 degrees for mode 6 (I'm not sure where the 15 degrees delay go here) but 315 degrees for mode 4. That's what I have to do to get my algorithm to look like the Tandy.

That's because it's just the artifact colours that are different on a Tandy - the direct/chroma colours are the same so when both are used (as in mode 4) the offset will be different for different colours. To get Tandy colours with my patch, you'd need to adjust pixel_clock_delay by 135 instead of hue_adjust.

NewRisingSun wrote:

That means for mode 6 games, existing saturation should just be reduced to 56% regardless of CGA setting, then the NTSC-to-709 transformation applied. For mode 4 games, I'm less certain, but I tend to favor taking the unadjusted old CGA amplitudes.

I strongly feel that whatever saturation correction we apply it should be the same for all modes. After all, no real monitor knows which mode the CGA card is running in.

reenigne wrote:

I strongly feel that whatever saturation correction we apply it should be the same for all modes. After all, no real monitor knows which mode the CGA card is running in.

The aim of dosbox is to be most userfriendly (not reproducing as much real tweaks needed to play a game). Hence we don't have to tweak autoexec.bat and config.sys memory/driver settings, auto composite option, etc. The only reason for introducing tweaks in dosbox is when it is not possible to do it simple (auto) way. That is why if it is possible to make saturation proper for games without any disadvantages of it, it should be done the userfriendly way.
I think a notification in dosbox status window could be appearing informing how much saturation was lowered/highered, etc. Of course manual adjustments could still be provided. So that someone could correct the auto if he doesn't like it 😉 or for some other reasons.

robertmo wrote:

tennis_new_old.PNG

Nice find... so there's at least one game that's obviously tailored for "new" CGA.

robertmo wrote:

You can make it this way: f12 - toggles emulated monitor type (composite, rgb, auto) f11 - toggles hue/brightness/contrast/satur […]
Show full quote

You can make it this way:
f12 - toggles emulated monitor type (composite, rgb, auto)
f11 - toggles hue/brightness/contrast/saturation/cgaversion
ctrl-alt-f11/ctrl-alt-12 - adjusts what was chosen by f12

(as alt-f11/f11 the way it is now is hard to tell which option goes which direction without actually pressing the key at least twice to see the results)

The idea sounds great in principle, but I don't know if such a scheme would be user-friendly enough for most people. F11/alt-F11 do give feedback on the console window; I usually run DOSBox fullscreen so the console isn't visible, but for now these keys only control a single property (hue_offset) so it's not too confusing.
If we let F11 cycle through the various adjustable parameters, that's an additional state change that the user has to remember, and can be disorienting without clear visual feedback (for some considerations on this see http://en.wikipedia.org/wiki/Mode_%28computer … %29#Mode_errors)

Ideally we'd just pop out some kind of GUI box with sliders and switches for all the adjustable properties, like some other emulators have (thinking of the old CCS64 here). But DOSBox doesn't have the infrastructure for that, so that's too much of a stretch.

We just need to find a balance between ease-of-use and flexibility. For what it's worth, my thoughts are:

• CGA type (new/old): doesn't have to be adjustable in real-time, although that's nice for testing. A config property would do for this, especially if it's "Changeable::Always".
• Brightness/contrast: I don't know if we really have to introduce these parameters, unless we can find a game that justifies it. Most games tested so far look good enough without these controls. RGB monitors have adjustable brightness and contrast too, and DOSBox is still doing fine without them in EGA/VGA/tandy/etc. modes.
• Saturation: for "new" CGA, saturation can probably be left at 100%... for "old" CGA, a hard-coded value sounds fine to me, as long as it gives a happy medium in all modes (reduces clipping to an acceptable level, without desaturating unclipped colors too much).

robertmo wrote:

That is why if it is possible to make saturation proper for games without any disadvantages of it, it should be done the userfriendly way.

If there were any evidence that it was standard practice to set the saturation one way for mode 4 games and another way for mode 6 games, I would agree with you, but I haven't seen any such evidence. Even more so than with hue, it's a subjective question as to what saturation is "correct" and most if not all software will look perfectly reasonable across a large range of saturating settings. So I think any kind of automatic changing of the saturation is likely to cause more problems than it solves - while it might improve the picture for one particular game, it would make another correspondingly worse (much like the -15 degree hue shift on port 0x3d9 bit 5 hack).