I rechecked Duke Nukem II and the color is yellowish/mustard like. I personally think it fits better with the military cammo team in the logo than the brown shown in other screenshots. It makes me wonder what was actually the intention.

I found this snippet on: https://moddingwiki.shikadi.net/wiki/EGA_Palette

Notice that colour entry #6 (brown) doesn't fit in sequence with the other entries. This is because the CGA had additional circuitry to make this colour appear "more visually pleasing." The introduction of the EGA palette meant this adjustment no longer required additional hardware. Setting palette entry #6 to the in-sequence value of 6 (#AAAA00) instead of 20 reveals the "dark yellow" colour found in cheaper clone CGA monitors lacking the additional circuitry.

I take it to reverse this change one could use a tool like CHGCOLOR.

In other problems with the new EGA card I now cannot use QRAM to load device drivers/TSR's high and at the same time get EGA graphics. I need to look more closely into what is causing that issue. The second problem is that when loading ansi.sys in Olivetti MS-DOS 3.1 (which the computer has installed) the video performance tanks completely. If I don't load it I don't get correct characters for the country localization I've setup. I've read that perhaps switching to NANSI.sys could be a trick.

maxtherabbit wrote on 2025-09-15, 22:50:

"CGA brown" is definitely handled in the monitor not the video card

This is true for 16-color monitors. This is not true for 64-color monitors. The IBM ECD (and compatible monitors) are quite funny: In 200-line mode, they are "16-color monitors", and handle CGA brown inside the monitor. In 350-line mode, they are "64-color monitors" and do no longer handler "CGA brown", because "dark yellow" and "CGA brown" are both present in the 64-color EGA palette and no translation is needed in the monitor. The EGA card is set up to specifically request "CGA brown" (EGA color number 20) instead of "dark yellow" (EGA color number 6) for pixels with color number 6 in 350-line modes.

mkarcher wrote on 2025-09-16, 08:44:

maxtherabbit wrote on 2025-09-15, 22:50:

"CGA brown" is definitely handled in the monitor not the video card

This is true for 16-color monitors. This is not true for 64-color monitors. The IBM ECD (and compatible monitors) are quite funny: In 200-line mode, they are "16-color monitors", and handle CGA brown inside the monitor. In 350-line mode, they are "64-color monitors" and do no longer handler "CGA brown", because "dark yellow" and "CGA brown" are both present in the 64-color EGA palette and no translation is needed in the monitor. The EGA card is set up to specifically request "CGA brown" (EGA color number 20) instead of "dark yellow" (EGA color number 6) for pixels with color number 6 in 350-line modes.

Interesting. Is 200 mode only 320x200, or for 640x200 as well?

vetz wrote on 2025-09-16, 09:07:

mkarcher wrote on 2025-09-16, 08:44:

The IBM ECD (and compatible monitors) are quite funny: In 200-line mode, they are "16-color monitors", and handle CGA brown inside the monitor. In 350-line mode, they are "64-color monitors" and do no longer handler "CGA brown".

Interesting. Is 200 mode only 320x200, or for 640x200 as well?

This applies to both 320*200 and 640*200. The monitor doesn't know what horizontal resolution it is operating at, but it could count the number of lines per frame to determine whether it is in 15kHz/200 line mode or in 21kHz/350 line mode. The monitor could also measure the horizontal frequency to distinguish these modes. Multi-Sync monitors actually do stuff like this, whereas the IBM ECD (and compatible monitors) rely on assistance by the computer. If the vertical synchronization signal is negative (typically high, with "short" pulses of being low between frames), the monitor operates in 21kHz/350-line/64-color mode. If the vertical syncronization signal is positive (typically low, with "short" pulses of being high between frames), the monitor operates in 15kHz/200-line/16-color mode.

IBM wanted the EGA to work perfectly with the IBM Color Display (the CGA monitor) in 200-line mode, and IBM also wanted the ECD to work perfectly with the CGA card (always in 200-line mode). So IBM had to use the same protocol for 200 line modes on the EGA as IBM used on the CGA, which means 16 colors. And 16 colors means that the rendering of color number 6 needs to be "adjusted" in the monitor. The EGA card can decide between "dark yellow" and "CGA brown" only in 64-color mode.

See https://www.reenigne.org/blog/why-the-ega-can … 200-line-modes/ for a nice blog post by a fellow VOGONS used for more elaboration.

Here's Simcity in 640x350 16 color EGA. Notice how the earth color is alot more orange for the classic graphics. It looks fine in "Future Europe". Beside that the game runs as it should. I did notice graphic corruption when running the game on a NetDrive (MTCP application). All fine when I copied the files over to the local harddrive.

Hi - what version of netdrive are you using? Did you try to send a bug report?

mbbrutman wrote on 2025-09-19, 15:08:

Hi - what version of netdrive are you using? Did you try to send a bug report?

Its the embedded server version running in Docker. I need to check. I can try to replicate using the latest Windows server version and report back in the mtcp thread if you want.

That thread is getting kind of polluted - can you send email instead?

mbbrutman wrote on 2025-09-19, 15:31:

That thread is getting kind of polluted - can you send email instead?

Will do! I'll follow up on the issue with Prince Of Persia as well (which I managed to reproduce on another computer)

vetz wrote on 2025-09-16, 08:37:

In other problems with the new EGA card I now cannot use QRAM to load device drivers/TSR's high and at the same time get EGA graphics. I need to look more closely into what is causing that issue.

EGA does take up more of the Upper Memory Area, since it needs more video memory. I don't have any particular experience with QRAM, but wouldn't it simply be a matter of telling it to exclude the memory at segment A000h as well? Maybe there are newer versions of QRAM that are better aware of EGA and VGA cards?

Ah, wait. If I'm not mistaken, the built-in graphics of the M24 (and I guess also that of the M28) also has twice the video memory of IBM CGA, since it supports twice the resolution. And I believe it expands into that same segment A000h that EGA uses. So if back in the day you set up QRAM to repurpose that extra video memory for loading TSRs high, because you never utilized that proprietary 640x400 high-res monochrome mode, that could explain why it stopped working for you once you installed the EGA card. What command-line arguments were you passing to QRAM in your autoexec.bat file?

The second problem is that when loading ansi.sys in Olivetti MS-DOS 3.1 (which the computer has installed) the video performance tanks completely. If I don't load it I don't get correct characters for the country localization I've setup. I've read that perhaps switching to NANSI.sys could be a trick.

The implementation of ANSI.SYS that shipped with DOS is indeed notoriously slow. NANSI, like you said, is a major improvement. There is also NNANSI (with a double N), which is even better, albeit closed source, and only free for home or educational use. (Not a big deal since we're just using this for hobby purposes, I guess.)

For more details on NANSI and NNANSI, and how they compare with the ANSI.SYS that shipped with DOS, see https://kegel.com/nansi/

digger wrote on 2025-09-20, 11:04:

EGA does take up more of the Upper Memory Area, since it needs more video memory. I don't have any particular experience with QRAM, but wouldn't it simply be a matter of telling it to exclude the memory at segment A000h as well? Maybe there are newer versions of QRAM that are better aware of EGA and VGA cards?

Ah, wait. If I'm not mistaken, the built-in graphics of the M24 (and I guess also that of the M28) also has twice the video memory of IBM CGA, since it supports twice the resolution. And I believe it expands into that same segment A000h that EGA uses. So if back in the day you set up QRAM to repurpose that extra video memory for loading TSRs high, because you never utilized that proprietary 640x400 high-res monochrome mode, that could explain why it stopped working for you once you installed the EGA card. What command-line arguments were you passing to QRAM in your autoexec.bat file?

It wasn't setup to exclude those segments, but it shouldn't be needed. Just like EMM386 it should auto exclude them. Hi-res 640x400 monochrome I did test out in Windows and the included setup/demo programs from Olivetti using the built-in video card. I tried to checkout the included QRAM readme, but how to manually exclude segments were not covered. I probably need to find the written manual or other documentation for QRAM. QRAM is just a convenience since I can load everything all at once, but if I can't get it to work it won't be a problem for the games that run well on this system if I make some menu system for boot.

digger wrote on 2025-09-20, 11:04:

The implementation of ANSI.SYS that shipped with DOS is indeed notoriously slow. NANSI, like you said, is a major improvement. There is also NNANSI (with a double N), which is even better, albeit closed source, and only free for home or educational use. (Not a big deal since we're just using this for hobby purposes, I guess.)

For more details on NANSI and NNANSI, and how they compare with the ANSI.SYS that shipped with DOS, see https://kegel.com/nansi/

Thanks for the tip!