The Spellcaster games are really using high-resolution EGA modes, @ 640x350. That resolution isn't very suitable for integral scaling on modern displays. Even though letterboxing would result, DOSBox should extend its scalers to modes containing 640 and 720 horizontal pixels. Also, I would prefer to make my own decision about whether I want 640x200 line modes doubled to 400 lines or not.

On another note, a fellow on the AtariAge forums had something interesting to contribute about CGA color composite graphics (extremely unusual that):

Would have been much nicer if [IBM] fed the [IBM PC Portable's built in amber monochrome composite] monitor off a luminance-only […]
Show full quote

Would have been much nicer if [IBM] fed the [IBM PC Portable's built in amber monochrome composite] monitor off a luminance-only signal instead of the absolutely horrid composite color signal output by the CGA. I wonder why IBM even bothered with color-modulating the composite output in video mode 3, given that the colorburst timing is wrong so colors come out as ugly striped monochrome anyway.

The 80-column text mode doesn't give a composite color signal. It gives a nasty stripey black and white signal. If the chromaburst actually appeared in the right spot, it might actually be useful but as it is it's worse than useless.

The only program I've seen that looks better on a composite monitor in hardware mode 3 than hardware mode 2 is a game called "Round 42". That particular game sets the border color to yellow, and the yellow border kinda sorta works as a pseudo-colorburst. Otherwise, everything looks better in mode 2 whether it uses color (which then appears as greyscale) or not.

The only games I've seen that look good on a composite color monitor are those that use a 'tweaked' mode 6. Ironically, the 640x200 mode is the only mode that can produce a decent color display on a composite monitor, and yet it's the only mode that doesn't provide the option to enable colorburst.

While we can appreciate his irony at IBM's allowing composite color counterparts to all RGB modes in the BIOS except Mode 6, I ask whether his assessment of composite color is a fair one when displaying text. We already know that composite color in a 320 mode will vary from manufacturer to manufacturer.

We already know that composite color in a 320 mode will vary from manufacturer to manufacturer.

We do?

It doesn't matter here, as the number of text mode games is small, and the normal RGB emulation is enough for them. I don't trust these Atari people anyway --- like their incorrect claim that the color signal oscillates at 3.58 MHz (see page 3) 😉

I only had a CGA clone, but text mode 3 wasn't "stripey" --- while text became difficult to read because of the heavy color bleeding, solid colored areas were displayed properly, even without a yellow border color. Can't imagine that IBM would put out a sloppy product, and I also wouldn't know why the text mode would be screwed up if the graphics mode 4 looks all right in Servo's screenshots as well, and he uses an original IBM C/GMA.

I also never heard of that problem before, so maybe it's something in these people's setup --- since the CGA doesn't have its own clock crystal, it has to take the color burst frequency from the host system, and if that host system doesn't properly provide that clock signal, the result might be as described. That's my take on the subject, maybe I'm wrong.

Oops, my mistake. I meant to say from software developer to developer, as some actually optimized their 320 graphics for color composite while others did not. As far as graphics using text modes games go, I only know of seven:

Bricks/Wrecking Ball (Seem to be same game)
ICON (ICON demo)
Moon Bugs
Round 42
Styx
The Exterminator
The Seven Spirits of RA

HunterZ wrote:

That spellcaster widescreen issue may be because the games are running in something like 640x200 and you don't have aspect-correct stretching enabled.

Well, I checked DOSBOX.CONF and the only thing that seems similar to what you offered is the 'aspect' parameter. I changed that to aspect=true but there was no difference. The game still ran in this weird "widescreen" mode. Not only that, but with aspect=true the game text became a little weird (it isn't that obvious but if you take a good look you can see it).
Could it just be a problem of sorts in DOSBox, and not really something that can be solved by changing parameters in DOSBOX.CONF?

Can you tell me what exactly did you change in MESSUI.INI to achieve this effect?

I don't know what messui.ini setting it would be; in the macmess gui though I click on the options button, and there are several choices under renderer; software or opengl, and a checkbox for "smoothing", etc...I thought I remembered the default as having "smoothing" on, which makes full screen mode rather blurry (and then procedes to give me a headache). Turned off the scaling looks nice and sharp. I haven't checked to see if DosBox provides equivalent options, but wanted to check to make sure you were comparing the two emulators with similar enough full screen modes enabled.

Regarding the AtariAge quote, my results were different (though still not great). I didn't see any variety of the striped monochrome effects, though as NewRisingSun noted the text is very difficult to read; lots of color artifacts and bleeding. Testing Round 42 the border is actually red, not yellow. Also interesting on the title screen the border flashes colors, which does affect the color seen on a composite monitor! (on the RGB monitor it looks as if only the border changes color, on composite monitor it looks as if there is no border with the screen changing palettes) Also interesting the colors don't match; blue on RGB appears red on composite, etc... My other test (Moon Bugs) didn't work well at all; on a composite monitor the colors were much too dark with some not even visible. This is all IBM CGA card on a Tandy; I haven't tried other combinations yet.

I didn't see any variety of the striped monochrome effects, though as NewRisingSun noted the text is very difficult to read;

Here's how my algorithm emulates the composite monitor in text modes. As Servo stated, it's hard but not impossible to read. The B/W pictures are with the color burst bit off.

"Round 42" indeed sets a red border, showing that those AtariAge guys REALLY have no clue what they're talking about. Again, for text mode games, there's nothing to be gained from emulating a composite look; the normal register-level RGB emulation is enough. DosBox seems to emulate Round 42 correctly.

Servo wrote:

Can you tell me what exactly did you change in MESSUI.INI to achieve this effect?

I don't know what messui.ini setting it would be; in the macmess gui though I click on the options button, and there are several choices under renderer; software or opengl, and a checkbox for "smoothing", etc...I thought I remembered the default as having "smoothing" on, which makes full screen mode rather blurry (and then procedes to give me a headache). Turned off the scaling looks nice and sharp. I haven't checked to see if DosBox provides equivalent options, but wanted to check to make sure you were comparing the two emulators with similar enough full screen modes enabled.

Oh, you were using MESS for Mac. I'm using the Windows port, and I can't see a "renderer" under Options, so perhaps it's only in the Mac port.
But basically, you're saying that the DOSBox composite emulation is more accurate than MESS's because of the "fuzziness"?

NewRisingSun wrote:

Here's how my algorithm emulates the composite monitor in text modes.

That's not the same algorithm that's currently incorporated in DOSBox, is it? There's also your algorithm for the composite mode of Serenia and Ulysses which is more impotant than the text composite mode, and that's not incorporated as well.

By the way, I noticed that when my TV-out is in use (I have an NVIDIA GeForce FX 5200), DOSBox displayes everything in "widescreen"! (this has nothing to do with the Spellcasting widescreen problem I talked about some posts ago) That's very weird. Incdentally, screenshots captured while in this "widescreen" mode appear normal.

But basically, you're saying that the DOSBox composite emulation is more accurate than MESS's because of the "fuzziness"?

Absolutely! As the Apple II community will tell you, the closer you can get to a composite monitor, the better the video emulation if you are using a composite video mode uses artifact colors.

That's not the same algorithm that's currently incorporated in DOSBox, is it? There's also your algorithm for the composite mode of Serenia and Ulysses which is more impotant than the text composite mode, and that's not incorporated as well.

No, NewRisingSun's algorithim is more advanced than the one DOSBox uses. Still, DOSBox's is miles better than MESS's simply nibble=pixel method. Serenia and Ulysses use a 320x200 mode even for composite graphics. This requires somewhat different tweaks compared to the usual 640x200 mode on a composite monitor, as NewRisingSun can explain in much more detail. DOSBox, unlike MESS, cannot support this mode unless it allows the user to distinugish the type of monitor he is using, composite or RGB. Otherwise it will always appear in RGB.

By the way, I noticed that when my TV-out is in use (I have an NVIDIA GeForce FX 5200), DOSBox displayes everything in "widescreen"! (this has nothing to do with the Spellcasting widescreen problem I talked about some posts ago) That's very weird. Incdentally, screenshots captured while in this "widescreen" mode appear normal.

Remember that the 320x200/640x200 graphics themselves are suitable for widescreen, i.e. have a 1.6:1/2.6:1 pixel ratio. High resolution 640x480 graphics won't show this. I would think it may have something to do with the GeForce. Did you try all rendering modes?

NewRisingSun's algorithim is more advanced than the one DOSBox uses.

And slower, too.

This requires somewhat different tweaks compared to the usual 640x200 mode on a composite monitor, as NewRisingSun can explain in much more detail.

Well, you have the chip-generated color in addition to the "regular" artifact color.

DOSBox, unlike MESS, cannot support this mode unless it allows the user to distinugish the type of monitor he is using, composite or RGB

And HiColor/TrueColor support. You can't use a Gaussian filter with palettized modes.

Well, you have the chip-generated color in addition to the "regular" artifact color.

I assume you mean that each pixel is not simply on or off, white or black, in the 320 modes like they are in the 640 modes. Since the 320 mode can display four colors, that is four shades of luminosity as opposed to the one shade of the 640 modes. I imagine that must complicate things somewhat. It must become even more fun in the text modes, which should be capable of sixteen shades of gray in the mono modes.

And HiColor/TrueColor support. You can't use a Gaussian filter with palettized modes.

Hence the speed issue which continually pops up in other contexts. Those modes are slower than VGAish mode DOSBox uses, which is why the authors are reluctant to support 16-bit SVGA and VESA modes, used in some later DOS games.

Also, I don't suppose this is the time to be ambitious, but I note that other graphics adapters also have a composite video output, namely the Tandy 1000 (A, HD, EX, HX, TX, SX) and IBM PCjr. (I believe that the IBM EGA card, which has two RCA jacks, does not use them at all.) Assuming that they will demonstrate the same behavior in the CGA modes as the CGA itself, what about their additional 160x200x16, 320x200x16 and 640x200x4 modes?

Since the 320 mode can display four colors, that is four shades of luminosity as opposed to the one shade of the 640 modes.

Well, not only do you have four shades of gray, but also the color difference signal modulated on top of it. The "monochrome bit" in port 3d8 not only turns off the color burst but also the I and Q signal generation. Compare the following three pictures and see how the modulated I/Q signals appear in the second picture. Remember, a composite signal is just a monochrome signal where certain patterns (or frequencies in analog terms) will be replaced with a color by the TV's color decoder, which is what an algorithm has to emulate. Basically, the second picture is the algorithm's input, and the first picture is its output.

what about their additional 160x200x16, 320x200x16 and 640x200x4 modes?

They always turn off the color burst. At least that's how I understand the following lines from Sierra AGI's JR_GRAF.DRV's original source code:

1jrig:
2        mov     ax,89h          ;initialize graphics: 320x200 16 color mode
3        int     10h
4        mov     ah,11           ;set background color to black
5        xor     bx,bx
6        int     10h
7        mov     al,0bh          ;turn on color burst (BIOS error in TANDY 1000)
8        mov     dx,3d8h
9        out     dx,al
10        call    jrsh            ;set horizontal sync position

For some reason they think it's a "BIOS" error.

I understand the first picture and the third, but the second remains a mystery.

The first picture shows what happens when the color composite bit is turned on on a color composite monitor. The third picture shows what happens when it is turned off on either a color or monochrome composite monitor.

I don't understand how the second picture could be different from the third picture when viewing the video output on a monochrome composite monitor. How could generating a color burst signal and modulating the I and Q signals affect a monochrome monitor in any way? A monochrome monitor technically does not know NTSC, PAL, SECAM or any other color encoding system. It only knows luminence, the Y signal and anything extra is filtered out.

The color burst is something like a signal to the TV circuitry that there will be color on this scan line. The video source then modulates the I and Q components, which the monitor compares to the color burst signal to determine which color to display. In early video game consoles, the video controller circuitry would have a set palette and each "color" is essentially the modulation information to set that color at a specific amplitude and luminence.

Now, by contrast and if I remember the earlier discussion, In color systems based on artifact colors, the video controller circuitry only sends a luminence signal and a color burst signal. Because the luminence signal has much more bandwith a color composite monitor's I/Q modulating circuitry can handle, the result is that the modulating circuitry cannot properly transition and it produces unintended colors. I know I am missing something here...

How could generating a color burst signal and modulating the I and Q signals affect a monochrome monitor in any way? A monochrome monitor technically does not know NTSC, PAL, SECAM or any other color encoding system. It only knows luminence, the Y signal and anything extra is filtered out.

Because the color information is not "anything extra"; it's part of the composite signal. A monochrome monitor, because it doesn't know color, doesn't know that the signal is composite and thinks all parts of the signal are monochrome information, and thus does NOT filter out the color information which is visible as fine detail in the monochrome picture.

In color systems based on artifact colors, the video controller circuitry only sends a luminence signal and a color burst signal.

Again, 320x200x4 mode is not entirely based on artifact colors but a mix of chip-generated and artifact colors. Basically, pure "artifact color" graphics just mean the programmer tries to approximate the I/Q modulation by setting black/white pixels accordingly. In 320x200x4 mode, the programmer tries to approximate additional I/Q modulation by setting colored pixels accordingly. The result will always be "approximated" because the CGA has a 'pixel clock', in other words a discrete signal, whereas ideally NTSC is a continuous signal.

I see, so while a monochrome composite monitor might ignore the color burst signal, after all it is only a reference, the modulated I and Q signal combines with the main luminence signal to produce unintended luminence signals. So it follows if you say that the IBM CGA card sends both a color burst signal and a modulated I and Q signal if bit 2 of port 3d8h is 0 that the modulated I and Q signal will still affect the monochrome monitor.

Basically, pure "artifact color" graphics just mean the programmer tries to approximate the I/Q modulation by setting black/white pixels accordingly.

I assume that this is essentially what the CGA card does in its 640 composite color mode. It also sounds like what the Apple II does in its high resolution (280x192) and double-high resolution (560x192) color composite modes and the Atari 8-bit's 320x192 mode F.

In 320x200x4 mode, the programmer tries to approximate additional I/Q modulation by setting colored pixels accordingly. The result will always be "approximated" because the CGA has a 'pixel clock', in other words a discrete signal, whereas ideally NTSC is a continuous signal.

It sounds almost like artifacting upon artifacting and I can appreciate the extra work to get it to look right. Especially as almost every game that officially supported composite graphics set a 640 pixel mode to do it. The only game that I know of that uses the 320 mode officially is Microsoft Decathlon.

In 320x200x4 mode, the programmer tries to approximate additional I/Q modulation by setting colored pixels accordingly.

Thus instead of plotting a pixel to be on (white) or off (black), he has four pixel possibilities. Depending on which color the pixel would be as shown on an RGB monitor, that would be four different modulations of the I and Q signal. This is opposed to two modulations in the 640 mode.

I see, so while a monochrome composite monitor might ignore the color burst signal

Then it's not a "monochrome composite" monitor, but just a "monochrome" monitor. 😀

The only game that I know of that uses the 320 mode officially is Microsoft Decathlon.

"Officially"? Ok, the words "composite monitor" don't appear in the Ultima 3 documentation, but the results speak for themselves, I think.

Thus instead of plotting a pixel to be on (white) or off (black),

Actually, its (black) or (contents of 3d9).

he has four pixel possibilities.

And considering that color 0 may be set to any of the 16 colors, you're in for quite a lot of possible composite colors...

Then it's not a "monochrome composite" monitor, but just a "monochrome" monitor

I use the term "monochrome composite" monitor, say an Apple Monitor II, to distinguish from a monochrome TTL monitor, say an IBM 5151. One relies on fluctuations in the analog voltage level, the other on digital on/off signals to paint pixels.

"Officially"? Ok, the words "composite monitor" don't appear in the Ultima 3 documentation, but the results speak for themselves, I think.

I think that Ultima II, III and IV support for composite color is unofficial but clearly intended. (Ultima I and V offer very poor support for composite color because their CGA tiles and graphics are straight conversions of the EGA tiles.) If it was intended, then it would likely have been mentioned in the PC Reference Card that came with these ports. I often wondered why the fanbase never caught on with all those serrated graphics?

Also, because you can set the foreground color in the 640 modes to any of the 16 RGB colors, you can have some extra choice in how exactly the color composite graphics should appear if you apply the logic of the 320 modes to the issue. Pitstop II is the only game I can think of that does not use a gray or white foreground color in the RGB version of its composite color mode.

I also notice that the issue with King's Quest in Tandy mode (text on the opening scroll being serrated) has been fixed. Good work.

If it was intended, then it would likely have been mentioned in the PC Reference Card that came with these ports.

Uh, have you ever seen Ultima 3's PC reference card? 😉

I often wondered why the fanbase never caught on with all those serrated graphics?

I think if there's a better looking version out there, people are willing to accept that the PC version might look like crap, even though it's only due to configuration issues.

I have seen half of the IBM Player Reference Card for Ultima II and it doesn't mention graphics adapters at all and neither does the box.

Sure, there are better looking versions of Ultima III. The initial (APL, A8, C64, IBM) releases were all done in 1983. The better looking versions were done about three years later on advanced graphics hardware.

I think when people saw the serrated graphics, they just assumed it was a lazy transplant of Apple II graphics, which also look serrated when connected to a composite monitor. Because the games had no setting for color composite graphics, no one ever thought they would look different on a color composite monitor. Also, the IBM releases were somewhat obscure and relatively few people played them back in the day. Being a business machine, knowledge of the gaming-friendly color composite video modes was probably not known to the average user.

My point was that Ultima 3's reference card is so crappy that I'm not surprised at all they wouldn't mention it. It also doesn't explicitly tell you how to run the game. I wouldn't call that knowledge "unofficial" either.

I don't think "no one" ever knew that composite is the way to go; those who had a composite monitor for games that explicitly used it, like King's Quest, probably also tried it with other games and found that some would look nicer. And then of course there were monitors that had both composite and RGBI inputs, according to trebor.