Great Hierophant wrote:

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.)

Ok, I'll use Nestopia then instead of FCE Ultra. Note that one thing that is wrong in Nestopia but correct in FCE Ultra, is that in Nestopia the hue control affects PAL mode, and it's not supposed to. In FCE Ultra, when in PAL mode, the hue control is disabled.

Great Hierophant wrote:

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.

Where did you take the info about Zak's composite support for the FAQ, btw? The game's PREFS file does seem to indicate some composite support, because if you turn composite ON the pallete changes (in the enhanced version of Zak turning composite ON is meaningless). However, NewRisingSun said that Lucasarts games didn't support composite mode.

Great Hierophant wrote:

I second the idea of splitting composite CGA from RGB CGA, (this was done in Canadacow's old Tandy DOSBox build.)

It was also done in MESS.

Kaminari wrote:

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

It's good that we have that settled. There are more than enough variations as it is 😀

Qbix wrote:

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.

You mean Zak and Maniac? If Spellcasting 101 has been fixed, then probably so were they, as they behaved in the same way (i.e. showing fake composite colors when in b&w CGA mode while machine=cga). I guess we'll know for sure when a new CVS is released.

Qbix wrote:

The problems you mentioned aren't really problems. At least one of those (composite when BW is selected) has been (partly) fixed.

Why partly?

NewRisingSun wrote:

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.

I think it's important to have this mode as well, because the ultimate goal is to have a complete emulation. That's the mode that Microsoft Decathlon and Ulysses/Serenia use, right?
Btw, what conflict will be caused if the composite of DOSBox will support this mode and won't be seperated from the regular CGA mode?

Partly because I don't know if the other 2 games were fixed.
Behaving the same visually for you gives no garantees on how the game sets the different bits and bytes in the emulation. So until confirmed that the other games work ........

However, NewRisingSun said that Lucasarts games didn't support composite mode.

That's not what I said. I said "LucasArts didn't REALLY support it", "really" meaning putting much effort into it to make it look good. You'll get some new colors on a composite display, but not the right ones; it's basically unusable. I'm testing the Maniac Mansion Demo here.
Looking at what the game writes in composite mode into the CGA's video memory, the programmer basically assumed that the colors in 640x200 composite mode are like the RGBI colors, they're not. In RGBI, color 1 is blue and color 2 is green, color 13 is purple and color 14 is yellow. With composite colors, it's the other way around --- 2 is green, 1 is blue, 13 is yellow. As a result, with "COMPOSITE ON" in the PREFS file, the grass becomes blue, the "Maniac Mansion" logo becomes pink. That's obviously not right. Basically, the game treats the composite mode like Tandy's mode 8 (160x200x16), which in fact the game uses on a Tandy computer.

My explanation for this is that the programmer heard somewhere that composite mode is "just like Tandy's mode 8" and treated it accordingly, without ever testing it on a real CGA+composite combination. In that sense, LucasArts didn't REALLY support composite mode, if though they claim they did.

The game looks actually MORE accurate on a composite monitor with "COMPOSITE OFF" in the PREFS file; here the grass is cyan (which can be adjusted to become green with the hue control), and the Logo is a very pale yellow. Faces are purple, however, and browns are blue, so this is not right, either.

Btw, what conflict will be caused if the composite of DOSBox will support this mode and won't be seperated from the regular CGA mode?

"this" mode is just the normal 320x200x4 mode. If you emulated the composite look without separating it from the RGB look, you'll lose the RGB look. This is because there's no way of determining if the game desires the composite or the RGB look just by looking at what the game writes to the CGA's register/memory --- whether the RGB or the composite look is the correct one is purely empirical.

NewRisingSun wrote:

As a result, with "COMPOSITE ON" in the PREFS file, the grass becomes blue, the "Maniac Mansion" logo becomes pink. That's obviously not right. Basically, the game treats the composite mode like Tandy's mode 8 (160x200x16), which in fact the game uses on a Tandy computer.

My explanation for this is that the programmer heard somewhere that composite mode is "just like Tandy's mode 8" and treated it accordingly, without ever testing it on a real CGA+composite combination. In that sense, LucasArts didn't REALLY support composite mode, if though they claim they did.

Ok, but if perfect composite emulation is achieved, then it should display the right "wrong" colors for these games, shouldn't it? 😁 However, in the current CVS, when machine=cga and composite is ON, instead of showing composite colors, you just see what you'd see if machine=vga (or on a regular VGA screen). Only when you switch to b&w CGA mode inside the game (Shift-B), you get composite colors (although Qbix might have fixed that), and it doesn't matter if composite is ON or OFF, but these are not the right "wrong" colors, i.e., the logo is yellow instead of pink and the grass is gray instead of blue. When machine=tandy, by the way, and the game is in Tandy mode (Shift-T), you just get the same EGA colors this game normally shows. I don't know if it's correct.
I think MESS totally botched the Tandy emulation for this game, because you just see the same 4 colors you'd see on a regular VGA when the game is in CGA mode (Shift-C) and composite is ON. However, MESS's CGA composite emulation of Maniac seems close to what you described:

MESS 0.100, composite in PREFS is ON

The logo looks more peach than pink, but the grass is definitely blue. So, does MESS do it "correctly"? And how come DOSBox ignores these games' "wrong but existing" composite mode?

NewRisingSun wrote:

The game looks actually MORE accurate on a composite monitor with "COMPOSITE OFF" in the PREFS file; here the grass is cyan (which can be adjusted to become green with the hue control), and the Logo is a very pale yellow. Faces are purple, however, and browns are blue, so this is not right, either.

Hmm... I thought that when a CGA game does not have any specific support for composite mode, what you'd get on a composite monitor is just the regular 4 colors graphics but with artifacts.
Anyway, again, MESS seems close to your description:

MESS 0.100, composite in PREFS is OFF

Do you think DOSBox's algorithm should support this mode too? After all, that what would have happened on a real composite CGA. Btw, you used the demo of the original version, not the enhanced version, right?

NewRisingSun wrote:

"this" mode is just the normal 320x200x4 mode. If you emulated the composite look without separating it from the RGB look, you'll lose the RGB look. This is because there's no way of determining if the game desires the composite or the RGB look just by looking at what the game writes to the CGA's register/memory --- whether the RGB or the composite look is the correct one is purely empirical.

So, as long as there's no seperation, there can't be support in DOSBox for the composite mode of games like Ulysses and Serenia?

I think the only true test is if the game clear the color burst bit, bit 2 of register 03D8h.

Modes 0, 2, 4 do not, therefore all games that use those modes will show color on a composite color monitor. Maybe not the right color or the best color, but some color all the same. (Serrated CGA graphics are clear indicators that the a color composite monitor was contemplated.)

Modes 1, 3, 5 do, so the graphics should appear in grayscale on a composite monitor. As mode 5 games use the alternative palette when connected to an RGB monitor (cyan, red, white + background), these games are easy enough to identify and few in number. In fact, the only example I can think of is Chuck Yeager's Advanced Flight Trainer, which also has a separate mode for composite color.

Mode 6 (640x200) does not have a separate mode when the color burst is cleared as when it is set. The emulator must monitor the bit to determine whether the bit is set or cleared. If that is unworkable, then it should separate the RGB and Composite CGA modes, whereby the game is always in monochrome in the RGB mode and colorful in the composite mode. (A composite monitor would show the game in black and white, but the high resolution may make it difficult to resolve the graphics on a composite monitor.)

Let me try to clear things up a bit. There are two ways a game can utilize the artifacts of a composite monitor:

1. Select the black and white 640x200 graphics mode, then enable the color burst bit. Some games however set BIOS mode 4 (320x200 mode 4), then write directly to the port registers to set the 640x200 mode. This is done so that the BIOS text output functions will print the font at double-width. This is emulated by MESS and DosBox. This is used by all Sierra games after 1983.

2. Select the 320x200 4-color mode (BIOS mode 4), then arrange the dots in such a way that the artifacts that will inevitably result on a composite monitor result in a desired result. Of course, games with "normal" (i.e. not composite-optimized) graphics also select BIOS mode 4 if they don't want the "alternate" palette, and those will have unnecessary artifacts on a composite monitor. This method is only emulated by MESS. This is used by some Sierra games until 1983, as well as Ultima 2 and 3, and most ingeniously, Microsoft Decathlon.

BIOS Mode 5 on the other hand appears monochrome (notice the difference between "monochrome" and "black&white") on a composite monitor, so there are no artifacts.

How is an emulator to decide whether to emulate composite artifacts or not?
a) Artifacts must be emulated when port 0x3d8 contains 0x1a (see 1.).
b) Artifacts must never be emulated when port 0x3d8 contains 0x1e (original BIOS mode 6) or 0x2e (BIOS mode 5).
c) Artifacts may or may not be needed when port 0x3d8 contains 0x2a (BIOS mode 4). This can only be decided by the user (i.e. "empirically") (see 2.).
d) Artifacts should not be emulated in any text modes. Although a real composite monitor would show artifacts in color text modes, there's nothing to be gained from them.

