Servo wrote:

Amiga can choose 16 out of 4096 colors

32 actually (and 64 in Extra Half-Bright mode). But don't mind me.

Just a note: most modern PAL TVs can display NTSC (or at least "emulate" it in PAL 60 Hz), and the hue/tint setting is only OSD'd when the TV set receives an NTSC signal. Most European users are not familiar with the hue concept (I know I wasn't until I got a Japanese Laserdisc player!). Hey, we're a bunch of spoiled children born in a world of pure, blissful RGB 😉

Kaminari wrote:

32 actually (and 64 in Extra Half-Bright mode). But don't mind me.

oops, yes, that's what I meant; Sierra's AGI games only use 16 of 32 simultaneous colors though.

HunterZ wrote:

Are you using the same computers and DOSBox sound buffer and sample rate configuration settings with comparing sound output in 0.63 and CVS? There is a possibility that you're unintentionally introducing the sound artifacts by using too small of a buffer or by having analog input lines unmuted on your sound mixer that can be picking up RFI noise. I only ask because it's suspicious that you hear ticking in Tandy output for one game and OPL output for another.

Also, the CVS build you linked to is quite out of date. The other two linked from my CVS thread are much newer, although they both contain experimental patches.

I used the same computer, of course. I also used the same DOSBOX.CONF file, so the configuration would be the same for the CVS and 0.63.
And I didn't speak of Tandy sounds, I was talking about Indy and the Last Crusade which I loaded with machine=vga. And the KQ1 booter I mentioned was the PC booter, not the Tandy booter.
Also, I took the CVS from http://ykhwong.x-y.net/page.htm, it's dated October 4th, so it's not out of date. So, unless I did something else wrong, there's a new sound problem here.
Incidentally, while I tested Indy3 I noticed something weird - the sound of opening and closing doors is completely wrong under ANY version of DOSBox, not only the CVS. (and I know for a fact it's wrong cause I do own the "real hardware" this time 😁 ). Listen to it, I attached a rarred wave. There maybe other wrong sounds, but I didn't look for them.

NewRisingSun wrote:

I understand that the hue will not be changeable in the new version of DOSBox, is that correct?

Unfortunately not, even though I've been whining in my notoriously subtle way for quite some time. 😀 I think if they can reserve several key combinations for things 90% of DosBox users are never going to use (OPL logging, ...) , they could also reserve two combination for +/- NTSC hue.

So we should nag and whine and nag until they give up! Or ban us... 😦 But seiously, ever since I found out that CGA could actually support 16 colors, and that my favorite booters support it, I've been trying to find a way to get the best possible emulation for it. And it seems a "hue control" is required (yes, I'm from a PAL country).

NewRisingSun wrote:

It seems to me though that Sierra at the time was a little colorblind when it comes to orange vs. pink. Look at these screenshots:

http://www.mobygames.com/game/black-cauldron/screenshots

In the title screen, the Atari ST and Amiga versions have orange where the DOS version has pink.

Well, you can get that orange back if you run Black Cauldron under the new CVS (while machine=cga), and it doesn't matter if you use the booter or the DOS version. Look:

Kaminari wrote:

Just a note: most modern PAL TVs can display NTSC (or at least "emulate" it in PAL 60 Hz), and the hue/tint setting is only OSD'd when the TV set receives an NTSC signal. Most European users are not familiar with the hue concept (I know I wasn't until I got a Japanese Laserdisc player!). Hey, we're a bunch of spoiled children born in a world of pure, blissful RGB 😉

I have a modern PAL TV, so I decided to test this. And, it seems that whenever I put in an NTSC VHS tape or a Region 1 DVD, this "tint" option suddenly appears in the on-screen menu! When I choose it I get this bar that has green on its rightmost side and red on its leftmost side. I played with this and the colors of the picture actually changed! I checked Sin City, which is mostly b&w but have some colored parts with very definitive colors, and when the bar was all the way to the left, blood became purplish, and when I set it all the way to the right, the blood was orange. This is one of the most stupid things I've ever seen! Why not just have fixed colors? I guess when the bar is exactly in the middle (i.e. 0) the colors are supposed to be correct.
So, there weren't any PAL composite monitors? If there were maybe DOSBox should emulate them instead of NTSC, since they obviously always display the correct colors.

HunterZ wrote:

you can always write and submit a patch (which will probably make it into the popular CVS builds if not the official source tree).

