robertmo wrote:

Dosbox doesn't support mode 6 on pcjr/tandy But is supports mode 4 on pcjr? Notice red blue artifacts on white letters. […]
Show full quote

Dosbox doesn't support mode 6 on pcjr/tandy
But is supports mode 4 on pcjr? Notice red blue artifacts on white letters.

This isn't composite artifacting... looks like the result of doing a 2bpp write of the font data, while the current mode is 4bpp: two adjacent 320x200 pixels are reinterpreted as one 160x200 pixel with a new color. It's a pure RGB effect - same as the one discussed above ("false positive" vertical striping), only in reverse.

@reenigne: the patch looks very promising! Will do some testing and report back later on.

that yellow grass is cause of that saturation?

No, it's because of brightness. As I wrote before, that golf game needs its brightness reduced dramatically.

robertmo wrote:

VileRancour wrote:

You can see the same thing in later games that supported Tandy/EGA (like Turbo Champions or Shogun)... all graphics are stored as 16 color data, and the CGA mode just shows them as 16 pixel patterns. This shows as vertical lines on RGB monitors, but on composite displays the colors don't make sense at all... Shogun's CGA mode even uses the cyan-red-white palette (burst off), so a composite picture would lack any color.

Actually shogun uses slightly different modes 😉

Shouldn't ega/vga be pink not red? Alghough it is autodetection so maybe it detects ega/vga and chooses different palette for it.

I wonder how would it look if we hacked these games like: Turbo Champions, Boulder Dash 2, Donkey Kong into other modes? I wonder if they would look OK in one of them like Shogun.

robertmo wrote:

Dosbox doesn't support mode 6 on pcjr/tandy
But is supports mode 4 on pcjr? Notice red blue artifacts on white letters.

I can confim that.

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?

NewRisingSun wrote:

that yellow grass is cause of that saturation?

No, it's because of brightness. As I wrote before, that golf game needs its brightness reduced dramatically.

Does it mean we need brightness (in addition to hue) control in dosbox?

I've noticed alt-f10/f10 switches background color/intensity. But why only in red/blue/white mode?

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

I noticed a minor bug in the way I'm computing the zero point of hue. The line:

1	double hue_adjust = (-(45-22.5+33)+hue_offset+pixel_clock_delay)*tau/360.0;

should read:

1	double hue_adjust = (-(90-33)+hue_offset+pixel_clock_delay)*tau/360.0;

The previous cga2ntsc/composite_test code has a similar bug. Instead of:

1	double hue_adjust = (-(45+33)+hue_offset)*0.017453292519943;

it should have:

1	double hue_adjust = (-(112.5-33)+hue_offset)*0.017453292519943;

The hue was only off by 1.5 degrees, so the difference isn't really visible but I wanted to match the standard.

reenigne wrote:

Here's my "160 colour" patch so far. I realized that it actually only uses at most 64 distinct colours in 2bpp modes, so with a bit more work it might be possible to use a (1,4,7,8,7,4,1) kernel instead of the (1,1,1,1) one - this would smooth out the edges of some of the colour transitions a bit.

I don't know if I dislike the "blockier" colored edges (more apparent in mode 6 vs. the old technique). I think they stand out since I'm looking at scaled-up pixels on a flat-panel monitor, rather than a 200-line CRT, but otherwise not that bad. Would be neat to have this patch in one of the D3D-enhanced builds down the line, and use it with the CRT pixel shader.

I added new/old CGA card selection to the config file, but I haven't tried out the new CGA card yet.

I've incorporated all the logic delays that I can sensibly model. The delays for 2bpp aren't quite as sophisticated as those for 1bpp, but they're as accurate as I can manage within the confines of a paletted algorithm.

Using robertmo's patched build (that is, without the minor 1.5-degree correction from your last post) - a few things I've noticed so far:

1. In mode 6 / white foreground, there's now a distinct difference between the new and old CGA types: with cga=new, colors are the same as in the previous patch or cga2ntsc; with cga=old, the hue once again looks like it does in upatched DOSBox, i.e. 15 degrees away. Essentially the same effect as the -15 degree hack in current SVN.
Assuming that this is a result of your added logic delays, it might explain something about the clone card which inspired that hack - perhaps it was a "new"-type card that used port 0x3d9 bit 5 to trigger "old" CGA emulation, at least in mode 6. Kind of a weird thing to do, but maybe I'm looking at it wrong.

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.

3. Is there any downside to letting the "cga" property be "Changeable::Always"? Would make it easier to toggle from the internal command prompt.

All in all this is looking very good - the more prominent fringing may need some getting used to, and more configurable options could make it more flexible, but I'd say it's close enough to meeting the goal for DOSBox.

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.

robertmo wrote:

ripsaw8080 wrote:

The colors generally look good; but the colored edges, such as on the castle bricks or door handles, take some getting used to.

Maybe this is cause of too high saturation too?

