NewRisingSun wrote:

Like VileRancour, I'm still having trouble getting some color combinations right in 320x200 mode with new CGA and PCjr (i.e. Adventure in Serenia). Has anyone ever checked what the actual resistor values built on the card for R/G/B are? I know the ones from the logic diagrams, but maybe they didn't follow them too closely.

There's a high resolution image of a 1501981 card at http://www.yjfy.com/images/oldhard/video/1501981XM.jpg - that has the same resistor values as the logic diagram.

See if you can get it to look right by tweaking the values in the phases array and pixel_clock_delay, since those are the parameters that are the most suspect.

As with the PCjr, any remaining differences could be due to the exact times that one pixel ends and the next one starts depending on the colours of the before and after transitions. In any given 2bpp mode, there are 12 possible transitions and two variables (end of old pixel and start of new pixel) for each transition, so 24 possible values to adjust.

I played around with resistor values and angles for direct colors. Nothing got me come closer to the captures. Changing the pixel clock delay made some colors look right and others wrong.

Then I output, for testing purposes, just the artifact color part of 320x200 graphics with chroma color amplitude set to zero to see what the "pure artifact color" at that screen position would be. I realized that any time there is a color error, the color is too close to the artifact color. Hence I conclude that the problem lies with the chroma amplitude of direct colors.

It would be great if one could capture the CGA output with no NTSC demodulation, that is, setting the CGA's color burst ON (otherwise there'll be no chroma pattern in the output), but making the capturing TV card not decode the chroma, kind of like a black and white TV without color killer circuit would display it.

NewRisingSun wrote:

Then I output, for testing purposes, just the artifact color part of 320x200 graphics with chroma color amplitude set to zero to see what the "pure artifact color" at that screen position would be. I realized that any time there is a color error, the color is too close to the artifact color.

I'm not sure I understand that experiment. You're replacing all the chroma signals with a DC level corresponding to half the chroma amplitude? What does that look like, and how does it prove anything?

NewRisingSun wrote:

Hence I conclude that the problem lies with the chroma amplitude of direct colors.

So can you get better results by changing the chroma amplitude? By how much? The resistors in the image I linked to have a tolerance of 5% which I would think would be too small to make a difference, though I suppose it's possible that the wrong resistor was used in the card you're actually comparing against.

Instead of additional conf settings, a different approach is a Z: drive internal program that only appears for machine types with composite functionality. You could pass it an individual var=value parameter, or several of them at once. I think it would be about as useful as the conf approach because you can change settings from the command line, and also run the program from the [autoexec] section of the conf. Going further you could have a parameter that toggles the mapped function keys on and off for on-the-fly tweaking, and another that displays all of the current settings (especially useful for values changed by function key).

reenigne wrote:

You're replacing all the chroma signals with a DC level corresponding to half the chroma amplitude?

Basically I'm generating the composite signal as if the mono bit in the mode register was set, but I'm still decoding color from it. That way you only get the artifact color from the luma portion of the signal. You can imagine the regular final decoded output as luma plus artifact color plus direct color, and in the experiment I am generating luma plus artifact color, without direct color. Remember that "artifact colors" are luma (mis-) interpreted as chroma.

reenigne wrote:

So can you get better results by changing the chroma amplitude? By how much?

It turns out that the result is much better if I set the chroma amplitude twice as high. Which would indicate that the problem lies more with my algorithm than with any particular idiosyncracy in the CGA. Though I wouldn't know where the factor two would come from.

ripsaw8080 wrote:

Instead of additional conf settings, a different approach is a Z: drive internal program that only appears for machine types with composite functionality. ou could pass it an individual var=value parameter, or several of them at once. I think it would be about as useful as the conf approach because you can change settings from the command line, and also run the program from the [autoexec] section of the conf.

So basically like the MIXER command. That would be acceptable (at least better than having to bang function keys every time), though I still don't understand why the config file is so sacred and untouchable.

NewRisingSun wrote:

It turns out that the result is much better if I set the chroma amplitude twice as high. Which would indicate that the problem lies more with my algorithm than with any particular idiosyncracy in the CGA. Though I wouldn't know where the factor two would come from.

