Older computer monitors generally came in the following varieties:
Composite Mono (Apple II)
Composite Color (Apple II, Atari 8-bit, Commodore 64)
Analog RGB Mono (Atari ST)
Analog RGB Color (Amiga/Atari ST)
MDA
CGA/Digital RGB (Commodore 128)
EGA
VGA Grayscale
VGA Color

`Moe` wrote:

Well, I just wanted to point out that "for use with computers" and "being NTSC" do not actually coincide. Haven't seen any NTSC composite monitor back in those days.

There may be NTSC and PAL versions of composite color video signals. My experience with the PSX leads me to believe that the main differences, however, may be the number of scanlines and the refresh rate, and *not* color encoding. I could be wrong though, as I have no technical documentation to back it up.

Also, even early VCRs had composite video inputs and could modulate them into an NTSC (and probably PAL) RF signal for display on a TV. More commonly, many early computers and consoles had RF modulators built into them and the user would connect them to a TV's antenna input via a switchbox.

HunterZ wrote:

More commonly, many early computers and consoles had RF modulators built into them and the user would connect them to a TV's antenna input via a switchbox.

Iirc, the whole reason why early computers had RF modulators built in, is that most TVs of that era didn't have an antenna input to begin with. Thus, those computers (the Apple II for instance, although it didn't come with an RF modulator to avoid FCC trouble, but one could be purchased) broadcast a (weak) air signal, that you could tune your TV to. Of course, we're getting a bit off-topic here...

JAL

That may have been true in Europe and/or in the late 1970s, but I don't remember seeing any consoles or computers or TVs in the U.S. after 1980 (or so) that used anything but direct 300 Ohm (double screw terminal) or 75 Ohm (coax screw-on connector) RF connections. The purpose of modern RF modulators is to convert a composite video and audio signal into a signal that can be tuned on a cable or antenna TV (usually channel 3 or 4 in the U.S.), and they are most commonly used today in VCRs for connecting directly to older TVs that don't have composite video input.

Sorry for going off-topic.

When I was young, if I remember correctly, TVs generally had two pairs of screws, one where you could screw in the VHF antenna (channels 2-13) and the other where you would do the same for the UHF antenna (channels 14-68). I assume that was the way it had been done for decades, unless the TV itself came with a built-in antenna. I don't recall seeing the single screw connector until the mid-80's, but that is just me.

I think the first time I saw a 75 Ohm coax cable TV connector was on the early-80s Hitachi VCR that my dad bought (it also had pinch terminals for UHF input/output). By the mid-80s we had cable TV, which caused the 300 Ohm screw terminal VHF antenna input to be phased-out. You can still find matching tansformers to convert between the two types, inlcuding ones with both VHF and UHF antenna inputs; however, VHF-only transformers are more common due to the fact that many 90s TVs with coax VHF cable inputs still provided screw terminals for a UHF-only antenna.

Also, most U.S. UHF tuners could tune channels as high as 83.

HunterZ wrote:

That may have been true in Europe and/or in the late 1970s, but I don't remember seeing any consoles or computers or TVs in the U.S. after 1980 (or so) that used anything but direct 300 Ohm (double screw terminal) or 75 Ohm (coax screw-on connector) RF connections.

You are right, and I didn't recall correctly. I interpreted some information about it the wrong way.

JAL

So NewRisingSun, do you have any plans to try to integrate your findings into MESS? MESS has optional composite color emulation based on the information in http://bugzilla.mess.org/show_bug.cgi?id=431 but I don't think it's as correct as yours because text is hard to read and the colors seem wrong.

Their philosophy is accurate emulation regardless of CPU cost, so you could go hog-wild with color depth and slow techniques 😀