Well, I think if someone goes through the trouble of writing a hue control, it should be integrated in the next official release so we'll have the perfect composite CGA emulation. If not, then at least the hue is set to 0 which supposed to give the "correct" colors.
Actually, I'm wondering why do we need a hue control at all? If I understand correctly, when hue=0 the correct colors are displayed, and any deviation from that only changes them to wrong colors. Isn't the correct colors what we want?

Well, you can get that orange back if you run Black Cauldron under the new CVS (while machine=cga), and it doesn't matter if you use the booter or the DOS version

Well yeah, that's the mistake I'm talking about, because it's supposed to be pink, not orange. The character's hair and face on the other hand are pink when they should be red/orange. As I said, Sierra mixed up pink and orange on a regular basis. This can not be corrected with any hue adjustment, either.

It's interesting though that for Mickey's Space Adventure and Winnie the Pooh, the composite version is correct and the RGB (Tandy/EGA) version is wrong, whereas for all other games, RGB is correct and composite is wrong.
Maybe the fact that Mickey and Winnie were originally for the C64/AppleII, while the others are PC originals, is the reason.

Why not just have fixed colors?

Because the hue fluctuates by itself with terrestial reception, that's why you need a "hue" control to correct these transmission errors. PAL does not have that problem because the chroma signal is inverted on every other line, thus allowing the hue shift to cancel itself out at the expense of saturation.

If there were maybe DOSBox should emulate them instead of NTSC, since they obviously always display the correct colors.

The CGA outputs a NTSC signal, therefore, you need to emulate a NTSC monitor, not a PAL monitor (duh). A non-multistandard PAL TV, when receiving a NTSC signal, will display a black&white picture at best; thus, emulating a PAL monitor would mean emulating a black&white picture. 😉

I think if someone goes through the trouble of writing a hue control

It's actually not a trouble at all, because the hue changing code is already there; someone just needs to assign two key combinations for + and - and make them affect the variable "tvHueOffset". That shouldn't involve more than 10 lines of code max, if you know what to change.
I'm certainly not going to mess around with the user interface of an unknown program.

Actually, I'm wondering why do we need a hue control at all? If I understand correctly, when hue=0 the correct colors are displayed

No. Hue=0 does not produce "correct" hues at all times; rather, the "correct" hue depends on what the programmers just happened to have set their TVs to back then, and also what kind of graphics card they used --- the Tandy 1000 for example seems to produce a different hue offset than the CGA, and the PCjr is different again, as Servo tells me.

To give you an example: the color of bright grass in KQ1 Booter is the same color that is used for the sky in Bruce Lee. Obviously you'd want grass to be green and the sky to be blue, hence, it makes sense that you need different hue settings for these games.