Is your algorithm giving the same results as DOSBox with my patch? Are you generating your sampled chroma signals the same way that I do (a band-limited resample of a square wave)?

If you like I'll take a look at your code and see if I can spot a bug.

Here's the relevant portion for new CGA:

1void    CGA_generateColorNew (int color, double *luma, double *inPhase, double *quadrature, double burst) {
2        double  angle, chroma;
3        /* Color Generation Method used in new model CGA (P/N 1501981) */
4        /* resistors for new CGA according to page 32 in manual 6361509:
5           red          2000 ohm
6           green        1000 ohm
7           blue         3000 ohm
8           video         750 ohm
9           intensity     680 ohm */
10        #define NEW_RED       0.1078224101
11        #define NEW_GREEN     0.2156448203
12        #define NEW_BLUE      0.0718816068
13        #define NEW_VIDEO     0.2875264271
14        #define NEW_INTENSITY 0.3171247357
15        if ((color & 7) == 0) {
16          *luma  = 0.0;
17          chroma = 0.0;
18        } else if ((color & 7) == 7) {
19          *luma =  NEW_VIDEO;
20          chroma = 0.0;
21        } else {
22          *luma  = 0.5 * NEW_VIDEO;
23          chroma = 1.0 * NEW_VIDEO; // was 0.5
24        }       
25        if (color & 4) *luma+= NEW_RED;
26        if (color & 2) *luma+= NEW_GREEN;
27        if (color & 1) *luma+= NEW_BLUE;
28        if (color & 8) *luma+= NEW_INTENSITY;
29        angle = (phases [color] + burst + 180) * PI / 180;
30        *inPhase    = sin (angle) * chroma;
31        *quadrature = cos (angle) * chroma;
32}

The line that says "was 0.5" is the one where the factor two applies (without implying that factor two is necessarily perfect, only that it's better). Since you mentioned the band-limited square wave, does that mean that for my approach, a square root of two would be the correct factor?

NewRisingSun wrote:

I still don't understand why the config file is so sacred and untouchable.

I don't think it's either of those things. In my experience the devs simply prefer to avoid additional conf settings, and that preference is nothing new. Also, there are few (if any) conf settings that are only applicable to certain machine types and useless to others, and that may well be a trend the devs want to continue.

NewRisingSun wrote:

Here's the relevant portion for new CGA

I'm not sure how you even get any artifact colour from that algorithm. Presumably you're taking the generated luma, inPhase and quadrature, combining them and then decoding the signal again? Seems like a bit of a roundabout way to do it...

NewRisingSun wrote:

Since you mentioned the band-limited square wave, does that mean that for my approach, a square root of two would be the correct factor?

Actually, having just done the calculation again by hand, I think the correct factor should be 2/pi or about 0.64 (from the Fourier series of the square wave), if I'm understanding your algorithm correctly. That gives you a sine wave that peaks at 1.14 and -0.14 which is the same as a band-limited square wave that peaks at 1 and 0.

Though, now that I think about it some more, I've convinced myself that this method isn't quite as accurate as I thought it was - the operation of switching from one chroma signal to another happens very rapidly, so working in the post-bandlimited regime as I have been doing is going to result in some leakage of voltage. Consider the case where you have a black pixel (in 2bpp mode) which completely overlaps the high part of the chroma signal. This should give a zero signal, but with my current patch it'll give a signal of about 0.05 for two of the four samples (so it's wrong in this particular case by about 2.5% - it might be wrong by more in other cases).

So now I'm wondering if I can get better results by calculating a waveform at essentially unlimited bandwidth - i.e. instead of keeping track of sample values at evenly spaced intervals, keep track of a set of (time, value) coordinate pairs and then integrate that to get the samples (the same way I created the chroma_signals array in my earlier patch). This method would also make it possible for pixels' start and end times to depend on their colours.

I'll have a go at making a patch later to see if it makes any difference.

reenigne wrote:

I'm not sure how you even get any artifact colour from that algorithm.

Well, that part quite obviously only generates the luma and color-difference signals for a direct color.

reenigne wrote:

Presumably you're taking the generated luma, inPhase and quadrature, combining them and then decoding the signal again? Seems like a bit of a roundabout way to do it...