Obviously, only point c) requires user cooperation, everything else can be decided by the emulator. This does not have to be solved by separating "machine=cga" into "machine=cgargb" and "machine=cgacomposite"; I also could imagine switching between RGB and composite display using a function key, which of course would only be needed in mode 4 (or to be more precise, when port 0x3d8=0x2a, see c)). I actually would prefer that solution, though I'm aware that QBix doesn't like to add more function keys. 😀

However, in the current CVS, when machine=cga and composite is ON, instead of showing composite colors, you just see what you'd see if machine=vga (or on a regular VGA screen).

I just debugged the executable. The "COMPOSITE ON" is even more of a hoax than I actually thought. Even with "COMPOSITE ON", the game remains in regular BIOS mode 4, the method described above in 1. is not used at all. All the game does with "COMPOSITE ON" is select BIOS mode 4, but write the Tandy pixel data, instead of the regular CGA pixel data, to video memory. What a bunch of nonsense! Forget about the "COMPOSITE ON", it's not good for anything.

Only when you switch to b&w CGA mode inside the game (Shift-B), you get composite colors (although Qbix might have fixed that),

Right. B/W mode is just the normal colorless BIOS mode 6, regardless of the PREFS "COMPOSITE" setting. That DosBox showed composite colors is the bug mentioned within this thread.