When I told QBix to leave "tvHueControl" at 0 rather than adjust it to what he likes, that was because the current CVS code tries to "auto-guess" the correct hue by looking at bit 5 of register 0x3d9.
This emulates a neat feature of my old CGA clone, but this is not what an original IBM CGA does (something I only learned recently; I thought all CGAs behaved like that. I still think that at least some game programmers were conscious of that clones' feature, why else would they set a bit that is unused on an original IBM CGA?).
Once the hue offset becomes user-adjustable, this behavior should of course be removed.

Hope this clears it up for you.

-non-booter AGI -cga switch still doesn't work when machine=vga. This switch forced EGA AGI games to run in CGA colors (two palletes changeable by Ctrl-R) on VGA machines.

This has been fixed by wd.

The textbox issue:

Seems to be caused by some sort of selfmodifying code.
A bit odd that happened on your old system as well as they don't have prefetch queues. (Bug is present in 0.63 with dynamic core as well)

Indy3:
I attached a recording made at my place.
It doesn't have these ticks.
So it's probably one of the experimental patches.... (did you enable timesync ?)

Qbix wrote:

-non-booter AGI -cga switch still doesn't work when machine=vga. This switch forced EGA AGI games to run in CGA colors (two palletes changeable by Ctrl-R) on VGA machines.

This has been fixed by wd.

And in which CVS this can be found? There are so many CVSs, I just hope all the correctly improved stuff will end up in the next release 😖

Qbix wrote:

The textbox issue:

Seems to be caused by some sort of selfmodifying code.
A bit odd that happened on your old system as well as they don't have prefetch queues. (Bug is present in 0.63 with dynamic core as well)

Yeah, I found out that core=dynamic causes that. It is odd that it happened to me on my old 286, that's why I mentioned it. It was actually nice seeing Alexander's "footsteps" again, because I couldn't reproduce this problem on any other system I owned since then, and it reminded me of great times!

Qbix wrote:

Indy3: I attached a recording made at my place. It doesn't have these ticks. So it's probably one of the experimental patches... […]
Show full quote

Indy3:
I attached a recording made at my place.
It doesn't have these ticks.
So it's probably one of the experimental patches.... (did you enable timesync ?)

Your recording is indeed clean. And no, I have timesynched=false in my DOSBOX.CONF. Perhaps we're using a different CVS?
By the way, did you listen to the wave of the Indy3 door sounds? It's really weird and it sounds like that on every DOSBox version. I wonder what's causing it.

NewRisingSun wrote:

Hope this clears it up for you.

Yes, it actually does. It's very unfortunate that something that was necessary as a result of broadcasts interfered with computer game programming. By the way, Qbix, why are you against hue control if it's so simple? You can use F11 and F12 for the +/-, no 80s game recognizes those 😀

Ok, since we're still on the composite subject, I decided to test the old Lucasfilm games that I suspected have composite support. Namely, the regular and enhanced versions of Maniac Mansion and Zak McKracken.

As you probably know, these games automatically detect the video card you're using, but you can switch graphic modes by pressing Shift and a letter key. In addition, you can press Shift-W inside the games and a PREFS file will be created, which is useable by the switch p (e.g. maniac p). In this PREFS file I found a line in which you can turn composite mode on or off, so I began testing this under DOSBox.
I found that the original versions and enhanced versions behaved in quite a different way, so I'll begin with the original versions:
When the games are in CGA mode (Shift-C), having composite ON or OFF in the PREFS file causes some change in the colors.

left shot: composite is OFF in PREFS file, right: composite is ON

The same change happens whether machine=vga or machine=cga (although the image is brighter when machine=cga) on both 0.63 and CVS. The same thing also happens on a regular VGA machine. So, this can't be a composite mode, obviously.
When I continued testing the various graphic modes of the games, I found something very odd - when I switched to b&w CGA mode (Shift-B) while DOSBOX.CONF is set to machine=cga, I got what appears to be a composite mode! This happened both on 0.63 and on CVS, with a minor color difference. Observe:

left shot: DOSBox 0.63, right: DOSBox CVS

Whether composite was ON or OFF in the PREFS file made no difference whatsoever in this case. Something is obviously wrong, because b&w CGA mode shouldn't have colors at all. And those colors don't look so good anyway! Under a normal VGA, and also under MESS 0.100, b&w CGA mode simply displays b&w graphics. (incidentally, when machine=vga b&w CGA mode looks corrupted, and not like it should look on a VGA screen; click here to see how it looks under 0.63 and here to see how it looks under CVS).
Because of this weird behaviour in DOSBox, I decided to see what MESS 0.100 will do. Like I already said, MESS displayed the b&w CGA mode correctly. However, it produced two new composite "look-alike" modes when the game was in CGA mode. You can switch between them by turning composite ON or OFF in the PREFS file; take a look:

left shot: composite is OFF in PREFS file, right: composite is ON

One last thing that can be said about the regular versions of Zak and Maniac, although a little off the subject, is that when machine=tandy the screen size is weird. See here.

On to the enhanced versions. I didn't think that the enhanced versions have composite support at all, but the option appears in the PREFS files so I checked them too.
Since the enhanced versions don't support the b&w CGA mode, there were much less weird behaviours. When in CGA mode (Shift-C), the games showed the exact same pallete, and it didn't matter what DOSBox version I was using, nor if machine=vga or machine=cga. It also didn't matter if composite was ON or OFF in the PREFS file. And they behaved in the same way on a regular VGA screen. Only when loaded on MESS, composite colors seemed to appear. Here's a screenshot:

MESS 0.100 (Maniac Mansion enhanced version)

Well, that's sums it up 😁

Something is obviously wrong, because b&w CGA mode shouldn't have colors at all.

Yes, DosBox seems to always select composite graphics in 640x200 mode, even when the color burst is off. That's not part of my code, however, to decide whether to have composite graphics or not.

However, it produced two new composite "look-alike" modes when the game was in CGA mode.

Neither of which looks good, of course. LucasArts didn't REALLY support composite graphics 😀

Only when loaded on MESS, composite colors seemed to appear.

Well, if you select a "composite monitor", composite artifacts of course will ALWAYS appear (unless the color burst is turned off, in case of which you will get a black & white picture); the question is whether the game makes conscious use of them to improve the picture or not, and the enhanced versions don't seem to.

I confirm. For some reason machine=vga seems to force composite CGA in B&W CGA games.

It looks very much like a strange behaviour I reported some time ago with early Legend games which left us puzzled for a while. I was getting a weird scrambled composite-like display when setting DOSBox to VGA and running Spellcasting with the CGA argument:

But the fact is, there's no composite support in Spellcasting. Using the CGA argument, you're supposed to get a 640x200 B&W CGA output -- and indeed, that's what you get when setting DOSBox to CGA:

Kaminari wrote:

I confirm. For some reason machine=vga seems to force composite CGA in B&W CGA games.

It looks very much like a strange behaviour I reported some time ago with early Legend games which left us puzzled for a while. I was getting a weird scrambled composite-like display when setting DOSBox to VGA and running Spellcasting with the CGA argument

That looks like the scrambled intro screen I was seeing in Overkill too. Don't remember whether that was fixed.

NewRisingSun wrote:

Neither of which looks good, of course. LucasArts didn't REALLY support composite graphics 😀

They didn't!? So why there's a composite line in the PREFS file?
Also, Great Hierophant wrote a FAQ about the different versions of Zak McKracken (I saw it in a thread in the LucasArts Museum forum). He said there that the older version of Zak had 16 colors composite CGA support, but it was eliminated in the enhanced version. Was he wrong?

Kaminari wrote:

I was getting a weird scrambled composite-like display when setting DOSBox to VGA and running Spellcasting with the CGA argument:

That's odd, I got somewhat opposite results when I tested Spellcasting 101. What version of DOSBox were you using? I checked both 0.63 and an October 4th CVS that I got from http://ykhwong.x-y.net/page.htm. On both versions I got the composite-like pallete you showed in your screenshot only when machine=cga, not when machine=vga like you wrote. And it didn't matter if I used the cga argument or not, the game loaded with the same composite-like graphics. When I loaded the game with the cga argument while machine=vga, I got different behaviors in the two DOSBox versions that I checked. On the CVS, I got the correct b&w pallete, but the screen was very stretched:

DOSBox CVS (mahine=vga)

(note that this is the same behavior I saw when I ran the older versions of Zak and Maniac Mansion in b&w CGA mode under this CVS with machine=vga; you can see a shot here)

On DOSBox 0.63, I got a completely corrupted image when trying to display the b&w CGA graphics when machine=vga:

DOSBox 0.63 (machine=vga)

(note: again, a similar behavior was seen with Zak and Manaic, only without the colors; see a shot here).

The only DOSBox version under which I got a correct b&w CGA image in Spellcasting 101 (as well as in Zak and Manaic) was in an older CVS that I got from http://cvscompile.aep-emu.de/dosbox.htm, and it was only when machine=vga. Otherwise I got the same behavior as DOSBox 0.63.

And back to the tint/hue subject, I found that at least two NES emulators have a hue switch - FCE Ultra and Nestopia. In FCE Ultra, there's a hue control and a tint control:

But I think the tint control is supposed to be named saturation or something, because when I move it all the way to the left, the image becomes b&w, and when I move it all the way to the right, the colors become more intense.

They didn't!? So why there's a composite line in the PREFS file?
Also, Great Hierophant wrote a FAQ about the different versions of Zak McKracken (I saw it in a thread in the LucasArts Museum forum). He said there that the older version of Zak had 16 colors composite CGA support, but it was eliminated in the enhanced version. Was he wrong?

They didn't "really" support composite mode in that they didn't bother implementing it carefully, it's just a half-assed attempt at supporting it, if you will. You'll get SOME 16 colors, but those are not the ones the game is supposed to display.

But I think the tint control is supposed to be named saturation or something, because when I move it all the way to the left, the image becomes b&w, and when I move it all the way to the right, the colors become more intense.

Right. But don't be fooled --- FCEUltra's NTSC emulation is rather inaccurate, mostly the result of a wrong decoder matrix. Of course, since it's no longer being developed, there's no point in submitting an updated version. Some time ago, there was a longer discussion on the nesdev board about his, in case you're interested in that sort of thing.

Fixed spellcasting 101 when dosbox is in cga mode.
it allready worked correctly in vga mode when starting "s101 cga"

For the record there is only 1 CVS.
however there are more than one people who compile it to executables.

• aep emulation - compiles it clean.
• ykhwong - adds a lot of patches.

To report "bugs about dosbox itself in the CVS" you should use aep emulation. But as that one was delayed a lot because of various reasons. a lot of people started using ykwongs build.

if you want to test out patches which aren't in the CVS yet. then you should ykwongs build and use that version to report bugs.

About the ntsc color keys.
Which one do you would want. The hue or the saturnation ? I think the hue (offset) and in which steps whould f11 and f12 step ?

I'm against keys as I don't like having a lot of keybinding in dosbox. but the argument for f11 and f12 as those games don't recognise it, is a convincing one.

One small "problem" with it though: Those settings are required to compensate for transmission errors. Why would dosbox need compensate for that as dosbox doesn't transmit a thing. Or should dosbox compensate for the fact that every programmer had a different TV when creating the game ?

One of the guidelines harekiet and I programmed dosbox with is: "We will not correct bugs in the original games". Would transmission errors in the tv of the programmer fall under that ?

Qbix wrote:

One small "problem" with it though: Those settings are required to compensate for transmission errors. Why would dosbox need compensate for that as dosbox doesn't transmit a thing. Or should dosbox compensate for the fact that every programmer had a different TV when creating the game ?
One of the guidelines harekiet and I programmed dosbox with is: "We will not correct bugs in the original games". Would transmission errors in the tv of the programmer fall under that ?

Well, I do not think that it goes against the rule. Every user had possibility to modify the setting of his TV set (which is impossible in DOSBOX). There is not any bug there, just subjective preferences... And if it was allowed in the original, DOSBOX should allow it too (when DOSBOX already supports the composite mode).
By the way: it should be possible to have the setting in DOSBOX.CONF...

Mirek

Which one do you would want. The hue or the saturnation ?

Hue. 5 degrees change per keypress.

Those settings are required to compensate for transmission errors. Why would dosbox need compensate for that as dosbox doesn't transmit a thing. (...) Would transmission errors in the tv of the programmer fall under that ?

Uh... the transmission errors don't occur within the tv, the transmission errors occur within the atmosphere and are usually only a problem when receiving via antenna (hence "terrestrial reception"). What you need the keys for is that yes, every programmer had a different TV with (more importantly) different settings on his TV (sometimes on purpose). You're not "fixing" a "bug" in the original game, you're just calibrating the "emulated TV". Microsoft Decathlon --- whose composite mode is not emulated at the moment --- even asks you to do just that.

Qbix wrote:

For the record there is only 1 CVS. however there are more than one people which compile it to executables. […]
Show full quote

For the record there is only 1 CVS.
however there are more than one people which compile it to executables.

• aep emulation - compiles it clean.
• ykhwong - adds a lot of patches.

To report "bugs about dosbox itself in the CVS" you should use aep emulation. But as that one was delayed a lot because of various reasons. a lot of people started using ykwongs build.

if you want to test out patches which aren't in the CVS yet. then you should ykwongs build and use that version to report bugs.

See here for more complete info and guidelines on DOSBox CVS builds. I also clarified the bug reporting section a bit.

Also, there seem to be new AEP and Gulikoza builds available now.

NewRisingSun wrote:

They didn't "really" support composite mode in that they didn't bother implementing it carefully, it's just a half-assed attempt at supporting it, if you will. You'll get SOME 16 colors, but those are not the ones the game is supposed to display.

Hmmm... but what DOSBox produce is totally wrong anyway, because it displays them when the games are in b&w CGA mode. Any chance of knowing what colors they produce in composite mode?
Anyway, this is good to know. I saw that Great Hierophant started this thread, maybe he'll see this tidbit and update his Zak McKracken FAQ.

NewRisingSun wrote:

Right. But don't be fooled --- FCEUltra's NTSC emulation is rather inaccurate, mostly the result of a wrong decoder matrix. Of course, since it's no longer being developed, there's no point in submitting an updated version.

What about Nestopia? It has both hue and saturation controls, and this hue control seems to produce different colors than FCE Ultra's hue control. Is this one also inaccurate?

Qbix wrote:

Fixed spellcasting 101 when dosbox is in cga mode.
it allready worked correctly in vga mode when starting "s101 cga"

I got the new aep CVS, and it doesn't seem to be fixed. When machine=cga, you still see composite-like colors in Spellcasting 101 instead of b&w graphics. The same still happens with Maniac's and Zak's b&w CGA mode.
You're right about the fact that the machine=vga mode was already ok, the stretched image I showed earlier was because of something in ykhwong's DOSBOX.CONF (although I didn't find the specific parameter). Once I deleted the file and loaded DOSBox clean, the graphics were displayed normally. I still think Kaminari got it backwards though, because DOSBox will never display composite colors when machine=vga.

Qbix wrote:

For the record there is only 1 CVS. however there are more than one people who compile it to executables. […]
Show full quote

For the record there is only 1 CVS.
however there are more than one people who compile it to executables.

• aep emulation - compiles it clean.
• ykhwong - adds a lot of patches.

To report "bugs about dosbox itself in the CVS" you should use aep emulation. But as that one was delayed a lot because of various reasons. a lot of people started using ykhwong's build.

Yes, I know that aep is the "official" CVS build, but the previous aep build didn't include the new composite algorithm, so I had to use ykhwong's build. Now that the new aep build is released and it does contain the new code, I'll use only it for further testing.
I was glad to find that the Indy3 ticking does not happen in the new aep build. It was apparently something unique to ykhwong's build.

Qbix wrote:

I'm against keys as I don't like having a lot of keybinding in dosbox. but the argument for f11 and f12 as those games don't recognise it, is a convincing one.

It's great to hear that there's a good chance that the next release of DOSBox will include hue control, as it seems important to a correct composite CGA and NTSC TV emulation.
Just one more suggestion - if it's possible, maybe the composite mode should be seperated from the regular machine=cga (e.g. machine=composite), because it seems to cause some conflicts, especially when b&w CGA is involved. Also, there are CGA palletes that we're "missing" because they would've been displayed only on RGB CGAs.

By the way, it's good to see that the AGI -cga switch works in the new aep CVS when machine=vga.

What about Nestopia? It has both hue and saturation controls, and this hue control seems to produce different colors than FCE Ultra's hue control. Is this one also inaccurate?

I believe the author stated in the readme that it was not quite accurate. Still, it is quite the improvement and is now up to Nintendulator's standard of compatibility (i.e. just a hairsbreadth shy of perfection.)

Anyway, this is good to know. I saw that Great Hierophant started this thread, maybe he'll see this tidbit and update his Zak McKracken FAQ.

Many of my FAQs are due for an update, just have to gather enough information to make it worthwhile. The thread has gotten awfully long, though.

It's great to hear that there's a good chance that the next release of DOSBox will include hue control, as it seems important to a correct composite CGA and NTSC TV emulation.
Just one more suggestion - if it's possible, maybe the composite mode should be seperated from the regular machine=cga (e.g. machine=composite), because it seems to cause some conflicts, especially when b&w CGA is involved. Also, there are CGA palletes that we're "missing" because they would've been displayed only on RGB CGAs.

Hue emulation is important because it compensates for the fact that most TVs were not professionally calibrated back in the day and everyone seems to remember something different. I second the idea of splitting composite CGA from RGB CGA, (this was done in Canadacow's old Tandy DOSBox build.)

SirGraham wrote:

I still think Kaminari got it backwards though, because DOSBox will never display composite colors when machine=vga.

Yep sorry, I got my c and v all mixed up in my previous post.

SirGraham wrote:

Qbix wrote:

Fixed spellcasting 101 when dosbox is in cga mode.
it allready worked correctly in vga mode when starting "s101 cga"

I got the new aep CVS, and it doesn't seem to be fixed. When machine=cga, you still see composite-like colors in Spellcasting 101 instead of b&w graphics. The same still happens with Maniac's and Zak's b&w CGA mode.

I fixed it right before I posted that message. It's therefore unlikely that AEP emulation has it allready in its build. I don't have the other 2 games you mentioned so I'm uncertain if they got fixed.

For now I don't see any reason to split off the cga composite mode emulation from the regular cga emulation.
The problems you mentioned aren't really problems. At least one of those (composite when BW is selected) has been (partly) fixed.

For now I don't see any reason to split off the cga composite mode emulation from the regular cga emulation.

If the low-res composite mode (320x200 based) will ever be added, you'll see the need.