It's not "roundabout", it's called modular design. 😒 Keeping the composite signal generation and the decoding separate allows me to reuse the decoding portion for other signal sources such as Apple II or NES.

I have tried the 1.28 factor, and am now able to replicate all results for new CGA and Tandy across the board. I have never seen old CGA captures, so I don't know for sure about it. As for PCjr, the issues presented by VileRancour remain. I suggest obtaining the logic diagrams for the PCjr to see if the resistors might be different from the new CGA. The only scan of the technical reference manual that I have been able to find unfortunately omits the logic diagrams.

ripsaw8080 wrote:

NewRisingSun wrote:

I still don't understand why the config file is so sacred and untouchable.

I don't think it's either of those things. In my experience the devs simply prefer to avoid additional conf settings, and that preference is nothing new. Also, there are few (if any) conf settings that are only applicable to certain machine types and useless to others, and that may well be a trend the devs want to continue.

This is correct.

reenigne wrote:

Oh, fascinating! So the color burst phase relative to the pixel clock is completely different for the three machines PCjr, CGA and Tandy 1000.

That explains the inability to make the Below The Root title screen look right - because the hues of the artifact colours are shifted relative to the hues of the chroma colours, no hue shift will do the job - it needs a change to pixel_clock_delay.

I'll have a go at porting my chart.com program to PCjr but I don't have a PCjr so it might take me a few iterations to get it right.

I'd just like to point out that the only practical target system for composite CGA graphics was the original IBM PC CGA. It's nice that all systems are being considered, but they were never targeted in the real world.

The only reason that Blue Angels' composite graphics are hue-rotated is because they developed and tested on Tandy 1000 machines, which were a very common clone in the late 1980s in Canada. They probably had no idea their graphics would look goofy on non-Tandys.

I just want to make sure that people aren't getting fixated on proper emulation of every single variant -- if it's easy to do so, great, but IBM CGA is really the only practical target.

NewRisingSun wrote:

It's not "roundabout", it's called modular design. 😒 Keeping the composite signal generation and the decoding separate allows me to reuse the decoding portion for other signal sources such as Apple II or NES.

Sorry, didn't mean to come across so critically. But I'd have thought the obvious way to do that would be for each video system simulator to generate a single composite signal sampled at 14.318MHz, and then have a resuable decoder that accepts that - just the same way that real hardware works.

NewRisingSun wrote:

I have never seen old CGA captures, so I don't know for sure about it.

I do actually have an old CGA and a capture card, so I'll have a go at creating some.

NewRisingSun wrote:

As for PCjr, the issues presented by VileRancour remain. I suggest obtaining the logic diagrams for the PCjr to see if the resistors might be different from the new CGA. The only scan of the technical reference manual that I have been able to find unfortunately omits the logic diagrams.

http://www.oldskool.org/guides/tvdog/documents.html has one in jrtech.zip - that shows the resistors to be similar to the new CGA ones but the R, G, B and I ones are 10% higher (2.2K, 1.1K, 3.3K and 750 ohms respectively as opposed to 2K, 1K, 3K and 680 ohms for the new CGA). Chroma and sync remain at 750 ohms and 680 ohms respectively. Hopefully that accounts for the discrepancy.

Qbix wrote:

ripsaw8080 wrote:

NewRisingSun wrote:

I still don't understand why the config file is so sacred and untouchable.

I don't think it's either of those things. In my experience the devs simply prefer to avoid additional conf settings, and that preference is nothing new. Also, there are few (if any) conf settings that are only applicable to certain machine types and useless to others, and that may well be a trend the devs want to continue.

This is correct.

Qbix just wants to keep dosbox as simple as possible cause the more complicated it is the more email flood asking for help he receives. And it is he not you who has to handle it 😀

MobyGamer wrote:

It's nice that all systems are being considered, but they were never targeted in the real world.

I don't think that most developers were even aware that there are several CGA revisions with the difference being in the composite video encoder. So those two are essential, because games can be found that target either one of them. PCjr composite emulation is necessary if you want "Below the Root" with proper display and three-channel sound, and supporting the Tandy 1000's composite video is just a matter of changing two numbers. And besides, I think it's kind of fun! 😀

robertmo wrote:

Qbix just wants to keep dosbox as simple as possible cause the more complicated it is the more email flood asking for help he receives.