When machine=tandy, by the way, and the game is in Tandy mode (Shift-T), you just get the same EGA colors this game normally shows. I don't know if it's correct.

Well, of course it is. I don't know why people assume that Tandy graphics are any different from EGA graphics, at least concerning the colors displayed (the memory layout is of course completely different).

I think MESS totally botched the Tandy emulation for this game, because you just see the same 4 colors you'd see on a regular VGA when the game is in CGA mode (Shift-C) and composite is ON.

Yes, MESS messes up that mode. DosBox displays it correctly color-wise, but the aspect ratio is wrong.

The logo looks more peach than pink,

That's what I meant to say, but didn't. 😉

So, does MESS do it "correctly"?

Yes. MESS' composite emulation is ok color-wise, all it needs is a hue control and a better luma filter that keeps the text readable. Nevertheless, I can't learn anything from the MESS source because it doesn't actually calculate the color values like I do, but just has the output from a TV-card hard-coded as hexadecimal RGB values into the source, obscuring the way these colors came about.

I thought that when a CGA game does not have any specific support for composite mode, what you'd get on a composite monitor is just the regular 4 colors graphics but with artifacts.

That's what I said, isn't it.

Do you think DOSBox's algorithm should support this mode too?

No, I'm working on that. Remember my Ultima 3 pictures on the QuestStudios board?

Btw, you used the demo of the original version, not the enhanced version, right?

Yes. I once had the full original version, but somehow I can't find it anymore.

So, as long as there's no seperation, there can't be support in DOSBox for the composite mode of games like Ulysses and Serenia?

Not without giving up the sharp RGB-like display of mode 4.

If the user has to make a judgement call in some cases as to whether or not composite mode should be used, it seems to me that it's worth considering adding the option to bind a hotkey for toggling composite output emulation on the fly (if this is possible).

