PDA

View Full Version : 16-color PC CGA-EGA Friendly Picture Viewer



Great Hierophant
December 28th, 2015, 07:19 PM
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?

Trixter
December 28th, 2015, 09:50 PM
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 (http://www.imagemagick.org/script/index.php).

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.

Scali
December 28th, 2015, 10:51 PM
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 (http://freeimage.sourceforge.net/), 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.

dr.zeissler
December 29th, 2015, 02:36 AM
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.

Trixter
December 29th, 2015, 07:02 AM
Problem is however that PNG is truecolour

PNG also supports indexed color images (http://libmng.com/pub/png/spec/1.2/png-1.2-pdg.html#DR.Image-layout). (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.

Gabucino
December 29th, 2015, 07:39 AM
Image Alchemy for conversion
LXPIC for viewing

ropersonline
December 29th, 2015, 03:04 PM
If you run into trouble, write an exact scenario and I can write back with how I solved it.

With just about anybody else, I would dismiss that as overconfidence. Not with you though. ;-)

Great Hierophant
December 29th, 2015, 09:29 PM
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.

Scali
December 29th, 2015, 10:53 PM
PNG also supports indexed color images (http://libmng.com/pub/png/spec/1.2/png-1.2-pdg.html#DR.Image-layout). (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.

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.

Scali
December 29th, 2015, 11:07 PM
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.

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

Gabucino
December 29th, 2015, 11:11 PM
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.

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.

dr.zeissler
December 30th, 2015, 01:32 AM
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.

Trixter
December 30th, 2015, 07:02 AM
But I did not find a way or programm that get's you the best images for MDA.

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.


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.

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


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.

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.

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.

Scali
December 30th, 2015, 10:35 AM
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).

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.

Trixter
December 30th, 2015, 12:15 PM
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.

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

Scali
December 30th, 2015, 12:26 PM
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).

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.

Trixter
December 30th, 2015, 12:59 PM
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.

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.

Great Hierophant
December 31st, 2015, 06:38 PM
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.


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

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.

Great Hierophant
January 2nd, 2016, 09:53 PM
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 : 28715

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.

Scali
January 3rd, 2016, 03:17 AM
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.

Great Hierophant
January 3rd, 2016, 07:58 AM
Official DOSBox is pretty good at being consistent with the CGA 16-color palette regardless of machine type. All 8-bit RGB color values are multiples of 85 for R, G & B. However, if you are using screenshots generated by another program or maybe even an old version of DOSBox, the values may be a little different.

Scali
January 3rd, 2016, 08:14 AM
Yup, which is why I suggested 'closest match'. This could be done by simply calculating the Euclidean distance (consider colours as 3-component vectors, so you have a 3-dimensional space with R, G and B axis) between the colours in the palette and your own 'perfect' palette definition.
That is what I do in my tool anyway, to iron out small differences between interpretations of palettes. Especially with composite colours, there is no one true set of RGB values.
Another issue I solve with this, as an indirect side-effect, is that you cannot rely on the palette order. Some software tries to be 'smart' and reorganizes your palette (perhaps to try and get the best possible compression from GIF/PNG). So I have been 'surprised' before by editing some artwork in some paint program, and ending up with the colours all messed up.

Great Hierophant
January 3rd, 2016, 02:07 PM
I looked into cshow a little more and found The Tandy Secret. As I stated before, with DOSBox PNGs the program would show frequent errors and draw the image very slowly using the 320x200x16 Tandy mode. (You have to start the program with /J1 to choose these modes). This is necessary if you wanted to view anything that requires better than standard CGA to display. At first I tried converting the images to GIF and PCX, but the same problems would occur. Only if I converted the PNGs to GIFs in the program itself would the images display as they should. I noticed that the program would draw these gifs in series of four lines. This made sense because the 320x200x16 Tandy mode uses an four line interlaced graphics memory organization. Finally I noticed that the "Interlaced" setting for cshow's conversion settings always seemed to be on. When I tried turning them off, the errors reappeared in the GIFs.

I wondered if I converted my PNGs to interlaced GIFs in infranview, would they display correctly as would cshow's interlaced GIFs? I tried it and it worked perfectly, all my Infranview interlaced GIFs would display correctly in cshow but the standard GIFs would not. So, I am now of the opinion that an interlaced GIF will display a screencapture properly with the Tandy 1000 modes as supported by cshow. This also means that I can use a modern PC to convert images instantly instead of using my TX or TL to do it, which is not instant.

Great Hierophant
January 3rd, 2016, 04:06 PM
I tried the cshow program on my Tandy 1000 SX. It works just fine with an 8088 CPU, but otherwise functions as I described above (where I was using a Tandy 1000 TL with a 286 CPU), except that the CGA 160x100 mode, accessible by loading the CGA driver, works properly.

dr.zeissler
January 3rd, 2016, 08:57 PM
I'll have to test cshow again. Afaik it only displayed 640x200 with a "TL" mode but no 320x200@16colors. Therefore I use "gallery" from deluxepaint to display 320x200@16 Tandy Gfx.

cr1901
April 27th, 2016, 03:03 AM
Tbh, I'm a little surprised nobody here has written a modern PNG viewer for 8088 systems. How bad could the decompression routines be :P (Don't answer this)?

krebizfan
April 27th, 2016, 08:21 AM
Tbh, I'm a little surprised nobody here has written a modern PNG viewer for 8088 systems. How bad could the decompression routines be :P (Don't answer this)?

Actually the decompression won't be that bad; the original PKZIP DEFLATE algorithm was designed to run on 8088s. The problem would be memory. Some PNGs require more than 16 MB of RAM to work through which would be difficult to do on a 8088.

My estimate would be that GIF replacement PNG files would take about twice as long to decompress as the corresponding GIF file.

Scali
April 27th, 2016, 08:50 AM
Actually the decompression won't be that bad; the original PKZIP DEFLATE algorithm was designed to run on 8088s. The problem would be memory. Some PNGs require more than 16 MB of RAM to work through which would be difficult to do on a 8088.

You could decode directly to harddisk though, with a 'sliding window' approach. Decode a part of the file, then write to disk.

Stone
April 27th, 2016, 09:21 AM
Dontcha' just love it?

In a world where nearly every computer enthusiast is looking to get stuff displayed faster than the speed of light some of you guys are working on high-tech methods to see how many cups of coffee you can drink before the pic you just clicked on gets fully displayed on your screens. And the funny part is... you would probably need that coffee to stay awake long enough to see the result. :-)

SomeGuy
April 27th, 2016, 09:57 AM
Dontcha' just love it?

In a world where nearly every computer enthusiast is looking to get stuff displayed faster than the speed of light some of you guys are working on high-tech methods to see how many cups of coffee you can drink before the pic you just clicked on gets fully displayed on your screens. And the funny part is... you would probably need that coffee to stay awake long enough to see the result. :-)
Click? You mean like with one of those new-fangled mice? Where it the fun in that? Or do you mean clacking away on a model M keyboard? Nah, toggle switches and connecting bales of wire together all the way down. :cool:

At least you didn't say "swipe". I swear, each time I hear someone say that I want to throw their bacon grease covered tablet/phone to the ground and stomp it in to little bits. And then stomp on it some more. And then stomp on THEM.

Trixter
April 27th, 2016, 10:10 AM
In a world where nearly every computer enthusiast is looking to get stuff displayed faster than the speed of light some of you guys are working on high-tech methods to see how many cups of coffee you can drink before the pic you just clicked on gets fully displayed on your screens.

We're still pushing the state of the art; it's just not on modern systems.

Signed,
Jim "on the leading edge of the trailing edge" Leonard

Stone
April 27th, 2016, 10:28 AM
We're still pushing the state of the art; it's just not on modern systems.

Signed,
Jim "on the leading edge of the trailing edge" LeonardNow, that's quite eloquently put.

Great Hierophant
April 27th, 2016, 10:59 AM
I wonder if anyone ever tried to create a "CGA dump" image format. In order to view a CGA screenshot on any monitor correctly, not only would you need a raw 2-bit per pixel format, you would also need the values of certain CGA registers. These registers are the Color Select and Mode Control registers at 3D8 and 3D9 and registers 0-9 of the 6845 CRTC. A small header attached to each image file would have all the information you would need.

Trixter
April 27th, 2016, 11:02 AM
Now, that's quite eloquently put.

If only it were also financially gainful!

Trixter
April 27th, 2016, 11:16 AM
I wonder if anyone ever tried to create a "CGA dump" image format. In order to view a CGA screenshot on any monitor correctly, not only would you need a raw 2-bit per pixel format, you would also need the values of certain CGA registers. These registers are the Color Select and Mode Control registers at 3D8 and 3D9 and registers 0-9 of the 6845 CRTC. A small header attached to each image file would have all the information you would need.

Actually, I did something similar to that 20 years ago working on Flopper (I wrote the screenshot facility). It didn't work the way you think it did, though. Since we knew people would be running Floppy on VGA systems, IIRC I used vga status registers and the BIOS to retrieve the current palette and color index register values, then I stuffed them into the last two bytes of a raw CGA screen dump. The last two bytes on a typical raw dump are not visible due to 16KiB of memory being available but only 16KB of that is used in typical mode 4/5/6.

I recall graphics programs' capture utilities recording the color index register and palette... DeluxePaint's capture.com might have done that, or Dr. Halo, or maybe PCPaint, or ZSoft PC Paintbrush. I lack the motivation to retry them all to verify, sorry. Pizazz was a commercial screen capture program that stored this info per shot as well.

I don't think there is a reason to make a CGA Dump format. I think the proper thing to do would be to create a valid 8-bit PNG at screenshot creation time that reflects what is visible. Besides, it's not really possible to dump CGA because some registers are write-only and you can't get the current values out of them (unless you're using a clone card that uses something like the Chips & Technologies CT82c425). The best you could do is take those values out of the BIOS Data area and hope that the program you are dumping used the BIOS to set the display colors and palette.

Great Hierophant
April 27th, 2016, 08:56 PM
Indeed, you would have to take the screenshot on an emulator, a clone that allows you to read registers that are write only on the real CGA (all of them I mentioned), guess what values would be correct based on the parameters of the image, or allow the user to input his own values. The last is risky, values that put the monitor out of spec could damage it. If you want a format that can display tweaked text modes, you will need the CRTC values or define particular tweaked modes and let the viewer designate the appropriate mode (160x100x16, 80x100x16, "320x200x16" etc.)

Scali
April 28th, 2016, 12:09 AM
Indeed, you would have to take the screenshot on an emulator, a clone that allows you to read registers that are write only on the real CGA (all of them I mentioned), guess what values would be correct based on the parameters of the image, or allow the user to input his own values. The last is risky, values that put the monitor out of spec could damage it. If you want a format that can display tweaked text modes, you will need the CRTC values or define particular tweaked modes and let the viewer designate the appropriate mode (160x100x16, 80x100x16, "320x200x16" etc.)

Yes, I think it would be nice to have some kind of 'metadata' that describes how the image should be displayed on CGA. This could just be stored in the comment-field of a GIF image.
And yes, if grabbed from a real PC, you wouldn't be able to fill the metadata, but you could edit it later, with the viewer. The viewer could allow you to tweak the palette and other metadata, and write it back to the comment-field in the GIF when you're done adjusting it.
You could also put in some safeguards for the tweaking of registers, so you are only allowed to pick 'safe' values (you should only adjust the visible width and height, and the remaining values could be derived from that automatically, so you always get a properly timed CGA-frame)... And perhaps a manual override at your own risk.

Trixter
April 28th, 2016, 06:39 AM
Tbh, I'm a little surprised nobody here has written a modern PNG viewer for 8088 systems.

Compushow mentioned above displays PNG files; is that deficient?