Getting more complicated is invariably the result of adding more features. Among the alternatives presented --- adding a few config file options, adding another Z-drive program, and adding yet more things to the key mapper, the config file alternative still is the least intrusive to the overall logic of the emulator, and the one likely to generate the least amount of help requests, being the most intuitive.

reenigne wrote:

But I'd have thought the obvious way to do that would be for each video system simulator to generate a single composite signal sampled at 14.318MHz, and then have a reusable decoder that accepts that - just the same way that real hardware works.

That is what I am doing. But I'm also splitting up the composite signal generation into several logical steps to be as flexible as possible. For example, by keeping the generation of YIQ signals for the direct colors separate from combining them into one composite signal, I can add S-Video support, or view just the artifact colors without the direct colors, as I explained before, which gave me the insight into where my algorithm was wrong. I have also added an alternative "ideal NTSC" encoder just to see how good the CGA's signal could have been. Basically, you could say my program is more for research than for actual emulation purposes, which is also why it's a lot slower.

reenigne wrote:

(2.2K, 1.1K, 3.3K and 750 ohms respectively as opposed to 2K, 1K, 3K and 680 ohms for the new CGA). Chroma and sync remain at 750 ohms and 680 ohms respectively. Hopefully that accounts for the discrepancy.

Those are the same resistor values as in the Tandy 1000. Unfortunately it does nothing to alleviate the discrepancy.

This is as good as I can get it. It turns out that changing saturation does more to change perceived hues --- because higher saturation causes colors to clip and thus shifts the hue --- than any resistor differences. I suspect that the algorithm is basically correct and remaining differences are due to saturation, black level and luma filtering differences --- remember than we're basically normalizing video levels by just defining CGA's black as RGB #00000 and CGA's white as RGB #FFFFFF. That's obviously not what a real TV or capture card does, and those video level differences alone will cause slight changes whenever red/green/blue is clipped at 0 or 1.

Is there a reason that we couldn't have machine= settings like cgargb, cgaold, cganew, pcjr, tandy? Or maybe have a single keybind (and Z:\ command or environment variable) that does the following:
- switches between rgb and composite for non-CGA machine modes and
- cycles among rgb, cgaold and cganew for machine=cga?

A config option makes the most sense because to me personally, because this is the way I think about config options versus Z:\ utilities:
- config options are best for choosing hardware emulation settings that aren't likely to change during a DOSBox session (e.g. which type of emulated CGA hardware and/or monitor is to be used)
- Z:\ fake programs or fake environment variables are best for emulation settings that should be able to be changed programmatically (via .BAT files or dosbox.conf autoexec section) during a DOSBox session (possibly cgaold versus cganew and maybe tint/saturation/brightness)
- hotkeys for settings that the user would want to tweak while a game is running (things like tint/saturation/brightness I suppose, like on a real composite monitor)

HunterZ wrote:

Is there a reason that we couldn't have machine= settings like cgargb, cgaold, cganew, pcjr, tandy?

That would make all existing config files that have a simple "machine=cga" obsolete. Making existing config files obsolete is what would cause the most complaints from users.

The user-friendly approach would be that when presented with an existing config file that makes no mention of the new options, a future DosBox version will behave exactly as the previous one; the new features are activated by adding the new options to existing config files. Which is why I like VileRancour's config patch, because as far as I can tell, that's exactly what it does.

Obviously you would have to keep a machine=cga that defaults to whatever is the closest to the current official release behavior, but it would be considered deprecated.

I'm certainly fine with VileRancour's approach (in fact I would probably prefer it myself), but I thought I'd throw out a more conservative idea since it sounds like the DOSBox devs aren't too keen on adding lots of extra config settings to the official releases.

NewRisingSun wrote:

the new features are activated by adding the new options to existing config files.

That's not the way the conf file works. Settings omitted from the conf use their default value, settings included in the conf override their default value. All settings are written when you use the "config -writeconf" command.

I think the most user-friendly approach, and also the one more likely to be looked at favorably by the devs, is to use default settings that work fine for most games and provide an unobtrusive way to change settings for the few games that need it and for users that are inclined to do so. It is important to remember that many users "just want it to work."