NewRisingSun wrote:

This does not have to be solved by separating "machine=cga" into "machine=cgargb" and "machine=cgacomposite"; I also could imagine switching between RGB and composite display using a function key, which of course would only be needed in mode 4 (or to be more precise, when port 0x3d8=0x2a, see c)). I actually would prefer that solution, though I'm aware that QBix doesn't like to add more function keys. 😀

I also think that a function key would be more comfortable, but now that F11 and F12 are taken by the hue control, what can be used?

NewRisingSun wrote:

I just debugged the executable. The "COMPOSITE ON" is even more of a hoax than I actually thought. Even with "COMPOSITE ON", the game remains in regular BIOS mode 4, the method described above in 1. is not used at all. All the game does with "COMPOSITE ON" is select BIOS mode 4, but write the Tandy pixel data, instead of the regular CGA pixel data, to video memory. What a bunch of nonsense! Forget about the "COMPOSITE ON", it's not good for anything.

Well, it doesn't really important for the Lucasfilm games, apparently, but the ultimate goal is that DOSBox's composite emulation will be as close as possible to the real thing, so the Lucasfilm games still have to look like they did on a real composite monitor.

NewRisingSun wrote:

I think MESS totally botched the Tandy emulation for this game, because you just see the same 4 colors you'd see on a regular VGA when the game is in CGA mode (Shift-C) and composite is ON.

Yes, MESS messes up that mode. DosBox displays it correctly color-wise, but the aspect ratio is wrong.

right, let me make it more clear with a screenshot:

NewRisingSun wrote:

Yes. MESS' composite emulation is ok color-wise, all it needs is a hue control and a better luma filter that keeps the text readable.

I thought that DOSBox CVS with your algorithm shows better colors than MESS (KQ1 PC booter, to name one game), and that the only advantage MESS have is that it recognizes more composite usage methods by games and has a separate emulation mode for composite and RGB. But now you're saying that MESS's colors are also correct, is that simply because you set the fixed hue of your algorithm to a different value than MESS? So the colors are essentialy the same in DOSBox CVS and MESS?

but now that F11 and F12 are taken by the hue control, what can be used?

You could put +Hue on F12, -Hue on Shift-F12, and RGB/Composite switch on F11.

But now you're saying that MESS's colors are also correct, is that simply because you set the fixed hue of your algorithm to a different value than MESS? So the colors are essentialy the same in DOSBox CVS and MESS?

MESS displays at Hue=0. DosBox CVS automatically switches to Hue=-15 for KQ1. Once the Hue Control is added, the auto-switch will be removed, and DosBox wil somewhat look like MESS color-wise, but you can use the Hue Control to change the Hue value to -15 or whatever you like. I personally prefer Hue=0 with some Red Boost, but that won't be included in DosBox.

Basically, the game (Maniac Mansion) treats the composite mode like Tandy's mode 8 (160x200x16), which in fact the game uses on a Tandy computer.

I don't understand how this is possible on an RGB monitor. If it does, then how does it get the regular text characters to display properly? Those characters are designed for the 320x200 modes, graphics or text. In a 160x200 mode they would be stretched to double size, just like in the 640x200 mode they are squeezed to half size. Either that or you could only get 20 characters per row instead of the 40 that Maniac Mansion uses. The Atari and Commodores could get by with scanline interrupts that allowed switching modes by scanline, but the Tandy 1000 would be capable of that, would it? Judging by the "sqeezing" that occurs in the game in DosBox, LucasArts must have used a custom single-dot font instead of the something similar to the IBM or Tandy double-dot fonts in the Tandy mode. Otherwise, 40 columns just wouldn't work with 8x8 cells, but it would with 4x8 cells.

I trust the following screenshot is how it should look on a true Tandy 1000:
[img]zak_000.png[/img]

