eL_PuSHeR wrote:

[Thread moved to DOSBox Development Section as suggested]

maybe this post could be split to a new thread in the patches section? - Re: CGA Composite Mode under DOSBOX?

Servo wrote:

Ok, here's a few captures with palette 0 low intensity.

Great - thanks for these. Here's what it looks like in DOSBox using the aforementioned method (hardcoding a phase difference for the chroma signals and the opposite difference in the overall hue control). 115 degrees looks like a better match for your PCjr capture; still a few minor differences to work out.
 

In preparing an overhaul of Wikipedia's CGA article to incorporate the new findings since 2008, I have created example images showing direct and artifact colors of all the major CGA revisions. I haven't seen a capture of the PCjr in 640x200 mode, so those colors might be completely off.

NewRisingSun wrote:

I haven't seen a capture of the PCjr in 640x200 mode, so those colors might be completely off.

According to Servo's earlier post, 640x200 on a PCjr should be the same as new CGA with no offset (though that was from memory, so some verification would be helpful if that is to go on WP).

About those 320x200 PCjr palettes: intensity aside, some of the hues appear to differ from the captures; e.g. artifact color #2 being green rather than a reddish brown in both palettes, and #11 being a lot more yellowish in pal1. Though my DOSBox attempts above had similar discrepancies which I'm still not sure how to account for.

I have updated the PCjr portion of the images. I had matched the PCjr to DosBox, now I have matched it to the captures. Palette 0 color 2 is now more like brown (though I would disagree about it being a "reddish" brown), and 640x200 mode now looks like new CGA.

I would like to ask,
if some games using mode 4/5, but with changes on background color (color 0) to something else than black, usually Light-Blue (like upper half of game: Frogger).

Would changing the color-0 can also affect color-artifacting on composite monitor?

Joey_sw wrote:

I would like to ask,
if some games using mode 4/5, but with changes on background color (color 0) to something else than black, usually Light-Blue (like upper half of game: Frogger).

Would changing the color-0 can also affect color-artifacting on composite monitor?

Yes, see Pitstop II: http://www.mobygames.com/game/pc-booter/pitst … eShotId,128360/

This patch still doesn't support linewise color updates (=in mid-frame) - there just aren't enough palette entries available, but aside from Pitstop II I can't think of any game that really uses this trick for color artifacting. "Normal" changes of color 0 work fine as demonstrated.

In composite color mode, Pitstop II uses 640x200 mode with color select register = 0x0a. No mid-screen color changes.

Right - no idea why that's the game I thought of... it is a rare example of using a non-grey/white color in mode 6, but yes, the color is constant throughout the screen.

Jungle Hunt does change the palette for the height of the status bar, but not for color-blending purposes (there are no separate RGB/composite options anyway). Did any game use such a trick specifically for color artifacting? I guess CGA-era game authors didn't think that going beyond 16 simultaneous colors was worth the hassle.

Was trying to get some mode 6 captures on the PCjr but I'm not sure how to set the color burst there for modes where it defaults off; on CGA the color burst bit is in port 3d8 and I had no problem setting that, but apparently PCjr is 3da instead and I'm not sure what value I need to set there. Can any one point me to any PCjr resources or know how to enable color burst on PCjr?

In DEBUG, type

1o 3DA 00
2o 3DA 0A

Stickying this thread, since it seems to be a long-running active development topic.

Well, once again my memory was completely off; I did a capture of mode 6 on my PCjr and on PC/CGA and the colors are pretty different.

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.

Updated the picture in my previous post again.

Is the CGA picture new or old CGA?

VileRancour wrote:

Any comments about this implementation? I guess this makes the patch pretty much good to go (leaving aside the question of pcjr/tandy)... if anyone wants to "prettify" it and/or move this stuff to a dedicated [composite] section then go right ahead.

So far it works great and held up to my port twiddling. Nice job!

The capture video and capture screenshot sections appear missing from the mapper, and when I add them manually to the keymapper file, it just says the following:

1Can't find matching event for hand_scrshot
2Can't find matching event for hand_video

Any reason these are missing?

The build you used doesn't make use of libpng which is used for both these events.

With regards to the patch.
Would it be possible to find some sensible defaults for all those settings ?
As I am not fond of adding stuff to the configuration file for the composite video mode.

MobyGamer wrote:

So far it works great and held up to my port twiddling. Nice job! […]
Show full quote

So far it works great and held up to my port twiddling. Nice job!

The capture video and capture screenshot sections appear missing from the mapper, and when I add them manually to the keymapper file, it just says the following:

Copy code to clipboard

1Can't find matching event for hand_scrshot
2Can't find matching event for hand_video

Any reason these are missing?

yeah - it's just a test build; I use MSVC, and linking the required zlib/libpng libraries seems like a real pain with that. Should really get around to setting up a proper dev environment already. *hides*

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.

Hmm, thought I did something similar... if you look at my attempts, the solid colors (patterns 0,5,10,15) aren't shifted. Though I applied the offset to phases[6] rather than pixel_clock_delay.
Attached is a comparison of the results against the colors from the captures: the trouble with Below the Root seems to be that a select few colors are still off (see colors #2 and #9 in mode 4). Any idea what could cause that, if the chroma colors (and most of the artifact colors) appear to be correct?
 

Qbix wrote:

With regards to the patch.
Would it be possible to find some sensible defaults for all those settings ?
As I am not fond of adding stuff to the configuration file for the composite video mode.

Hue and composite auto/on/off could just stay in the keymapper. The problem is with cgatype and tvbrightness... some games definitely need the ability to adjust these: MS Decathlon needs old CGA; Tournament Tennis needs new CGA. Championship Golf needs brightness lowered by a lot; most other games are fine with 100%.

These things could be moved to the mapper too, like robertmo's earlier suggestion - it's just less convenient IMO to have to keep tapping the keys for the correct values before loading each game.

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.

I am asking because my suspicion is that the amplitude ratio of chroma and luma might not be correct.

QBix wrote:

As I am not fond of adding stuff to the configuration file for the composite video mode.

Why not? If you are worried about frontends, the CGA emulation will run just fine for most games even if these values are missing in the configuration file.

VileRancour wrote:

Hmm, thought I did something similar... if you look at my attempts, the solid colors (patterns 0,5,10,15) aren't shifted. Though I applied the offset to phases[6] rather than pixel_clock_delay.
Attached is a comparison of the results against the colors from the captures: the trouble with Below the Root seems to be that a select few colors are still off (see colors #2 and #9 in mode 4). Any idea what could cause that, if the chroma colors (and most of the artifact colors) appear to be correct?

Ah okay. In that case, three possibilities spring to mind - two easy to fix, one more difficult.

One is that just tweaking the hues of some of the artifact colours a small amount might fix things. Nybble 2 is red and black pixels, so maybe tweaking phases[4] a bit (while leaving the other entries of phases alone) would get you that reddish brown for nybble 2 without affecting the colour of nybble 10 too much.

The second is that the correct pixel_clock_delay might be different for 2bpp mode than for 1bpp mode.

The third one is more difficult - it could be that pixels start and end in slightly different places depending on their colours. In my patch I mentioned such a possibility in the comment "The pixel clock delay calculation is not accurate for 2bpp, but the difference is small and a more accurate calculation would be too slow." Well, maybe in this case the difference is large enough to be visible. The trouble is that without knowing exactly what the circuitry inside the PCjr's PAL is, there's no way of knowing exactly what those delays should be, and there's enough variables that tuning them all would be equivalent to just manually choosing a colour for each possible nybble.