Back on topic:

Attached is a "lite" version of the composite CGA patch, which may be more suitable for the dev team to commit, as previously discussed. (Qbix?)
No new config options or machine types; only two extra key mappings compared to official DOSBox:

- F12: set composite output - auto/on/off (default=auto)
- Ctrl+Alt+F11: select CGA model (early/late, aka "old/new")

There hasn't been much to add on the composite emulation front lately, but a couple more games have turned up that really call for artifact colors in mode 4 (see the other two attachments), which drove me to revisit this once again.

This "lite" patch takes away some of the fine-tuning options such as brightness -- not really a concern for most games, but if a full monitor patch is ever implemented in the future, all of those extra controls would optimally be incorporated into that.

[Moderators: is there any way to have this visible in the Patches forum? after all, a working patch buried beneath 27 pages of discussion isn't too easy to find.]

but a couple more games have turned up that really call for artifact colors in mode 4 (see the other two attachments), which drove me to revisit this once again.

Aside from the games you mentioned, I can also list the following as using Mode 4 composite colors:

*Archon
*Adventure in Serenia
*Ulysses and the Golden Fleece
*Shamus
*Boulder Dash
*M.U.L.E.
*Donkey Kong
*Agent USA

kao wrote:

Aside from the games you mentioned, I can also list the following as using Mode 4 composite colors: […]
Show full quote

but a couple more games have turned up that really call for artifact colors in mode 4 (see the other two attachments), which drove me to revisit this once again.

Aside from the games you mentioned, I can also list the following as using Mode 4 composite colors:

*Archon
*Adventure in Serenia
*Ulysses and the Golden Fleece
*Shamus
*Boulder Dash
*M.U.L.E.
*Donkey Kong
*Agent USA

Look at the attachment back on page 13 of this thread for an incomplete list of games I compiled that use 320 and 640 color composite graphics.

CGA Composite Mode under DOSBOX (Commited r3804)

Look at the attachment back on page 13 of this thread for an incomplete list of games I compiled that use 320 and 640 color composite graphics.

Ok I looked at your list and you couldn't figure out some games.

Burgertime, Jumpman, and Ms. Pac Man are 640x200. In fact Ms. Pac uses the old Sierra trick of switching to Mode 4 and then writing 1A to 3D8 to dupe the BIOS into printing 40-col text. I believe it was developed by Sierra as Atarisoft farmed games out to all different devs who went uncredited (Jungle Hunt was definitely made by them as it uses their favorite red/green/brown/blue colors and the same palette swap trick as Frogger).

Night Mission Pinball offers four options on startup:

A. Color TV or composite monitor (640x200 w/ color on)
B. B&W TV or monitor (640x200 w/ color off)
C. RGB monitor color set 1 (320x200 w/ CMW palette)
D. RGB monitor color ser 2 (320x200 w/ RGY palette)

A bunch of Atarisoft games (Dig Dug, Donkey Kong, Moon Patrol, etc) also offer a "Do you want full color?" option. One of these appears to be for RGB monitors and switches to Mode 5 (they would be B&W on composite). The other is the low intensity RGY palette in Mode 4 and appears to be for composite.

As an aside note, those screenshots on Page 13 were more-or-less pretty accurate to what my XT displays except Dig Dug was too green (color 3 a golden yellow)

So it's not an intentional adjustment, but a glitch possibly caused by extracting the game from the original floppy. That's very nice. I'm sure though that Jumpman was modified because that has no speed throttling for 286+ machines.

And I suddenly remembered now that Demonlord put an exit feature into Centipede (Alt+X). I'm going to guess that that somehow screwed up the keyboard routines in there (the code may be very timing-sensitive and this alteration could throw it off).

One little continuation from here. The DOS rip of Ms. Pac Man for some reason causes the floppy motor to spin continually, so you either have to run it from a hard disk or load it in DEBUG first and then execute (this problem seems to only happen if you start it from a floppy at the DOS prompt)

kao wrote:

(Jungle Hunt was definitely made by them as it uses their favorite red/green/brown/blue colors and the same palette swap trick as Frogger).

But does it truly use the exact same technique to pull it off? Jungle Hunt changes the palette for a constant number of scanlines, but in DOSBox the affected region moves along the Y axis depending on CPU cycles... unlike Frogger. Though I haven't really tested this too rigorously.

kao wrote:

As an aside note, those screenshots on Page 13 were more-or-less pretty accurate to what my XT displays except Dig Dug was too green (color 3 a golden yellow)

Those screenshots were from an early proof-of-concept program - I wonder how the current DOSBox patch matches up against your XT. Is your CGA card an "early" or a "late" model?

But does it truly use the exact same technique to pull it off? Jungle Hunt changes the palette for a constant number of scanlines, but in DOSBox the affected region moves along the Y axis depending on CPU cycles... unlike Frogger. Though I haven't really tested this too rigorously.

Someone will have to disassemble it and find out. Jungle Hunt is the only game I know that's 100% totally unusable on VGA (you can't even get past the title screen as it just locks up). Whereas Frogger runs except for the palette switch.