Speaking of the Tandy 1000, I had originally complained that the King's Quest Booter, Tandy version wrongly produced serrated graphics in the title screen. When Servo admitted that he was using a Tandy 1000 instead of an IBM CGA to take the screenshots at MobyGames, it all makes sense. The Tandy 1000 has a somewhat different font for graphics than an IBM PC. A noticeable example is that the letters "d" and "b" are different. Also, the text columns are shifted by one pixel. As the game is attempting to draw the wrong text, it is conflicting with the white background. Use of the Tandy font is necessary to avoid problems like these.

Finally, in MESS, Pitstop II presents an interesting test. Even if you have your monitor set to RGB, you can still read both options. Using RGB, press option 1 and you will play in 640x200 monochrome or press option 2 and play in the 320x200 four color mode. Using a composite monitor with option 1 to get "green-dominated" color graphics, but by using option two you will get graphics similar looking to the RGB mode with a few extra colors added.

Great Hierophant wrote:

Basically, the game (Maniac Mansion) treats the composite mode like Tandy's mode 8 (160x200x16), which in fact the game uses on a Tandy computer.

I don't understand how this is possible on an RGB monitor. If it does, then how does it get the regular text characters to display properly? Those characters are designed for the 320x200 modes, graphics or text.

If the game indeed uses 160x200 on a Tandy, then it would have to have characters designed for 160x200. In the screenshot you supply, the 'Zak, Zak, Zak.' characters all fit this requirement. It's not that difficult to make a 160x200 displayable font, as most 320x200 characters, save a few serifs, are already based on units of two horizontal pixels.

JAL

Great Hierophant wrote:

I don't understand how this is possible on an RGB monitor. If it does, then how does it get the regular text characters to display properly? Those characters are designed for the 320x200 modes, graphics or text. In a 160x200 mode they would be stretched to double size, just like in the 640x200 mode they are squeezed to half size.

The game doesn't used the built in font for text, it uses it's own font which is the same width as 320x200 40 column text, just blockier. Ordinarily you would get 20 column wide text in 160x200 though. Your Zak screenshot looks to be accurate.

Great Hierophant wrote:

Speaking of the Tandy 1000, I had originally complained that the King's Quest Booter, Tandy version wrongly produced serrated graphics in the title screen. When Servo admitted that he was using a Tandy 1000 instead of an IBM CGA to take the screenshots at MobyGames, it all makes sense. The Tandy 1000 has a somewhat different font for graphics than an IBM PC. A noticeable example is that the letters "d" and "b" are different. Also, the text columns are shifted by one pixel. As the game is attempting to draw the wrong text, it is conflicting with the white background. Use of the Tandy font is necessary to avoid problems like these.

Just to clarify, I used an IBM CGA adapter installed in a Tandy 1000; I didn't use the built in Tandy video. The KQ booter screenshots on moby were taken from the PC version, not the Tandy version. What's different about the text? The only thing I can spot is being off by one pixel causing the red/blue artifacting to be reversed. I'm not spotting other diferrences though between IBM CGA on an IBM vs IBM CGA on a Tandy? (guess I'm not following what's wrong here...)

I don't understand how this is possible on an RGB monitor. If it does, then how does it get the regular text characters to display properly? Those characters are designed for the 320x200 modes, graphics or text. In a 160x200 mode they would be stretched to double size, just like in the 640x200 mode they are squeezed to half size.

"Basically, the game (Maniac Mansion) treats the composite mode like Tandy's mode 8 (160x200x16)", EXCEPT for text output. 'k?

Using RGB, press option 1 and you will play in 640x200 monochrome

No, Black&Green, not monochrome.

Also, the text columns are shifted by one pixel. As the game is attempting to draw the wrong text, it is conflicting with the white background. Use of the Tandy font is necessary to avoid problems like these.

Huh?. What problems are avoided by using a font shifted by one pixel?

Just to clarify, I used an IBM CGA adapter installed in a Tandy 1000; I didn't use the built in Tandy video. The KQ booter screenshots on moby were taken from the PC version, not the Tandy version. What's different about the text? The only thing I can spot is being off by one pixel causing the red/blue artifacting to be reversed. I'm not spotting other diferrences though between IBM CGA on an IBM vs IBM CGA on a Tandy? (guess I'm not following what's wrong here...)