No, it's just a consequence of using a notch/bandpass filter to separate Y and C - whenever there is a vertical boundary between two colours there will be a transient artifact of some kind. It's just that ripsaw8080 is used to the previous (incorrect) algorithm. Reducing the saturation would make them less obvious but (as long as the saturation isn't turned all the way down) they will still be there.

robertmo wrote:

I've noticed alt-f10/f10 switches background color/intensity. But why only in red/blue/white mode?

Not sure what you're talking about here - alt-f10 and f10 don't do anything as far as I can tell. Is there some specific game that this is in reference to?

robertmo wrote:

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

When you say "not configurable" do you mean that the automatic detector doesn't choose composite mode by default? (Because its only heuristic is 640x200 mode with palette 15 and color burst enabled and this is a 320x200 game)

VileRancour wrote:

1. In mode 6 / white foreground, there's now a distinct difference between the new and old CGA types: with cga=new, colors are the same as in the previous patch or cga2ntsc; with cga=old, the hue once again looks like it does in upatched DOSBox, i.e. 15 degrees away. Essentially the same effect as the -15 degree hack in current SVN.
Assuming that this is a result of your added logic delays, it might explain something about the clone card which inspired that hack

It was my understanding that there was never actually a clone card that does this at all - see CGA Composite Mode under DOSBOX (Commited r3804).

VileRancour wrote:

3. Is there any downside to letting the "cga" property be "Changeable::Always"? Would make it easier to toggle from the internal command prompt.

I think the only reason I didn't do it that way from the beginning is because it won't take effect immediately (not until the next call to update_cga16_color()) so it might be confusing. I'm fine with it either way however.

VileRancour wrote:

with cga=new, colors are the same as in the previous patch or cga2ntsc; with cga=old, the hue once again looks like it does in upatched DOSBox, i.e. 15 degrees away. Essentially the same effect as the -15 degree hack in current SVN.

That seemed odd to me at first but I rechecked the numbers and yes: 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.

With default hue in Blue Angels the edge artifacts don't stand out because the colors are similar, but after changing the hue there are single-pixel edges with high contrast. It's a bit strange looking, like some kind of filter was applied to the image. Shouldn't transitions be more gradual in general, or is this maybe some unintended behavior of the algorithm brought out by changing hue?

ripsaw8080 wrote:

With default hue in Blue Angels the edge artifacts don't stand out because the colors are similar, but after changing the hue there are single-pixel edges with high contrast. It's a bit strange looking, like some kind of filter was applied to the image. Shouldn't transitions be more gradual in general, or is this maybe some unintended behavior of the algorithm brought out by changing hue?

On the text you mean? Yes, it looks strange because the blue used in the shadows is very similar to the background. However, we know that the composite support for this game was developed with the combination of a Tandy 1000 and a monitor with a comb filter, both of which will make a difference.

It occurs to me that we don't know the logic delays in the Tandy 1000's video circuitry (and have no way of modelling them, since it's all in a ULA). Making comparisons with Servo's screenshots, I suspect the correct hue shift is closer to 120 than the 135 I thought earlier, and the difference is probably logic delays again.

The reason the two blues aren't more different could be differences in the resistor values between IBM CGA and Tandy 1000, or (more likely) brightness/contrast/saturation issues.

reenigne wrote:

It was my understanding that there was never actually a clone card that does this at all - see viewtopic.p...180#264306.

D'oh - you're right... and this after I had read and re-read the referenced posts 'till the cows came home. (Dis)information overload claims another victim. :)

That seemed odd to me at first but I rechecked the numbers and yes: 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.

...which, in turn, likely means that those initial KQ1 screenshots that sparked the whole thing off were from an "old-type" CGA, in contrast with Servo's captures that seem to use the later model. Sounds like a satisfactory answer to that age-old question (and a good reason to keep the choice of CGA revision configurable).

reenigne wrote:

On the text you mean? Yes, it looks strange because the blue used in the shadows is very similar to the background.

I didn't really notice the text shadow because the text was never particularly legible, anyway.

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.

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?

reenigne wrote:

robertmo wrote:

I've noticed alt-f10/f10 switches background color/intensity. But why only in red/blue/white mode?

Not sure what you're talking about here - alt-f10 and f10 don't do anything as far as I can tell. Is there some specific game that this is in reference to?

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

reenigne wrote:

robertmo wrote:

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

When you say "not configurable" do you mean that the automatic detector doesn't choose composite mode by default? (Because its only heuristic is 640x200 mode with palette 15 and color burst enabled and this is a 320x200 game)

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)

reenigne wrote:

I noticed a minor bug in the way I'm computing the zero point of hue. The line: […]
Show full quote

I noticed a minor bug in the way I'm computing the zero point of hue. The line:

Copy code to clipboard

1	double hue_adjust = (-(45-22.5+33)+hue_offset+pixel_clock_delay)*tau/360.0;

should read:

Copy code to clipboard

1	double hue_adjust = (-(90-33)+hue_offset+pixel_clock_delay)*tau/360.0;

Added. Brown is more greenish in mode 6 now .