ColorGraphicsAdapter (CGA) Thread (Games/Demos/Intros/GFX-Art/ASCII etc.)

[dr.zeissler]

Any idea, why xenon2 in CGA is only b/w ?
https://www.youtube.com/watch?v=Sm6StU-SBzk

These CGA-Games look really good with the alternate-pal:
https://www.youtube.com/watch?v=4ALFWx1ufVk
https://www.youtube.com/watch?v=vcbGpQdIU0A
https://www.youtube.com/watch?v=X74Z4K-2dIs
https://www.youtube.com/watch?v=NHlNABiR1zk

Doc

[derSammler]

Any idea, why xenon2 in CGA is only b/w ?

Because it uses 640x200 and dithering. They probably borrowed that mode from the Atari ST version.

[konc]

Pharaoh's Tomb and The Monuments of Mars also use the alternative palette, but I guess there are many more games doing so. The really interesting ones are those that either let you choose or switch palettes in-game.

4X4 Off-Road Racing also has some not-so-common colors.

[reenigne]

Any idea, why xenon2 in CGA is only b/w ?

Because it uses 640x200 and dithering. They probably borrowed that mode from the Atari ST version.

I think so too. I was going to say "it's probably designed for composite output" but there doesn't appear to be any rhyme or reason to the colours you get by doing so.

Designers of some CGA games just decided to use the 640x200 mode for one reason or another - usually because they preferred more resolution (or in this case, more dithered shades of grey) over more colours. Games designed for 640-pixel EGA or VGA modes that were given a CGA mode as an afterthought often do this (e.g. the original Sim City).

[dr.zeissler]

I thought Xenon2 on the Atari was color only, but how cares?

Currently searching for some bbs-stuff, perhaps some 16color-textmode-scene stuff (beside the early stuff linked on site one) is available.

[derSammler]

Xenon 2 on the ST was one of the few games that supported color and b/w.

[dr.zeissler]

I wrote one, which you can get at http://www.reenigne.org/misc/cgaart.zip. .

Does not work on my iMac with wine.

[reenigne]

I wrote one, which you can get at http://www.reenigne.org/misc/cgaart.zip. .

Does not work on my iMac with wine.

I don't know why it wouldn't - it doesn't use any Windows APIs in a particularly complicated or non-standard way. Did Wine give any indication of what the problem might be?

[dr.zeissler]

I get no error message at all, it simply does not open a window. I'll have to check if there were log-files. I will go for my win9x laptop instead.
*1
now testing winxp, because win98se does not work either.
*2
no, winxp reports missing dll "msvcr120.dll", after installing this dll, I get an "GetLogicalProcessorInformation" error in "KERNEL32.DLL"

[dr.zeissler]

ftp://ftp.hornet.org/pub/demos/code/con ... /info.html

@JIM

were there any productions for this toppic?

Don't have any ideas? Then convert one of your exiting demos (or someone else's demo) to work on a slow machine with CGA! Higher scores may be awarded to faithful conversions of parts of Future Crew demos, Triton demos, and others (like Unreal or Crystal Dream's vector parts, etc.). For instance, this message goes to members of Orange, Impact Studios, Epical, Xtacy, Halcyon, Capacala, Iguana, and others: Convert your winning demos to 8086!

These are just a few suggestions... be creative!

[reenigne]

I get an "GetLogicalProcessorInformation" error in "KERNEL32.DLL"

The program does run on Windows XP, but requires SP3. This is because it was compiled with Visual Studio 2015, and the corresponding C++ runtime unfortunately requires SP3. Still, it's good that we can target XP with VS2015 at all (we had to fight for that).

[dr.zeissler]

Thx, I will install SP3 for XP an that laptop in the next days and have a look on the cga-prog.

[dr.zeissler]

Some interesting Information written by G.H. thx for that!

B. The Color Graphics Adapter (CGA) (1981)
This was the other video adapter choice for IBM PC buyers, and was far more suited to games than text. However, as a gaming adapter it was weak, inferior to almost every other home computer on the market at first glance. The mode that at least 95% of games use is the 320x200 mode 04h. In this mode the programmer could use 4 colors from two predefined palettes,

palette 1: background/cyan/magenta/white or
palette 0: background/red/green/brown.

The background’s default color was black, but could be changed to any of the 16 colors.
No border would be displayed because the background and border colors are shared in this mode.

The palette could be set to alternate intensity so that the palettes consisted of

palette 1: background/light cyan/light magenta/bright white and
palette 0: background/light red/light green/yellow.

By disabling the color burst bit, a third rarely used RGBI palette of background/cyan/red/white can be obtained.

Its high intensity variant would be background/light cyan/light red/bright white.

IBM defined these palettes; they are not based on the Motorola chip. A 4 shades of gray palette could have been selected using mode 05h, which was a grayscale version of mode 04h. This only could be viewed through a connection to a composite monitor. However, IBM PCs were designed to hook up to RGB TTL monitors (15.75kHz horizontal scan frequency), which are much crisper than NTSC display devices, which many other computers of the time hooked up to. IBM’s color display was model 5153. The encoding scheme is 1 bit for Intensity 1 bit for R, G, B, in high to low order. Each byte of graphics data represents the color of 4 pixels. The high resolution 2 color mode 06h, with a 640x200 resolution, is usually black and bright white, but the user can change the foreground pixels to any of the 16 colors, but the background color will remain black. (In later adapters the background color may also be set.) The 16 colors are:

Code: Select all

Color               Hex Value     R   G   B

Black                      00h       0   0   0
Blue                       01h       0   0 170
Green                      02h       0 170   0
Cyan                       03h       0 170 170
Red                        04h     170   0   0
Magenta                    05h     170   0 170
Brown                      06h     170  85   0
White (Light Gray)         07h     170 170 170
Dark Gray   (Light Black)  08h      85  85  85
Light Blue                 09h      85  85 255
Light Green                0Ah      85 255  85
Light Cyan                 0Bh      85 255 255
Light Red                  0Ch     255  85  85
Light Magenta              0Dh     255  85 255
Yellow (Light Brown)       0Eh     255 255  85
Bright White               0Fh     255 255 255

Naturally, many programmers thought that these choices were horrible and they had other ideas. In addition to an RGB out to a digital color monitor, IBM’s CGA cards had a composite out that could be used to connect to a composite monitor. This would allow the programmer to access a new mode, a 160x200 mode with 16 colors, using the same method as the Apple II. This mode was a supported feature although not a BIOS mode, but useless without an original CGA or some EGA cards because it uses the NTSC color burst signal and timing to select the color. Today, if the mode is selected it in a game modern display adapters will adopt it to the 640x200x2 mode, which it was derived from.

The worst problem is when the programmers tried for the full 16 colors on an RGB monitor. The good thing was that the CGA’s text modes allowed for 16 foreground and 16 background colors to be set in the character’s attribute byte. The border color could be set to any of 16 colors. So the programmers used certain ASCII characters to approximate pixel graphics. However, as an 8x8 character is a bit inflexible, many programmers used hacks to cut down the characters to more useable sizes. These modes use very low or awkward resolutions. One method is to use the 40 or 80 column text modes and shorten the cell sizes to two lines, giving an 8x2 character cell to work with. Using 40 column modes gives the user two graphic pages on a CGA card, unlike the graphic modes. Using the 80-column mode and the left vertical bar, ASCII 211, will give an effective 2x2 pixel size with two pixels in each “column.” This is the 160x100 graphics mode. Also, other programmers tried to get more than 4 colors out of the 320x200 mode through hacks, such as switching palettes in mid-frame and tweaking the palette to cyan, red, white. These hacks are very difficult to reproduce without a card with 100% register compatibility with the CGA. An 8088 processor running at 4.77272MHz is also critical for these hacks.

The CGA was limited in other ways. It was not quick at all, considering it was usually pared with a very inefficient 4.77272Mhz 8088, which often meant flickering images because the card cannot draw to the screen fast enough. If the programmer wrote to the screen too quickly in the 80-column text mode, snow on the screen would be the result due to single ported memory that can only read or write, not both, at the same time. The CPU would be writing to the video memory at the same time as the video display circuitry was trying to read to the video memory, so the video display circuitry would get a random result that would translate into white lines a character cell wide. Snow can be reduced by waiting for vertical retrace or using the BIOS to write to the video RAM, but both methods were much slower. IBM’s CGA card has 16KB of video memory interlaced into two 8KB banks. This was a brain buster for programmers because they had to draw and store their graphics in an interlaced fashion, even lines before odd lines and skip 192 bytes per bank. Why IBM designed it in this way remains a mystery. Finally, the 8x8 pixel format for text (which only had the blink attribute in hardware but could simulate boldness and inverse to an extent) made for some very unsightly text, especially for those characters with descenders, g, j, p, q, y that go underneath the line. But for 1981 through 1985, the CGA was the only affordable color graphics available for most PCs. The high price of PCs combined with this weak video hardware led to few PC exclusive games and a lot of inferior ports. Its character ROM is 4KB, used for a 5x7 single dot font (abandoned in VGA) and 7x7 double dot font, both using 256 patterns, selected by a dipswitch on the cart. It uses a 16KB video RAM buffer starting at $B0000.

Code: Select all

Alphanumeric Modes:
Mode    Cell  Column   Colors   Buffer  H/V Resolution  Pages
      Size   /Row
00h    8x8      40x25  16 grays  B8000h  15.75kHz/60Hz   8
01h   8x8      40x25  16        B8000h  15.75kHz/60Hz   8
02h    8x8      80x25  16 grays  B8000h  15.75kHz/60Hz   4
03h    8x8      80x25  16        B8000h  15.75kHz/60Hz   4

Code: Select all

All Points Addressable Modes:
Mode    Resolution  Colors    Buffer  H/V Resolution  Pages
04h     320x200      4 preset  B8000h  15.75kHz/60Hz   1
05h     320x200      4 grays   B8000h  15.75kHz/60Hz   1
06h     640x200      2/16      B8000h  15.75kHz/60Hz   1#

# 16 colors are only available with the color composite signal and reduces the effective resolution to 160x200. It is not a BIOS mode.

[dr.zeissler]

https://scalibq.wordpress.com/2014/11/2 ... eblasters/

Scali wrote an interesting article about the CGA-Demo. It's the best CGA Demo, if you don't have a compatible machine for 8088mph.
It's target is 8088/4,77. I have V20 9,54, so there is a bit free-cpu time. Perhaps I am able to try to manipulate the code to get a bigger
Rasterbar or add a starfield, scroll-text (if I find some demo.asm to borrow) ...

[Jo22]

It probably is. I do have an XT clone with NEC D8088D @4.77Mc/s and monochrome composite "CGA" (50Hz?).
Yet, 8088mph still doesn't show any picture (but I *guess* runs, 'til I press ESC).
Edit: Fixed the writing.