Ah, even if you used the CGA card in the Tandy 1000, the game cannot use the CGA Character Generator ROM, which houses the text characters but only for the text modes. Instead it uses the characters as stored in the BIOS. On a true PC, the game would take its text from the IBM BIOS. On a Tandy 1000, the game would take its text from the Tandy 1000 BIOS. The two fonts have the differences I mentioned above.

No, Black&Green, not monochrome.

When people say monochrome, they don't consider black a color. Perhaps dualchrome is a better description, but to me monochrome means "one color against a black background", which color that is depends on the display device and the graphics hardware.

Huh?. What problems are avoided by using a font shifted by one pixel?

I think what happens is that the game first puts the text on the screen, draws the outline of the scroll, then fills the scroll with white. If the text is off by a pixel, then the program will overwrite the pixels that are not where they are supposed to be, or at the very least change their color. The light gray text becomes white and the black text becomes dark gray. The intensity of those bits are "turned on." Try it with the true Tandy font and see if any improvement is effected.

In general computer/video-related discussion, "monochrome" is usually used to refer to a display which can show either one color or the absence of that color (typically black & white, black & green, black & amber, etc.). A display that could only be all white or all black would be pretty useless...

The place where it gets confusing is when you talk about displays that can only show one color, but in different shades. Case in point is the original Nintendo GameBoy, which had a greenish LCD on a yellow background; it could display 3 shades of green, or by absence of color it could display yellow.

I think what happens is that the game first puts the text on the screen, draws the outline of the scroll, then fills the scroll with white.

No. The game draws the complete screen, with outlines and fillings, then prints the text at the very end.

The light gray text becomes white and the black text becomes dark gray.

The PC version doesn't print the text as gray, it prints all text as black. It has nothing to do with the font being used.

In general computer/video-related discussion, "monochrome" is usually used to refer to a display which can show either one color or the absence of that color (typically black & white, black & green, black & amber, etc.). A display that could only be all white or all black would be pretty useless...

I've been taught (not in a computing, but a graphics class) that "monochrome" means one hue in various shades, not just two shades. On a composite monitor, modes 0, 2 and 5 are monochrome (because they show different shades of gray), while mode 6 is black&white (because there are no shades of gray, only black and white), the GameBoy would be monochrome. According to Wikipedia, the word can be applied to both definitions. m-w.com writes "single color or hue". Oh well.

The Gameboy had 2 four-color palettes for the sprites and 2 four-color palettes for the background. Very unusual when you consider that the Gameboy can only display four shades of green. Also, the Tandy 1000 and IBM PCjr. also had 16 palette registers but only could display 16 colors. Why not simply have fixed values?

The PC version doesn't print the text as gray, it prints all text as black. It has nothing to do with the font being used.

Don't you find it odd how DosBox displays the text within the scroll for the Tandy booter using the Tandy driver? It seems that it displays odd columns using the dark color and even colums with the color's intense counterpart. (see first page of the post for the screenshot.)

I've been taught (not in a computing, but a graphics class) that "monochrome" means one hue in various shades, not just two shades. On a composite monitor, modes 0, 2 and 5 are monochrome (because they show different shades of gray), while mode 6 is black&white (because there are no shades of gray, only black and white), the GameBoy would be monochrome. According to Wikipedia, the word can be applied to both definitions. m-w.com writes "single color or hue". Oh well.

By the way, how many shades of gray can the CGA display in these modes on a composite monitor? I would guess either four or sixteen. Even the MDA, which is monochrome, can display three or four shades of a single color.

Great Hierophant wrote:

Ah, even if you used the CGA card in the Tandy 1000, the game cannot use the CGA Character Generator ROM, which houses the text characters but only for the text modes. Instead it uses the characters as stored in the BIOS. On a true PC, the game would take its text from the IBM BIOS. On a Tandy 1000, the game would take its text from the Tandy 1000 BIOS. The two fonts have the differences I mentioned above.