Is your CGA card an "early" or a "late" model?

I don't know; I never bothered to check. Archon and Shamus definitely look completely correct to what the real thing displays. Low-intensity RGY looks gold-colored while it looks bright pastel yellow on high intensity.

The TV I used here was a mid-90s 19" GE CTC175.

i have question about how color-0 would affect the composite output for mode-4
Suppose theres repeated vertical-line pattern like this:
Even-location lines: Cyan
Odd-location lines: Green

The pattern might be made by two following method:

1. Set palette into Green/Red/Brown,
   Set color-0 to Cyan
   Draw the vertical line with color depend on the X coordinate position
   The even line = color 0 (Cyan)
   The odd line = color 1 (Green)
   
   or
2. Set palette into Cyan/Magenta/White,
   Set color-0 to Green
   Draw the vertical line with color depend on the X coordinate position
   The even line = color 1 (Cyan)
   The odd line = color 0 (Green)

Except for the border color, both method will yield same visual results on non-composite monitors.
Would the same also applies for composite output? (Old, New, Tandy & PCJr)

Look at the attachment back on page 13 of this thread for an incomplete list of games I compiled that use 320 and 640 color composite graphics.

I updated the spreadsheet; there were a few corrections that needed to be made and I was able to fill in a few missing modes/games.

Joey_sw wrote:

Except for the border color, both method will yield same visual results on non-composite monitors.
Would the same also applies for composite output? (Old, New, Tandy & PCJr)

Yes, they should give the same results on composite output. At least for CGA (both types), the composite output is generated by taking the RGBI output and applying some transformations on it to create a composite signal. Since the RGBI outputs are the same for these two screens, the composite outputs should be too.

I'm not 100% sure offhand if the same is true for Tandy and PCJr (since much of the logic is in opaque chips), but I'd be very surprised if it wasn't.

reenigne wrote:

Joey_sw wrote:

Except for the border color, both method will yield same visual results on non-composite monitors.
Would the same also applies for composite output? (Old, New, Tandy & PCJr)

Yes, they should give the same results on composite output. At least for CGA (both types), the composite output is generated by taking the RGBI output and applying some transformations on it to create a composite signal. Since the RGBI outputs are the same for these two screens, the composite outputs should be too.

I'm not 100% sure offhand if the same is true for Tandy and PCJr (since much of the logic is in opaque chips), but I'd be very surprised if it wasn't.

Is it possible to recreate the composite signal by using the RGBI output from the monitor connector? I am not just talking about a straight color to color conversion, which can be done, but to allow for artifacting.

I updated the spreadsheet; there were a few corrections that needed to be made and I was able to fill in a few missing modes/games.

You forgot Boulder Dash. Miner 2049er also appears to have composite support. It's unnecessary to list Sierra AGI games separately since they all support 640x200 composite (instead you could just have one big entry labeled "AGI games")

Jungle Hunt changes the palette for a constant number of scanlines, but in DOSBox the affected region moves along the Y axis depending on CPU cycles