[reenigne]

Some interesting Information written by G.H. thx for that!

This is almost but not entirely accurate.

By disabling the color burst bit, a third rarely used RGBI palette of background/cyan/red/white can be obtained.

But only on RGBI monitors.

A 4 shades of gray palette could have been selected using mode 05h, which was a grayscale version of mode 04h.

Not all IBM CGA cards displayed this mode as 4 shades of grey. On early cards, the red, cyan and white colours all displayed as the same shade of white on the composite output when colour burst was disabled (the effect of using BIOS mode 5 instead of BIOS mode 4 is to disable the colour burst).

However, IBM PCs were designed to hook up to RGB TTL monitors (15.75kHz horizontal scan frequency), which are much crisper than NTSC display devices, which many other computers of the time hooked up to.

Using NTSC monitors or TVs (and displaying colour on them) was an original goal of the IBM PC from the beginning (hence the CPU speed being 4.77MHz instead of 5MHz).

The 16 colors are:

Code: Select all

Color               Hex Value     R   G   B

Black                      00h       0   0   0
Blue                       01h       0   0 170
Green                      02h       0 170   0
Cyan                       03h       0 170 170
Red                        04h     170   0   0
Magenta                    05h     170   0 170
Brown                      06h     170  85   0
White (Light Gray)         07h     170 170 170
Dark Gray   (Light Black)  08h      85  85  85
Light Blue                 09h      85  85 255
Light Green                0Ah      85 255  85
Light Cyan                 0Bh      85 255 255
Light Red                  0Ch     255  85  85
Light Magenta              0Dh     255  85 255
Yellow (Light Brown)       0Eh     255 255  85
Bright White               0Fh     255 255 255

These are the nominal equivalent colours on a modern sRGB system, but these numbers don't actually occur anywhere in a real CGA system (the RGBI signals are converted directly into analogue signals inside an RGBI monitor without being encoded as 8 bits per channel in between).

Naturally, many programmers thought that these choices were horrible and they had other ideas. In addition to an RGB out to a digital color monitor, IBM’s CGA cards had a composite out that could be used to connect to a composite monitor.

This implies that programmers came up with the composite colours. The composite colours were designed into the system from the beginning.

This would allow the programmer to access a new mode, a 160x200 mode with 16 colors, using the same method as the Apple II.

It's extremely similar to the Apple II, but the circuitry is different. It's also not *really* a 160 column mode (although programmers often treated it as such) because the "pixels" blend into each other via transition artifacts. So it can also be considered to be a 640x200 mode but with a particular analogue filter applied to it to convert patterns of certain frequencies into colours.

Today, if the mode is selected it in a game modern display adapters will adopt it to the 640x200x2 mode, which it was derived from.

It's not really a matter of "today" vs. "then" - it's a matter of what kind of monitor is connected (and the card in question having support for composite output).

The worst problem is when the programmers tried for the full 16 colors on an RGB monitor.

Worst according to whom?

These hacks are very difficult to reproduce without a card with 100% register compatibility with the CGA.

Everything's difficult until you know how...

An 8088 processor running at 4.77272MHz is also critical for these hacks.

It actually isn't really. It works fine on faster machines if the PIT is used to time the register changes (the PIT and graphics adapters with real 200-scanline modes were both based on the same 14.318MHz crystal). The reason this rumour persists is that the best known example of the "raster synchronized palette change" effect (California Games) had a bug in its speed test code which unintentionally failed on faster CPUs. If this test is fixed, the effect works fine on faster machines. The 160x100x16 mode is not speed dependent at all and works fine on most clones (and even on EGA/VGA if the software detects the card and uses a different set of register writes).

It was not quick at all, considering it was usually pared with a very inefficient 4.77272Mhz 8088, which often meant flickering images because the card cannot draw to the screen fast enough.

Flickering is really an issue with the software rather than (solely) the card being too slow. With sufficiently clever programming, most CGA flickering issues can be cured. Commander Keen 4 has exceptionally complex graphics for a CGA game, but doesn't flicker at all (though it is extremely slow on a 4.77MHz 8088).

If the programmer wrote to the screen too quickly in the 80-column text mode, snow on the screen would be the result

It's not a matter of writing "too quickly". Any CGA RAM access in high-res text mode will result in snow unless care is taken to avoid it (the BIOS has CGA writing routines to do this "taking care", but they're slow - special purpose routines can be faster).

due to single ported memory that can only read or write, not both, at the same time.

Very few graphics adapters used dual-ported memory - standard DRAM was much cheaper. Usually (and on the CGA in other modes), clever circuitry interleaves CPU and CRTC accesses to avoid the snow, but 80-column mode pushed the limits of available RAM bandwidth and snow was the result.

Snow can be reduced by waiting for vertical retrace or using the BIOS to write to the video RAM, but both methods were much slower.

Waiting for horizontal retrace (actually display disable) was faster (but still slow compared to "snowy" access).

IBM’s CGA card has 16KB of video memory interlaced into two 8KB banks.

Only in graphics modes.

This was a brain buster for programmers because they had to draw and store their graphics in an interlaced fashion,

Either store or draw, but not both. It's usually not a problem in practice because for speed you usually want to use a lookup table to convert y coordinates to "start of line" addresses (avoiding multiply by 80) and the interlace computations can be folded into that table.

Why IBM designed it in this way remains a mystery.

It's not a mystery at all. It's a consequence of the fact that the MC6845 CRTC chip that IBM used for the CGA's memory addressing and sync pulse generation only has 7-bit vertical (row) counters, so can only display a maximum of 128 rows (plus up to 31 extra scanlines during vertical overscan). So to get the ~262 total scanlines that an NTSC (or other 60Hz vertical, 15.7kHz horizontal) monitor requires, it's necessary to have at least 2 scanlines per row. Converting the CRTC memory address to a RAM address requires using one or more "row address" (i.e. scanline within row) bits to disambiguate the address. The two most logical places to put this extra bit are: less significant than the least significant memory address bit, or more significant than the most significant memory address bit. IBM chose the latter, as it made the circuitry simpler given that text modes did not need interlacing.

Other graphical machines based on the MC6845 (such as the Acorn BBC Micro and the Amstrad CPC) had the same problem. Both of these machines used 8 scanlines per row by default. Acorn made the row address bits the least significant, Amstrad made them most significant like the CGA if I recall correctly.

Its character ROM is 4KB, used for a 5x7 single dot font (abandoned in VGA) and 7x7 double dot font, both using 256 patterns, selected by a dipswitch on the cart.

There is no dipswitch on a standard IBM CGA card. You'd have to do some cutting/soldering to access the "thin" font.

It uses a 16KB video RAM buffer starting at $B0000.

$B8000. With an alias at $BC000.

Code: Select all

00h    8x8      40x25  16 grays  B8000h  15.75kHz/60Hz   8

Again, early cards could not do 16 shades of grey (only 4).

Code: Select all

04h     320x200      4 preset  B8000h  15.75kHz/60Hz   1
05h     320x200      4 grays   B8000h  15.75kHz/60Hz   1
06h     640x200      2/16      B8000h  15.75kHz/60Hz   1#

# 16 colors are only available with the color composite signal and reduces the effective resolution to 160x200. It is not a BIOS mode.

The 320x200 modes could also do 16 colours on the composite output (although the colours are less consistent between revisions of the card than they are in BIOS mode 6). The BIOS didn't have direct support for 160 columns or 16 colour graphics, but you could still use the BIOS routines regardless of what kind of monitor you had connected.

[reenigne]

And another thing...

The 16 colors are:

Code: Select all

Color               Hex Value     R   G   B

Black                      00h       0   0   0
Blue                       01h       0   0 170
Green                      02h       0 170   0
Cyan                       03h       0 170 170
Red                        04h     170   0   0
Magenta                    05h     170   0 170
Brown                      06h     170  85   0
White (Light Gray)         07h     170 170 170
Dark Gray   (Light Black)  08h      85  85  85
Light Blue                 09h      85  85 255
Light Green                0Ah      85 255  85
Light Cyan                 0Bh      85 255 255
Light Red                  0Ch     255  85  85
Light Magenta              0Dh     255  85 255
Yellow (Light Brown)       0Eh     255 255  85
Bright White               0Fh     255 255 255

Naturally, many programmers thought that these choices were horrible

I can't speak for all programmers, but my understanding is that when people say "the CGA colours are horrible" they're usually referring to the stereotypical cyan/magenta/black/white combination (which is pretty garish). The full RGBI palette of 16 colours above (also the palette for PCjr/Tandy when not using composite, and for EGA games that use 200-line modes, which is nearly all of them) is not nearly so universally abhorred, and some artists have made some fantastic images using it (see the ANSI art scene).

I don't have much in the way of artistic skill, but I think it's a much nicer palette than (say) that of the ZX Spectrum or the default palette of Windows in a 16-colour mode. The lack of full-saturation red/green/blue/yellow/cyan/magenta does mean that there are some sRGB colours which can't be displayed even by dithering, but it does reduce the overall garishness. The C64 palette has some more useful gradients but an even smaller gamut (for better or for worse).

[dr.zeissler]

CGA-ANSI-ART is one of the main targets here, especially if it uses some srolling-features in software or hardware (if possible).
I remember a "test-program" that scrolls white text in 80colums-mode simultaniously horizontal and vertical completly stutterfree.
(on my Scheinder EuroPC with CGA Color Monitor 1990)

Currently I have no ANSI-ASCII-ART for CGA collected, but that would be very nice if suitable software can be found that works
with a small XT and CGA.

[reenigne]

CGA-ANSI-ART is one of the main targets here, especially if it uses some srolling-features in software or hardware (if possible).

ANSI art is just data - it can be displayed on any machine that can display ANSI (including CGA) with a suitable viewer program.

I remember a "test-program" that scrolls white text in 80colums-mode simultaniously horizontal and vertical completly stutterfree. (on my Scheinder EuroPC with CGA Color Monitor 1990)

Currently I have no ANSI-ASCII-ART for CGA collected, but that would be very nice if suitable software can be found that works with a small XT and CGA.

Let me know if you can't find any - it's not a very difficult program to write. At the very least there's ANSI.SYS, though that's likely to be slow and you might need another little program to disable flashing. Also it can't scroll horizontally, but ANSI art is usually only 80 columns wide anyway.

[dr.zeissler]

The cool thing about ANSI-Art is that it has 16colors while using textmode even with cga
Perhaps "checkit" had a test for textmode with scrolling in both ways...but I am not sure.