The only visible difference I can tell is on the Tandy the red/blue artifacting is reversed (apparently due to the font being off by a pixel) but I can't see any other differences between the two. When the screen is drawn, the font isn't overwritten, rather the font overwrites what's drawn. If that wasn't the case though, the font wouldn't be needed; if the image could draw itself without overwriting pixels where the correct font would be displayed, why would you need the font at all? Just draw the screen and leave it at that...

But to be really insanely accurately emulated would require all sorts of options as each are slightly different; you apparently have to worry about CGA on a PC; CGA on a Tandy; Tandy video on a Tandy; and differences of Tandy video I vs video II (regular 1000's vs. TL/SL/RL); probably some other possible combinations as well. I'm not certain worrying about all that is terribly useful...though adding in PCjr might be nice.

Yeah, I've always heard monochrome allowing multiple shades; even some monochrome computer displays allowed it, such as the IBM MDA adapter or the VT-100 terminals I remember.

Great Hierophant wrote:

Don't you find it odd how DosBox displays the text within the scroll for the Tandy booter using the Tandy driver? It seems that it displays odd columns using the dark color and even colums with the color's intense counterpart.

Don't make things more complicated than they are. The Tandy booter displays some text on the scroll as gray, some text on the scroll as black. The PC booter displays all text on the scroll as black.

DosBox displays the Tandy booter's text incorrectly because DosBox has a bug that occurs when BL has bit 7 set on a Int 10h Ah=0Eh call, which tells the BIOS not to just draw the pixel, but to XOR it into video memory. This has nothing to do with the font being used.

Great Hierophant wrote:

By the way, how many shades of gray can the CGA display in these modes on a composite monitor? I would guess either four or sixteen.

0,2: 16. 5: 4. 6:1. 6+colorburst:3.

Great Hierophant wrote:

Even the MDA, which is monochrome, can display three or four shades of a single color.

3: Black, normal, intense.

Servo wrote:

But to be really insanely accurately emulated would require all sorts of options as each are slightly different; you apparently have to worry about CGA on a PC; CGA on a Tandy; Tandy video on a Tandy; and differences of Tandy video I vs video II (regular 1000's vs. TL/SL/RL); probably some other possible combinations as well. I'm not certain worrying about all that is terribly useful...though adding in PCjr might be nice.

According to the screenshots you sent me, the Tandy's output is basically like the CGA's, only the hue is 120 degrees off (i.e. you've got to set the algorithm's hue control to +120 to make it look like the Tandy. I've verified it with that "Blue Angels" game you mentioned). I guess the PCjr one somewhere within that range as well. By the way, do you still own a PCjr? I'm asking because the MESS people are lacking a complete image of the PCjr's ROM BIOS.

NewRisingSun wrote:

You could put +Hue on F12, -Hue on Shift-F12, and RGB/Composite switch on F11.

Sounds good to me. Qbix?

NewRisingSun wrote:

MESS displays at Hue=0. DosBox CVS automatically switches to Hue=-15 for KQ1.

Ah, you're talking about the "auto-guessing" of the correct hue that you mentioned a few posts ago. I forgot about that at first and thought that DOSBox CVS's hue is also fixed on 0. Hmm... if this "auto-guessing" worked for all games as good as it does for KQ1, we wouldn't have any need for the hue control 😀

NewRisingSun wrote:

I personally prefer Hue=0 with some Red Boost, but that won't be included in DosBox.

What is this Red Boost? And why it won't be included in DOSBox?

Incidentally, just out of curiosity I checked how Mean Streets looked on a composite monitor, and I used MESS 0.100 (because DOSBox just shows the regular 4 colors when machine=cga in this game):

It looks much worse than the regular 4 colors, so people who only had a composite monitor instead of a regular CGA couldn't really play this game. Well, perhaps Access never took composite users in consideration because by then VGA was available.

Great Hierophant wrote:

Don't you find it odd how DosBox displays the text within the scroll for the Tandy booter using the Tandy driver? It seems that it displays odd columns using the dark color and even colums with the color's intense counterpart. (see first page of the post for the screenshot.)

Yes, that's what started this thread. This problem still isn't fixed, here's a screenshot taken with the newest aep CVS:

And this is how it looks on MESS 0.100 for comparison: