• Please review our updated Terms and Rules here

16-color PC CGA-EGA Friendly Picture Viewer

G

Great Hierophant

Veteran Member
Joined
Mar 22, 2006
Messages
1,928
Location
Massachusetts, USA
Is there any kind of picture viewer software that could display a CGA, Tandy or EGA screenshot from a program as it would have been seen if the software had been run on the system?

Suppose I take a screenshot in DOSBox, which outputs to the PNG format. The program DOSBox is running uses a 4-color 320x200 CGA mode. I would like to display that screenshot on my IBM PC with a real CGA card, just as if I had run the program on the PC. Is there any viewer program that could display the screenshot? To what format would I need to convert the screenshot? Ideally I would like to see any conversion be lossless. Hopefully the program would allow me to display the screenshot in full screen. Similarly, what about 16-color adapters like Tandy, PCjr. or EGA? Do programs exist for them that allow them to display a 320x200 16-color screenshot?
 
There are no PNG viewers for DOS that work on <386 systems; the only one I know of, DISPLAY, requires a 386 as it uses protected mode. So, you will have to convert PNG to something else. For period-correct viewing of pictures/screenshots, convert to GIF and then use a GIF program like cshow (avoid "cshow 2000" if possible; it works on 808x systems but is a little bloated) to show the GIF. Make sure the GIF has the same number of colors as the source; for example, if you took a DOSBOX screenshot of a 16-color game, then make sure the GIF after conversion is also a 16-color GIF. If the resulting file is a 256-color-format .GIF with only the first 16 colors used, you might be able to display it but I wouldn't count on it.

Things get a little more difficult when you work with 4-color pictures; most modern programs don't support them even though the GIF/PCX/LBM formats clearly did. You may get lucky with very old programs that continue to work on modern systems, like the Win32 version of ImageMagik.

There's a potentially easier way to do this: Capture the screen from within DOS itself. There were many screen capture programs for DOS (even DeluxePaint comes with one) that save directly to 2-/4-/16-color .PCX or .GIF files which are then easily viewable in their native habitat. As long as the screen you're trying to capture isn't produced by a game that is taking over the keyboard in horrible ways, it should work.

If you run into trouble, write an exact scenario and I can write back with how I solved it.
 
The way I usually prepare graphics for demos on oldskool platforms is to have a Windows tool that can read pretty much anything you throw at it (I use FreeImage, which supports all the usual formats, and then a bunch of unusual ones), and then convert the raw pixel data into the machine-specific representation. Then I import this raw data into a binary for the platform, and just dump it into its video memory.

So I have something that can take a PNG and convert it to CGA, EGA or VGA. I could make it spit out a binary directly.

Alternatively, it shouldn't be too hard to get something like libPNG working from DOS directly, so we could make something that reads PNG directly. Problem is however that PNG is truecolour, so if you want to handle something that isn't in the native palette already, you'll need to process it, which will require memory and CPU power. Not something you want to do on an old PC.
Makes me recall the days of playing around with GIF images on the Amiga. Remapping the 24-bit 256-colour palette to the Amiga's HAM mode took ages, with the viewer I found. You were looking at 10-15 minutes per image.
 
For Tandy 16color Lowres (320x200) I capture the screens directly on my T1000 with "camera" from Deluxepaint. But it does not work for all Games.
I also downloaded some EGA Lowres Gfx over the Internet and converted them with "acdsee3" or "paintshop-pro5" to pcx.
I display those gfx on the Tandy with "gallery" from Deluxepaint, because it's FAST!

I think I will do the same with EGA, CGA(4colors) and MDA for my old XT's and AT's.
 
I tried Trixter's suggested program, CompuShow 9.0.4, found here : http://www.cshowplace.com/cshow.htm and it can work! However, it has issues displaying the PNGs output by DOSBox, so what worked for me every time was to convert it to GIF using CompuShow 9.0.4. After that, 16-color images would display flawlessly.

CompuShow works with Tandy 1000 (and presumably PCjr.) graphics adapters, but you need to use the /J1 command line argument. It even has a driver for the special 640x200 mode found in the TL and SL computers which will display 320x200 graphics properly. It does not like DOSBox's built-in DOS. Running the program in the Tandy 1000 allowed me to display all 4-color RGB screenshots properly, using the Tandy's 16-color mode.

Obviously I do not expect any difficulties with EGA or VGA screenshots, based on this program's Tandy abilities, with the PNGs it converts to GIF. Similarly, a Hercules screenshot in the proper format should be well within its capabilities, but I am too lazy to hook up the mono monitor right now.

Of course, if run on a CGA card or limited to CGA capabilities, things do not fare so well. A screenshot in a standard, BIOS-friendly palette will display as expected. Intense palettes are supported, even though that is not strictly a BIOS feature. However, the alternate cyan/red/white palette screenshots will not display correctly, the best mode to use is the equivalent cyan/magenta/white palette. If the screenshot uses a fourth color that is not black, that color will hopefully become black. Finally, forget about displaying 640x200 in composite color (whether CGA, PCjr. or Tandy) or displaying 640x200 graphics in anything other than black and white. However, it will display 640x200 graphics correctly even if they are using 640x400 resolution, which is the default output from DOSBox.

There is a CGA driver for displaying pictures in a 160x100 resolution. I will try that out with a game that uses that resolution. I would think that it would be possible for someone to write a CGA driver that would cure this program's deficiencies.
 
Last edited:
Trixter said:
PNG also supports indexed color images. (ie. 16-color, 256-color, etc.) These would be easier to support. Most programs that support PNG only support 256-color, but it is technically possible to create 2/4/8/16/32/64/128/256-color-indexed PNG files.
Click to expand...

I know, but those still use truecolour palettes. So remapping a 256-colour 24-bit palette to CGA/EGA is about as difficult as remapping a direct truecolour image (you need to perform some form of dithering or such to 'simulate' the colours).
Even a 2/4/8/16-colour image can be difficult to remap to CGA/EGA, since the chosen palette may be completely different from what CGA/EGA are capable of.
 
Great Hierophant said:
Of course, if run on a CGA card or limited to CGA capabilities, things do not fare so well. A screenshot in a standard, BIOS-friendly palette will display as expected. Intense palettes are supported, even though that is not strictly a BIOS feature. However, the alternate cyan/red/white palette screenshots will not display correctly, the best mode to use is the equivalent cyan/magenta/white palette. If the screenshot uses a fourth color that is not black, that color will hopefully become black. Finally, forget about displaying 640x200 in composite color (whether CGA, PCjr. or Tandy) or displaying 640x200 graphics in anything other than black and white. However, it will display 640x200 graphics correctly even if they are using 640x400 resolution, which is the default output from DOSBox.
Click to expand...

This could be a deficiency of the screenshot routine itself: It may have 'forgotten' to also save the CGA palette in the file, and might just use the default palette (which is how EGA/VGA work anyway, they don't support the CGA palette registers).
 
Scali said:
I know, but those still use truecolour palettes. So remapping a 256-colour 24-bit palette to CGA/EGA is about as difficult as remapping a direct truecolour image (you need to perform some form of dithering or such to 'simulate' the colours).
Even a 2/4/8/16-colour image can be difficult to remap to CGA/EGA, since the chosen palette may be completely different from what CGA/EGA are capable of.
Click to expand...

As a sidenote: that's what I've been doing back then on my 286 Herc. Image Alchemy rescaled 320x200x256 graphics to 720x348x2, and performed dithering. That really worked well with all that increased resolution though. Dithering on the same resolution is uglier.
 
Screenshots please.

I am collecting "low-color-art" as well, no photos, no rendering, just pixelart.
For "the old" standards below 256color VGA (MDA,CGA,TDY,EGA) dithering is the key to improve the visable quality when reducing the colors.
I did not find a tool yet, that makes Dithering in differnt patterns for each color automatically.
Important is, that the source material itself has low seperate colors und not much mixed colors.
The result is much much better when choosing pixelart with 16 vga-colors instead of 256 colors.
From 16 vga-colors you get a good EGA Hires image.

When it comes to CGA or MDA the differnt colors need to be remapped to different patterns,
otherwise you will lose mostly all details of the image.

But I did not find a way or programm that get's you the best images for MDA.
 
dr.zeissler said:
But I did not find a way or programm that get's you the best images for MDA.
Click to expand...

CompuShow 9.x should let you do this. I seem to recall that Graphics Workshop for DOS would also allow you to resize and dither images for Herc display, but could be wrong. It is trivial to convert those yourself with any program, DOS or Windows, though.

Scali said:
Even a 2/4/8/16-colour image can be difficult to remap to CGA/EGA, since the chosen palette may be completely different from what CGA/EGA are capable of.
Click to expand...

But it should be trivial when the palette is identical to the graphics card's capabilities, which is the scenario the OP was targeting (he wanted to take screenshots in DOSBox and then display them on a real system).

Great Hierophant said:
However, it has issues displaying the PNGs output by DOSBox, so what worked for me every time was to convert it to GIF using CompuShow 9.0.4. After that, 16-color images would display flawlessly.
Click to expand...

This is news to me! I never knew CS added PNG support (or conversions!) and works on 808x systems. That is good to know.

I would think that it would be possible for someone to write a CGA driver that would cure this program's deficiencies.
Click to expand...

IIRC, Bob never released source or a dev kit. I called him (long distance!) in 1990 asking him for 160x100x16 programming info and he never returned my call (as a maligned teen, you remember these things). On a lark, I emailed the address on the website asking for driver dev info.
 
Trixter said:
But it should be trivial when the palette is identical to the graphics card's capabilities, which is the scenario the OP was targeting (he wanted to take screenshots in DOSBox and then display them on a real system).
Click to expand...

It is only trivial if your capture software and display software are aware of eachother.
Because saving a screenshot to PNG forces you to encode your data to a 24-bit palette.
As you know, palettes for old computer systems are not an exact science. Which means the RGB values used in the PNG palette may be slightly different from what the display software assumes to be the 'exact' values for the hardware.
So only if it can assume that the palette indices can directly be mapped to the hardware colours, it can display them without any processing.
If the order is somehow different, and/or the RGB values don't match up exactly, it will have to do some kind of processing. And what approach will you take then? The generic approach is to just perform 'bruteforce' colour reduction and dithering.
 
Scali said:
It is only trivial if your capture software and display software are aware of eachother.
Because saving a screenshot to PNG forces you to encode your data to a 24-bit palette.
As you know, palettes for old computer systems are not an exact science. Which means the RGB values used in the PNG palette may be slightly different from what the display software assumes to be the 'exact' values for the hardware.
So only if it can assume that the palette indices can directly be mapped to the hardware colours, it can display them without any processing.
If the order is somehow different, and/or the RGB values don't match up exactly, it will have to do some kind of processing. And what approach will you take then? The generic approach is to just perform 'bruteforce' colour reduction and dithering.
Click to expand...

I don't disagree with the majority of you wrote, but the software at the time was aware of all of this and worked the way you would expect. Meaning, if you had an CGA-colored GIF, the various GIF display programs that supported CGA either chose the right palette to display the file, or let you pick which palette and then remapped the colors without dithering (so if you chose correctly, it looked correct).
 
Trixter said:
I don't disagree with the majority of you wrote, but the software at the time was aware of all of this and worked the way you would expect. Meaning, if you had an CGA-colored GIF, the various GIF display programs that supported CGA either chose the right palette to display the file, or let you pick which palette and then remapped the colors without dithering (so if you chose correctly, it looked correct).
Click to expand...

GIF yes, however, PNG wasn't developed until 1996, by which time we were well into the SVGA-era, and Windows was pushing DOS away.
So I don't think there will be a lot of software for PNG screenshots and support for Hercules/CGA for DOS.
It won't 'automatically' work as expected. GIF and other 'era-correct' formats such as PCX, BMP, LBM, TIFF and TGA have a better chance of working as expected, since they were commonly used for taking screenshots in DOS, so they were probably somewhat standardized in that respect.
 
Scali said:
GIF yes, however, PNG wasn't developed until 1996, by which time we were well into the SVGA-era, and Windows was pushing DOS away.
So I don't think there will be a lot of software for PNG screenshots and support for Hercules/CGA for DOS.
It won't 'automatically' work as expected. GIF and other 'era-correct' formats such as PCX, BMP, LBM, TIFF and TGA have a better chance of working as expected, since they were commonly used for taking screenshots in DOS, so they were probably somewhat standardized in that respect.
Click to expand...

GIF and PNG store palettes the same way (8-bit RGB values), so my expectation would be that a program like CompuShow, which first supported GIFs and ended up supporting PNGs later, would operate the same way with both GIFs and paletted PNG files.

GH (the OP) wrote earlier that CompuShow had trouble displaying 16-color PNG files created by DOSBox, but that converting from PNG (*with* CompuShow itself) to GIF then worked. That is curious, because it proves cshow can properly decode PNGs, and the resulting GIF would be identical in terms of decoded picture content and palette entries. I suspect the 16-color DOSBox PNG files are always 256-color-format files, with only the first 16 palette entries used, and cshow didn't handle remapping a 256-color picture to a 16-color hardware device correctly, as you posited earlier.
 
Trixter said:
GIF and PNG store palettes the same way (8-bit RGB values), so my expectation would be that a program like CompuShow, which first supported GIFs and ended up supporting PNGs later, would operate the same way with both GIFs and paletted PNG files.

GH (the OP) wrote earlier that CompuShow had trouble displaying 16-color PNG files created by DOSBox, but that converting from PNG (*with* CompuShow itself) to GIF then worked. That is curious, because it proves cshow can properly decode PNGs, and the resulting GIF would be identical in terms of decoded picture content and palette entries. I suspect the 16-color DOSBox PNG files are always 256-color-format files, with only the first 16 palette entries used, and cshow didn't handle remapping a 256-color picture to a 16-color hardware device correctly, as you posited earlier.
Click to expand...

Scali said:
This could be a deficiency of the screenshot routine itself: It may have 'forgotten' to also save the CGA palette in the file, and might just use the default palette (which is how EGA/VGA work anyway, they don't support the CGA palette registers).
Click to expand...

Regular DOSBox stores all PNGs as 256-color indexed PNGs. With the CGA, PCjr., Tandy and EGA, it will save the same 16 colors, all in the proper CGA order (Color 0 is black, color 1 is blue, color 6 is brown etc.). Exceptions are 350-line EGA color or monochrome graphics (which will only use 16 palette entries but the colors may take from the larger EGA palette) and CGA color composite graphics (up to 256 palette entries may be used). Hercules uses the 16-color palette, but colors 1, 7 and 15 are set to the color used for the white, green or amber mode.

I tried using InfranView to reduce the color depth to 16 colors and to convert the images to GIFs, but CompuShow showed the same errors. It really wants the images in its own format.
 
Ideally, I see a true CGA display program as consisting of two parts. The first part is converting a png/gif/pcx image into a raw binary format of 2-bits per pixel for 320x200 graphics, 1-bit per pixel for 640x200 graphics and 2 bytes for 160x100 graphics. One particular challenge is when the image is tweaked, such as when the background color in 320x200 is not the default black color, as in this Alley Cat screenshot : boot_002.png

I would suggest that the program, when it is looking at the four unique colors in a CGA image, have an automatic setting that can try and guess the appropriate CGA color or show the color to the user and ask him to determine which color it should be.

Then the next step would be to allow the user to manually configure the image output so that it does match the screenshot. A setting allowing the user to set the foreground/background or border color, depending on the mode; to set color composite or B&W composite, to set the intense palettes, to change palettes and to set the graphics mode.
 
With regular screenshot software it may be a problem to determine the correct palette, because the CGA palette registers are write-only, I believe.
DOSBox however should know exactly how the palette is configured, because it knows the whole CGA state. So it should be capable of exporting the proper palette to the screenshot file.
Then the display software could automatically select the proper CGA palette and background colour. If you save the file as a 4-colour file, with 4 palette entries, it shouldn't be too difficult to determine which palette to use, even bruteforce. You just compare the 3 fixed colours against the CGA palette, and pick the closest one. Then you set the background colour.

I suppose a 'manual' solution would be possible on real hardware. And it would be nice if you could just write back the manually corrected palette to the file, so it opens properly the next time.
 
You must log in or register to reply here.
Back
Top