I just noticed these composite threads, so in case it's useful I can add a few notes: Re: the Mobygames composite mode screenshots, I added most of those; all of the ones I did were captured off of a true IBM CGA card. I believe most of them should be pretty accurate; Re: Ms. Pac-Man, yeah the hues are off in those. I'm not sure how that slipped by me, but I just double checked and the color in the new Dosbox shots is much closer (I'll have to submit some corrected versions to moby...). KQ1 in composite mode is indeed rather dark; my moby shots might overdo it slightly, but I think they're pretty close.

NewRisingSun wrote:

In the composite color mode, as opposed to any other mode, the graphics card doesn't generate ANY color. It just generates a monochrome signal with a continuous 3.579545 MHz signal, the color burst, on top of it.
.

Not necessarily true in some cases I think, though it could depend on what's considered composite mode. In 640x200, the foreground color could be altered to any of the 16 colors; on a composite monitor this seems to effectively provide a new palette of colors. Ms. Pac-Man utilizes this to flash the screen when a level is complete (on an RGB monitor it appears as the foreground color switching between high intensity white and low intensity blue. On a composite monitor in appears to adjust the brightness of the colors). Pitstop II uses a foreground color of high intensity green; on a composite monitor it provides a god aweful set of colors quite different from usual. Some games use 320x200 color mode, and depending on the palette and some clever dithering, this appears to provide quite a few colors on composite monitors. Don't know if it's truly composite mode, but some games refer to it as such, Spy Hunter and Microsoft Decathlon do this.

Overall I'm delighted to see Dosbox addressing the composite mode issues; I always thought emulating the color artifacting would be near impossible, but the results are looking quite good based on the screenshots posted here...

Wow, straight from the horse's mouth. Thanks Servo, and welcome to VOGONS 😀

One question: What do you have connected to the output of the CGA card in order to capture it?

I have the CGA output connected to a video stabilizer, then run the output from that into a tv capture card (both hops with just ordinary composite video cables). That intermediate step shouldn't be necessary, though I found for some reason if I connect the CGA straight to the capture card, I get a lot of horizontal banding in the colors (best description I can think of for that effect...). I'm not sure what's causing this, but it's not visible on a composite monitor at all, just with this particular capture card.

I just noticed these composite threads, so in case it's useful I can add a few notes:

Thank you, your presence is indeed most welcome!

Re: the Mobygames composite mode screenshots, I added most of those; all of the ones I did were captured off of a true IBM CGA card.

Did you also use a real IBM 5150 PC? I'm asking because we've discussed how the ROM font in your pictures is not 100% correct (shifted by one pixel), and the thing is that the ROM font in graphics modes is NOT a function is the CGA card, but of the PC's ROM BIOS (the CGA, unlike the EGA, does NOT come with its own BIOS), it's stored at F000:FA6E.

Re: Ms. Pac-Man, yeah the hues are off in those. I'm not sure how that slipped by me, but I just double checked and the color in the new Dosbox shots is much closer (I'll have to submit some corrected versions to moby...).

Good that we cleared that up. So much for that "trebor" person telling me what he "knows" for a fact...

KQ1 in composite mode is indeed rather dark; my moby shots might overdo it slightly, but I think they're pretty close.

Right... it writes 0x27 to the color select register 0x3d9, which makes things pretty dark.

Not necessarily true in some cases I think, though it could depend on what's considered composite mode. In 640x200, the foreground color could be altered to any of the 16 colors; on a composite monitor this seems to effectively provide a new palette of colors.

You're right, if the lower four bits of port 0x3d9 contain something other than 7 or F, the whole "monochrome" signal becomes "tinted". My point was that individual pixels' colors were the result of cross-color artifacts (hence this mode sometimes being called "artifact color").

So NewRisingSun, do you have any plans to try to integrate your findings into MESS?

I'm not going to mess with MESS' code (hohoho 😵), but I can send them some code if they ask for it.

I *think* my algorithm does this correctly. at least my original version, don't know if QBix' 256-color adaptation breaks this. I have never checked because I didn't know of any game that does this.

The (lower)bits of 3d9 are decoded the same way as the algorithm you send me.
The only things missing is the optimize text and the chromafilter.

I still hope oneday to implement the chromafilter, but NTSC signals aren't very comparable with RGB signals, which gives me some nasty problems when adapting it to 256 colours with a lookup table.

The screenshots in this thread which were made by me used the tvHueOffset set to 3.0. In my initial opinion/judgment/whatever that compensated a bit for the missing chromafilter.
However I reset this to 0.0 as NewRisingSun pointed out that it was wrong to do so.

This(hue=0.0) is how the current CVS contains the code.
This doesn't match the code of ykhwong builds from before 28-9-2005 as I send him the patch with the hue set to 3.0 in order to get some people testing it.

So the blue of the titlescreen of kq1 will be bit different. (attached it).

Qbix wrote:

I still hope oneday to implement the chromafilter, but NTSC signals aren't very comparable with RGB signals, which gives me some nasty problems when adapting it to 256 colours with a lookup table.

I'm ignorant about DOSBox internals - would it be possible to implement composite graphics emulation in DOSBox without it being limited to 256 colors?

The screenshots in this thread which were made by me used the tvHueOffset set to 3.0. In my initial opinion/judgment/whatever that compensated a bit for the missing chromafilter.
However I reset this to 0.0 as NewRisingSun pointed out that it was wrong to do so.

Will this noticably affect the controversial Ms. Pac-Man screenshots?

HunterZ wrote:

Qbix wrote:

I still hope oneday to implement the chromafilter, but NTSC signals aren't very comparable with RGB signals, which gives me some nasty problems when adapting it to 256 colours with a lookup table.

I'm ignorant about DOSBox internals - would it be possible to implement composite graphics emulation in DOSBox without it being limited to 256 colors?

There is some confusion about this.
Dosbox is limited to 256 unique colours at one time when using the current vga card emulation. Each of these colours can be 18 bit.
Those colours must be precalculated, before drawing the screen.

My adaptation calculates with the value of port 3d9 a set of colours which is used when drawing the screen. You can consider them to be in a table. each with an unique index (that one is limited to 256)
This is set of colours is fixed until the game decides to write a (different) value to the color select register 3d9

The draw_screen function generates indexes for each pixels on the screen by taking in account the Y variation(3 bits) and the color of the 4 bits it's part off.

This results in an emulation which doesn't interfere with the regular CGA palette(as at the moment the adaption requires 7 bits (128 colours) So the lowerhalf of the paltette(0x7f mask) bits is the same as in regular cga mode. (bit 7 is always set in the composite mode)

Futher it's quite efficient, because of this lookup system. (those unique indexes).
While I agree that accurate emulation goes above speed in this case, it's a nice side effect of the 256 unique index emulation.

Anyway for more details on the current algorithm you can browse the source.

• Look for VGA_Draw_CGA16_Line
• Look for cga16_color_select

The screenshots in this thread which were made by me used the tvHueOffset set to 3.0. In my initial opinion/judgment/whatever that compensated a bit for the missing chromafilter.
However I reset this to 0.0 as NewRisingSun pointed out that it was wrong to do so.

Will this noticably affect the controversial Ms. Pac-Man screenshots?

It won't make them pink. The effect is in the same order as the changes you see in KQ1. Anyway Will just make a screenshot of the first level and attach it, so you can judge yourself

I just finished testing with PitStop II.

Pitstop II uses a foreground color of high intensity green

So why are the "white" areas in your MobyGames screenshots yellow instead of green? 😀

Anyway, here are the results of my tests. The green picture is what I get with the "hue" control at the "default" position, the yellow picture is what I get with the "hue" control at minus 44 degrees, which kind-of matches your MobyGames screenshot. The only difference is that the limits of the race track in the MobyGames shots are of a different color than the "grass", while they are the same in my shots. I wouldn't know how that's possible, as they would both be "gray" without the tint. On the other hand, I see your shots were taken on a different race track, so maybe that's the reason.

Curiously enough, minus 44 degrees is also what makes Ms. Pac-Man pink, so I guess you took the PitStop II screenshot with the same hue setting as the one you had when taking the Ms. Pac-Man screenshot. Minus 44 degrees is also what turns the CGA's normal colors cyan and pink into green and blue, which is exactly what we see in the MobyGames PitStopII title screen shot (the game is NOT yet in composite color mode there, just normal mode 4).

Thanks for the explanation Qbix. It seemed odd to me that advanced CGA emulation should be limited by VGA and not the capabilities of the real video hardware on the host system on which DOSBox is running, but now I understand better from your explanation why this is. Perhaps once 15/16-bit SVGA/VESA emulation becomes a mature feature of DOSBox, it will become easier to add things like the chromafilter functionality to the composite CGA emulation using that infrastructure?

NewRisingSun wrote:

Did you also use a real IBM 5150 PC? I'm asking because we've discussed how the ROM font in your pictures is not 100% correct (shifted by one pixel), and the thing is that the ROM font in graphics modes is NOT a function is the CGA card, but of the PC's ROM BIOS (the CGA, unlike the EGA, does NOT come with its own BIOS), it's stored at F000:FA6E.

I didn't know that about the CGA card, I had thought the font was in the CGA roms. For most shots I used a Tandy 1000 so that would likely explain the font issue; I have a PC (I think it is a 5150) somewhere in a closet so I'll have to dig that out. Apparently the Tandy is off on everything though; the composite output from the Tandy CGA changes all the colors, blue->red, etc...

It looks like I may have used that same hue setting for some other screenshots as well; I think the problem is I was comparing colors to those on the tv I was using at the time (to which the screenshots are pretty accurate). Now that I'm going back again and comparing with the new tv I'm using the "default" hue setting is looking more accurate. The default hue setting on the old set provided colors that were completely wrong; I recalibrated the set with video essentials and thought I had everything pretty close, so I tried to match those colors when capturing. guess I'll have to do some more fixing...

how does pitstop II switch to composite mode ? I only see lot's of screen mode switches. but no writes to 3d8. (except for the int 10 0 calls that write stuff to it)

CS:0x4556, or offset 0x4756 in the EXE file, in the DOS conversion from "Retrograde Station".