Jungle Hunt scrolls while Frogger doesn't; it may use a slightly different technique for this reason. Whatever the case, it's extremely timing sensitive and really does need an 8088+true blue CGA to work properly. I found some old posts by Great Hierophant on VCF where he says that on Tandys, the palette switch is off by four scanlines.

I am not just talking about a straight color to color conversion, which can be done, but to allow for artifacting.

CGA and Apple IIs keep the NTSC phase shift constant while on broadcast TV, it flips 180 degrees every scanline, thus producing faint vertical bars on the screen. Normally, chroma interference produces checkerboard patterns because of the alternating PS, but since it remains static here, they appear as bars.

At least for CGA (both types), the composite output is generated by taking the RGBI output and applying some transformations on it to create a composite signal.

IBM used a TTL logic circuit on CGA instead of a RGB -> NTSC converter for cost reasons. PCjr/Tandy use some kind of LSI chips.

Great Hierophant wrote:

Is it possible to recreate the composite signal by using the RGBI output from the monitor connector? I am not just talking about a straight color to color conversion, which can be done, but to allow for artifacting.

In theory, yes. It would not be easy though, because the RGBI output doesn't include the color burst, so just doing a straight RGBI to composite conversion wouldn't work for artifact colours, since the color burst phase wouldn't be aligned with the pixel clock. You could reconstruct the pixel clock from the horizontal sync pulse, though, and then generate a color burst (and chroma signals for the 8 RGB combinations) based on that.

composite_lite.diff has been commited as r3804.

Congratulations to _everyone_ involved in getting this in SVN, amazing piece of work and a fine contribution to some good ol' nostalgia! Thanks!

Nice! Good to know. 😀

Curious though... is a fix being planned for the aspect correction weirdness? (aspect=true looks over-squashed for the M_CGA16 mode.)

VileRancour wrote:

[Moderators: is there any way to have this visible in the Patches forum? after all, a working patch buried beneath 27 pages of discussion isn't too easy to find.]

I could split the thread from that point on, and make it the start of a new thread. Does that work?

I just came here looking for that info myself, as I saw it pop up in the DOSBox SVN changelog 😀

Edit: Can someone summarize what all the patch does, including what is added/removed/changed in the preexisting composite emulation? Also, does it allow proper composite emulation of games like Ultima 2 that weren't previously supported?

HunterZ wrote:

I could split the thread from that point on, and make it the start of a new thread. Does that work?

I guess, but that's probably not necessary anymore (the title now says that it's committed + anyone can compile from current SVN for the functionality).

Edit: Can someone summarize what all the patch does, including what is added/removed/changed in the preexisting composite emulation? Also, does it allow proper composite emulation of games like Ultima 2 that weren't previously supported?

The previous code only supported composite color for 640x200 games (CGA mode 6), and not 100% correctly either (some register behavior that didn't match what the real hardware does).

The patch:
- adds composite support for 320x200 graphics modes, which fixes Ultima 2 and many others, to answer your question.
- can emulate either "early"-model or "late"-model CGA (this has a visible effect on composite colors) - toggle with ctrl+alt+F11
- lets you set composite emulation to AUTO (default; works the same as it did before), ON (needed for 320x200), or OFF - select with F12
- corrects previous known inaccuracies.

Excellent, thanks!

If Jorpho doesn't mind, another option is for an admin, moderator or Jorpho to edit the first post in this thread to link to the specific relevant post(s).

Was playing some CGA games the other day, but don't think I was seeing the composite mode effects I should have. Is there DOSBox config related to such beyond setting...
[dosbox]
machine=cga

Ah duh, was up above...
F12: set composite output - auto/on/off (default=auto)
Ctrl+Alt+F11: select CGA model (early/late, aka "old/new")
...though...

Can someone explain how the "auto" mode works, is it that it only sets up composite mode for 640x200x2 modes? It doesn't seem to be setting composite mode for "Rad Warrior" which needs it to read the UI details (i.e. score, etc.). Is there any way to set the composite mode via config entries?