Color Graphics Adapter is a former featured article. Please see the links under Article milestones below for its original nomination page (for older articles, check the nomination archive) and why it was removed. | |||||||||||||
| |||||||||||||
Current status: Former featured article |
This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
The 8088 mph demo showed how to do high colour modes on CGA composite going well beyond the previous colour ranges.
http://www.reenigne.org/blog/1k-colours-on-cga-how-its-done/ http://8088mph.blogspot.co.uk/2015/04/cga-in-1024-colors-new-mode-illustrated.html
so these probably want incorporating into the tricks and tweaks
Alan Cox ( talk) 09:44, 21 April 2015 (UTC)
How does the 160x100 fit into 16K? Each character occupies two bytes of RAM -- one for the character itself, and one for the attribute. Thus, that's 160×100×2 = 32000 bytes. I buy that machines that use the MC6845 with 32K of RAM can display this mode, but an original 16K machine shouldn't be able to properly—the bottom half of the screen should show the same as the top half. I took a peek inside the
MESS code, and it appears they just put 32K on all CGA variants. (ref: "offs=(offs+2)&0x3fff
" in the text renderers) --
Mr z 23:21, 20 October 2007 (UTC)
Hi does anyone know about the signals applied through the pin's to give you the colour and what would they be?
Just a quick note that in one of the edits, I said "if you have a problem with the CGA color palette, contact me" but then realized later that I wasn't logged in. I am the one who put the final, correct CGA colors into the palette table -- if you want to change them you'd better have a good reason because I took them from the actual MC6845 specs and verified them with a TTL scan converter. Most people who think they know CGA colors seem to forget that when you toggle the brightness bit, ALL colors go bright, not just the ones that are supposed to go bright. Trixter 15:09, 20 Aug 2004 (UTC)
Goplat, I think you're confusing the 160x100 "tweaked text" pseude-graphics mode with the 160x200 composite mode. They were two totally different things:
The 160x100 tweaked text mode was achieved on standard RGB monitors. The 160x200 mode was ONLY available on the CGA card's composite video output (which you could hook up to your telly.) It had nothing to do with text mode. It was a seperate graphics mode in its own right -- only that few folks used it as most CGA boxen were hooked up to RGB monitors permanently.
As regards your video RAM size objection:
Fair enough?
Ropers 22:16, 20 Aug 2004 (UTC)
I don't know what mode it was, but I know for a fact that Bards Tale ]I[ became 16 color when I discovered that I could plug my TV into my computer.
I had been playing it with just the 4 colors that my Compaq 8088 (or was it 8086?) could produce.
When I discovered the 16 color trick, I played around in BASICA, and discovered that 2 pixels side-by-side were being interpreted as just one color on TV, with an aggregate of the color taken.
So I don't know if it was a different mode or not, or if it was the same mode just being interpreted differently by the two displays, or what. =^_^=
It was quite a shock to see that Bards Tale III was suddenly pretty..!
I just went through the article again, trying to bring the writing up to FAC standard. I cut a lot of side issues out to try to keep the actual points clear. Also worked over 160x200 16-color severely - it was confusing before, but I think it gets the point across now (and I think I got the point now) - David Gerard 21:47, 24 Aug 2004 (UTC)
It might be worth mentioning a couple of extra points:
In my experience of my first PC I know of additional palettes for the CGA. Now I must disclaim this saying that I had an Amstrad PC1512, which may have been custom-fit to produce unusual features. That said, I saw the following:
I repeat, I don't know how much of this is peculiar to the Amstrad PC1512, or could be achieved on any CGA card through hacking. -- Shlomital 10:24, 2005 Jun 2 (UTC)
I've added a table for the tweaked 3rd palette in the "tweaks" section, but my HTML skills aren't what they used to be and I can't figure out why it is too wide. Can someone fix the table for me? Thanks in advance! Trixter 17:20, 4 January 2006 (UTC)
This claim seems to be nonsense. The MC6845 produced only the address of the current pixel, it was up to other chips to read that address and actually display the color(s) stored there. If anybody can explain how those hex values were derived, please do so. -- 84.58.33.21 14:23, 29 July 2005 (UTC)
Well, well, this makes it the fourth version of the CGA colour palette values I've seen. Earliest, the numbers were (hex) 00, 54, B0, FE. Then, it was 00, 54, A8, FC. Later, on a previous version of this article, they were 00, 54, A8, FE. And now it's 00, 55, AA, FF, which I first saw as the "Linux console" colour palette for GNOME Terminal. I still don't know which one is correct (I root for 00, 54, A8, FC, if only because screenshots from the DOS window on Windows 9x, as well as from DOSBox, give out those colours), and I don't know even how to find the answer out, but please, if anyone does, bring it here, with evidence that it's the correct one, because all that juggling doesn't make for a reliable source. -- Shlomital 17:14, 27 February 2006 (UTC)
The original CGA from IBM was actually called "Color/Graphics Monitor Adapter" (C/GMA) (see this auction for pictures: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=8712503810), and the BASICA graphics demos on the DOS 1.x system disks call it that as well. I don't know when exactly the shortened name "CGA" came up (maybe when clones were produced?), but this original name should probably be incorporated in the main article. NewRisingSun 21:12, 16 December 2005 (UTC)
It was recently discovered [2] that IBM's original CGA monitor (IBM 5153 Color Display) displays color 6 differently than most compatibles (closer to what you'd expect if you strictly applied the RGBI color model). This should definitely be reflected in the article (as quite a number of games depend on it!); feel free to change my markup to something prettier... :) NewRisingSun 19:50, 17 January 2006 (UTC)
I think it needs to be made clear that the font used in graphics modes comes from a completely different source than the font used in text modes - hence my use of "separate". The text-mode fonts are in the character ROM on the card itself; this ROM doesn't appear in the PC's address space, so the BIOS contains its own 128-character font that it uses in graphics modes. On an original IBM PC with an original IBM CGA, the two fonts are the same so the effect isn't noticeable; but putting an IBM CGA card in an Amstrad PC2086, which has a completely different BIOS font, soon shows the difference. This is also the reason why changing the font jumper on the card doesn't change the font used in graphics modes. HungryHorace 10:33, 3 February 2006 (UTC)
It would be great if some knowledgable person could add the pinout of the CGA video connector. A drawing of the physical connector can be taken from the EGA article. -- 84.130.16.237 16:38, 3 July 2006 (UTC)
I made some larger changes to the article, and in order to avoid any needless reverting, I temporarily put them under User:NewRisingSun/cga.
Please review the changes and discuss. The picture markup is probably suboptimal as well. I'm also a little bemused by the constant past tense of the article; while it is appropriate to describe when it "was" sold, the inner workings of the CGA are still the same. ;) -- NewRisingSun
I changed the rather vague "this could be changed" about the black and white in hi-res monochrome mode to this text:
By default the colors were black and white, but the foreground color (white) could be changed to any other color of the CGA palette. This could be done at runtime without refreshing the screen.
I know for certain that this is possible, there is a game [4] that allowed the player to change the foreground color with a keystroke. What I don't know is whether it was possible to change the background color too (as could be done in lo-res). I don't think so, since I've never seen it done (though the background color would often display incorrrectly on a VGA display).
Another thing that bugs me is the following sentence in the paragraph about text mode:
This mode allowed each character a foreground and a background color, both of which could be freely chosen from the entire CGA palette (see table)—e.g. red on yellow text for one character, white on black for the next and cyan on gray for yet another.
Is this really true? As far as I remember, you can't set the background to a bright color in VGA text mode. If you do, the character will blink instead. Somehow it seems unlikely to me that this is a feature that was introduced later, and I'd expect the CGA to behave the same way. -- 213.47.127.75 20:17, 12 March 2007 (UTC)
How did the CGA compare on a techincal level to other graphics adapters, computers, consoles, etc. sold in its time (1981 - 1987)? Shinobu 18:08, 2 September 2007 (UTC)
I feel that the first two images, Image:Arachne CGA Mode.svg and Image:Cosmos bipinnatus0 CGA.png are very bad choices. They were both artificially created much later than the CGA era (and apparently with non-CGA hardware) and they are not representative of the actual use to which the Color Graphics Adapter was put in its time. One is an image of a browser that didn't exist in the CGA era and the other is a down-conversion from a better image. They're both nice enough pictures alright, but they don't inform, they mislead, because they're not depicting the past, but a latter-day reimagination of the past. The flower picture is also misleading because of the way ImageMagick (part of the Wikipedia server software) generates its thumbnails -- ImageMagick makes that picture thumbnail look much better than the exact picture would or could ever have looked on a CGA monitor. I suggest that these images be replaced by more representative pictures. Moving up the Alley Cat image later on in the article would be an excellent choice. That game was well-known and widespread during the CGA era. 86.56.48.12 20:26, 11 September 2007 (UTC)
I have put the image back in.
Removed FS dithered image because it is misrepresentative of CGA. CGA had many different palettes, and the dithering in the image further confuses the adapters abilities.
Regarding the comments posted above in this section:
Shinobu 01:41, 10 November 2007 (UTC)
Why are the images stretched like they are? It looks awful. SharkD ( talk) 03:05, 23 March 2009 (UTC)
...And a reason for not using this image that seems to have been missed by everyone: Doesn't the "C" in "CGA" stand for "color"? This why put a screen capture of black and white graphics at the top of the article?-- Drvanthorp ( talk) 21:31, 18 June 2011 (UTC)
OK. Some anonymous user just reverted the Fractint image back to the Arachne image with the non-CGA aspect ratios. If you want to use Arachne, then please use the one stretched to 640x480. CGA does not use a 1:1 pixel-aspect ratio, it is 1:2.4. Any CGA screen shot that isn't scaled to this aspect, by definition, is not presenting what CGA actually looks like. Shamino ( talk) 14:14, 9 August 2014 (UTC)
Done, an image with a more correct ratio is there. 4throck ( talk) 18:09, 11 August 2014 (UTC)
I emailed the author at http://www.digger.org/index.html and asked permission to use the Digger animated graphic seen on their webpage: http://www.digger.org/animate.gif
It is a perfect example of CGA in action, using a popular game from the period.
Kreline ( talk) 06:12, 11 February 2008 (UTC)
I went ahead and added it. If the animation is found to be annoying, it would be easy enough to edit the image to preserve only the first frame. -- Kreline ( talk) 04:09, 21 September 2008 (UTC)
The story of CGA is not complete without including a mention of this game.
http://www.mobygames.com/featured_article/feature,10/section,40/
http://www.mobygames.com/featured_article/feature,10/section,41/
http://www.mobygames.com/game/dos/icon-quest-for-the-ring/reviews/reviewerId,67846/
This game took the "tweaked text mode" technique to a new height. It used many other ASCII characters that were available, not just the "left block" and "right block" characters. Using drawing techniques of ASCII art, an effective resolution of 320x200 was created.
The 320 comes from 40 columns of text characters, at 8 pixels per character. 80-column mode was not used, because it was too slow, and because of the well-known "snow" bug of CGA's 80-column mode.
The 200 comes from 100 rows of text characters, using only the top 2 pixels of each character, just as in 160x200 mode.
The graphics have a distinctive look, as the available shapes were limited to what happened to be in the top 2 rows of pixels for each of the 256 text characters in the CGA's ROM. For example, the top of the "2" character produced a distinctive shape that looked like a musical slur, useful for drawing graphics that looked like waves in water.
Since this "320x200" mode was a text mode, it could use all 16 colors. This gave the graphics an appearance that could, at first glance, equal the 16-color 320x200 resolution of the EGA.
Perhaps the best example of this can be seen in the title screen of the ICON game: http://www.mobygames.com/game/dos/icon-quest-for-the-ring/screenshots/gameShotId,695/
Kreline ( talk) 06:12, 11 February 2008 (UTC)
Thanks for the feedback. I changed the phrase of "160x200 technique" simply to read "tweaked text mode", to avoid this confusion. The reader can read the rest of the article if they're interested in learning more about the resolutions of the various tweaked text modes.
FYI, the game did in fact achieve a vertical resolution of 200, by using the top 2 pixels of each of 100 rows of text characters. The major drawback was that not all the pixels were individually addressable. This gave ICON its distinctive appearance, as the programmers were limited to shapes found in the top two rows of each of the text characters in the BIOS of the CGA.
-- Kreline ( talk) 22:03, 11 August 2008 (UTC)
This is a forum thread, but maybe this info, particularly the info at post number 4 and 5, could be incorporated into the article? 86.56.122.190 ( talk) 08:42, 22 June 2008 (UTC)
In the RGBI section, is the formula to convert to RGB floating point values supposed to be in C? If then, shoudn't it read something like:
red = 2.0/3.0*(colorNumber & 4? 1:0) + 1.0/3.0*(colorNumber & 8? 1:0); green = 2.0/3.0*(colorNumber & 2? 1:0) + 1.0/3.0*(colorNumber & 8? 1:0); blue = 2.0/3.0*(colorNumber & 1? 1:0) + 1.0/3.0*(colorNumber & 8? 1:0);
Of course it is understandable the way it is, but I think it's a little bit better if it can be correctly executed. Samuel Lowry ( talk) 17:08, 6 November 2008 (UTC)
A. Video memory: The Toshiba 2016 chips are 2kB each and thus there are only 4kB on the board. The other chips are logic only. 4kB are not enough for a Hercules card so this should be a MDA clone (80x25x2 = 4000).
B. Clock: There is a 16MHz crystal on the board. CGA uses the 14.3xx MHz provided by the ISA bus as pixel clock and thus needs none of its own. MDA/Hercules adapters use 16MHz crystals. —Preceding unsigned comment added by 84.149.168.172 ( talk) 18:09, 2 July 2009 (UTC)
Maybe this information (in the yellow box) should go into the article? 31.16.112.242 ( talk) 22:20, 19 June 2011 (UTC)
Did IBM-made CGA cards sold in Europe output PAL? Or NTSC? Or neither? Please add. -- 78.53.146.224 ( talk) 11:45, 14 May 2012 (UTC)
Each byte in memory is represented on screen with pixels from smaller to higher.
I remember, back from my college days in 1988, that the Micro Plato software we used (an MS-DOS port of PLATO running courseware from floppy disk) generated a monochrome graphics mode with more than 200 lines on a standard CGA adapter. Some of our monitors could not display this resolution at all. Those that could were either NEC Multisync displays or needed us to twiddle the hold knobs in order to create a stable image. We typically also needed to adjust the size knobs to make the image wider and shorter in order to fit on-screen.
Is anyone familiar with this software and what it was actually doing to generate this unique graphics mode? Are there any CGA wizards who might have a good theory? Shamino ( talk) 17:39, 10 February 2014 (UTC)
It would seem that when arcade hardware buffs use the term "CGA", what they mean is 15KHz analog RGB, not digital IRGB (which is what CGA really is); needless to say, the two types of signal are not compatible. This usage has become widespread enough on the web to mislead and confuse (just run a web search for "CGA monitor" or "CGA converter" to see what I mean). I wonder if it's just plain ignorance or perhaps there is some sort of reasoning behind this.
At any rate, due to the popularity of this wrong usage of the term, perhaps a short clarification should be appended to the article, to alert readers to the distinction. 79.179.67.98 ( talk) 23:52, 28 April 2014 (UTC)
I reverted the edit that sorted the 16-color palette; all other palettes on the page are unsorted, and viewing the 16-color palette unsorted illustrates the relationship the intensity pin had on color generation. Additionally, most pages that describe 8-bit color modes also show their modes unsorted. Trixter ( talk) 17:04, 30 June 2014 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Color Graphics Adapter. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
{{
dead link}}
tag to
http://www.lauppert.ws/screen1/cga/When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 16:24, 4 September 2017 (UTC)
Some of the example images provided in this page are of copyrighted material, and have been automatically shrunken by the fair use image resizer bots. This is fair enough, but the reason the images are there in the first place is to get an idea of how the palettes listed on this page are used in creative ways. For this, you really want images to be in native resolution, so the bots are spoiling them.
The best way to fix this would be to replace the game images with images of free alternatives if possible, or simply removing them if not. -- 2602:30A:2C3A:6810:20F:60FF:FE0C:539D ( talk) 08:39, 27 June 2018 (UTC)
I guess I don't understand the fascination with this hardware, esp. the recent interest in the composite output which attains a wider color palette as a byproduct of NTSC artifacting and not as an inherent feature of the hardware? Apple was doing that years before the PC.
Video game consoles of the time were more aesthetically competent than IBM's overpriced hardware.
IBM's green monochrome display was a thing a of beauty though, and you actually could do "pseudo" graphics with that if you were willing to manipulate the character set and perform other trickery.
JMHO. 108.200.234.93 ( talk) 06:45, 5 January 2020 (UTC)
I have recently rewritten much of this page, and while a lot of it is valid pending sourcing (I have magazine articles and literature refs, they're just very tedious to add so I haven't done all of them yet) the situation with 160x100 is concerning.
While 160x100 is often referred to as "undocumented" or other such things on other sites, and has been referred to that way here, this isn't quite true true. It is documented, just very poorly. IBM's original technical manual calls it out as a defined mode, "low-resolution graphics," but asserts that it is "not supported in ROM" and gives very little information on how to implement it. They state that it uses 40x25 textmode and not much else.
I've read about this on a number of websites, almost all of which do not quite fit the description in the 160x100 section near the end of this article, or conflict with IBM's documentation. Several describe using 80x25 mode and tweaking control registers, which I don't see in IBM's manual.
I've been all over google books and internet archive's scanned library and I cannot find any direct explanation. I find mentions in magazine articles and books which universally refer to it the same way - as some distant, notional concept that IBM didn't document and which nobody knows anything about. This technique was supposedly used in games, so it must have been learned somewhere, but for the life of me I can't find it.
If this can't be resolved soon, I believe the 160x100 section under the mode list will need to be replaced with text explaining that IBM mentions but does not explain how to use this mode, and *nothing else*, because we don't actually know what IBM intended and Wikipedia's guidelines don't permit us to draw inferences.
The section explaining how to use it further down can be sourced from one of the websites that explains how to do it, but should have text added to the effect that "it is not known if this is the same as the IBM technique." I think this is a clarification, not a conclusion, and should be acceptable. Gravislizard ( talk) 21:34, 15 August 2020 (UTC)
The article states several times that the pixel aspect ratio is 1:1.2 (5/6). This seems to be based on the assumption that the 320x200 area should exactly fill the 4:3 area of the screen (320x200 stretched to 320x240 meaning 200/240=5/6). But is that really the correct derivation?
When going by the 7.16 MHz dot clock in 320x200 mode, as described here, the CGA pixel aspect ratio becomes 1:1.1666... (6/7). Note that the Pixel aspect ratio article goes by dot clock, a.k.a. sampling rate, as well. This would mean that the pixels are a little less tall than what is obtained from the above derivation. How can that difference be explained? Because the monitor's 4:3 area will not just be filled with the 320x200 area, but with the 320x200 area plus the border, and the border thickness is not the same at all edges.
At default register values in 320x200 modes (->Note 1), the horizontal resolution with border will be 376 pixels (->Note 2), and the vertical resolution with border will be 246 pixels (->Note 3), yielding 246/(376*3/4)=~1:1.146, or 41/47. However, we have to account for the fact that the 246 pixels of the CGA's vertical resolution with border are merely the result of the MC6845's Vertical Sync Height being fixed at 16 lines (see 6845 datasheet), and so exceed the actual 4:3 area in the vertical direction. If we force the vertical resolution to analog non-interlaced NTSC's actual value of 242, we get 242/(376*3/4)=~1:1.165, very close to what the pixel clock approach yielded.
Therefore, I question the specified 1:1.2 pixel aspect ratio.
Notes:
-- NewRisingSun ( talk) 12:02, 24 October 2020 (UTC)
Color Graphics Adapter is a former featured article. Please see the links under Article milestones below for its original nomination page (for older articles, check the nomination archive) and why it was removed. | |||||||||||||
| |||||||||||||
Current status: Former featured article |
This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
The 8088 mph demo showed how to do high colour modes on CGA composite going well beyond the previous colour ranges.
http://www.reenigne.org/blog/1k-colours-on-cga-how-its-done/ http://8088mph.blogspot.co.uk/2015/04/cga-in-1024-colors-new-mode-illustrated.html
so these probably want incorporating into the tricks and tweaks
Alan Cox ( talk) 09:44, 21 April 2015 (UTC)
How does the 160x100 fit into 16K? Each character occupies two bytes of RAM -- one for the character itself, and one for the attribute. Thus, that's 160×100×2 = 32000 bytes. I buy that machines that use the MC6845 with 32K of RAM can display this mode, but an original 16K machine shouldn't be able to properly—the bottom half of the screen should show the same as the top half. I took a peek inside the
MESS code, and it appears they just put 32K on all CGA variants. (ref: "offs=(offs+2)&0x3fff
" in the text renderers) --
Mr z 23:21, 20 October 2007 (UTC)
Hi does anyone know about the signals applied through the pin's to give you the colour and what would they be?
Just a quick note that in one of the edits, I said "if you have a problem with the CGA color palette, contact me" but then realized later that I wasn't logged in. I am the one who put the final, correct CGA colors into the palette table -- if you want to change them you'd better have a good reason because I took them from the actual MC6845 specs and verified them with a TTL scan converter. Most people who think they know CGA colors seem to forget that when you toggle the brightness bit, ALL colors go bright, not just the ones that are supposed to go bright. Trixter 15:09, 20 Aug 2004 (UTC)
Goplat, I think you're confusing the 160x100 "tweaked text" pseude-graphics mode with the 160x200 composite mode. They were two totally different things:
The 160x100 tweaked text mode was achieved on standard RGB monitors. The 160x200 mode was ONLY available on the CGA card's composite video output (which you could hook up to your telly.) It had nothing to do with text mode. It was a seperate graphics mode in its own right -- only that few folks used it as most CGA boxen were hooked up to RGB monitors permanently.
As regards your video RAM size objection:
Fair enough?
Ropers 22:16, 20 Aug 2004 (UTC)
I don't know what mode it was, but I know for a fact that Bards Tale ]I[ became 16 color when I discovered that I could plug my TV into my computer.
I had been playing it with just the 4 colors that my Compaq 8088 (or was it 8086?) could produce.
When I discovered the 16 color trick, I played around in BASICA, and discovered that 2 pixels side-by-side were being interpreted as just one color on TV, with an aggregate of the color taken.
So I don't know if it was a different mode or not, or if it was the same mode just being interpreted differently by the two displays, or what. =^_^=
It was quite a shock to see that Bards Tale III was suddenly pretty..!
I just went through the article again, trying to bring the writing up to FAC standard. I cut a lot of side issues out to try to keep the actual points clear. Also worked over 160x200 16-color severely - it was confusing before, but I think it gets the point across now (and I think I got the point now) - David Gerard 21:47, 24 Aug 2004 (UTC)
It might be worth mentioning a couple of extra points:
In my experience of my first PC I know of additional palettes for the CGA. Now I must disclaim this saying that I had an Amstrad PC1512, which may have been custom-fit to produce unusual features. That said, I saw the following:
I repeat, I don't know how much of this is peculiar to the Amstrad PC1512, or could be achieved on any CGA card through hacking. -- Shlomital 10:24, 2005 Jun 2 (UTC)
I've added a table for the tweaked 3rd palette in the "tweaks" section, but my HTML skills aren't what they used to be and I can't figure out why it is too wide. Can someone fix the table for me? Thanks in advance! Trixter 17:20, 4 January 2006 (UTC)
This claim seems to be nonsense. The MC6845 produced only the address of the current pixel, it was up to other chips to read that address and actually display the color(s) stored there. If anybody can explain how those hex values were derived, please do so. -- 84.58.33.21 14:23, 29 July 2005 (UTC)
Well, well, this makes it the fourth version of the CGA colour palette values I've seen. Earliest, the numbers were (hex) 00, 54, B0, FE. Then, it was 00, 54, A8, FC. Later, on a previous version of this article, they were 00, 54, A8, FE. And now it's 00, 55, AA, FF, which I first saw as the "Linux console" colour palette for GNOME Terminal. I still don't know which one is correct (I root for 00, 54, A8, FC, if only because screenshots from the DOS window on Windows 9x, as well as from DOSBox, give out those colours), and I don't know even how to find the answer out, but please, if anyone does, bring it here, with evidence that it's the correct one, because all that juggling doesn't make for a reliable source. -- Shlomital 17:14, 27 February 2006 (UTC)
The original CGA from IBM was actually called "Color/Graphics Monitor Adapter" (C/GMA) (see this auction for pictures: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=8712503810), and the BASICA graphics demos on the DOS 1.x system disks call it that as well. I don't know when exactly the shortened name "CGA" came up (maybe when clones were produced?), but this original name should probably be incorporated in the main article. NewRisingSun 21:12, 16 December 2005 (UTC)
It was recently discovered [2] that IBM's original CGA monitor (IBM 5153 Color Display) displays color 6 differently than most compatibles (closer to what you'd expect if you strictly applied the RGBI color model). This should definitely be reflected in the article (as quite a number of games depend on it!); feel free to change my markup to something prettier... :) NewRisingSun 19:50, 17 January 2006 (UTC)
I think it needs to be made clear that the font used in graphics modes comes from a completely different source than the font used in text modes - hence my use of "separate". The text-mode fonts are in the character ROM on the card itself; this ROM doesn't appear in the PC's address space, so the BIOS contains its own 128-character font that it uses in graphics modes. On an original IBM PC with an original IBM CGA, the two fonts are the same so the effect isn't noticeable; but putting an IBM CGA card in an Amstrad PC2086, which has a completely different BIOS font, soon shows the difference. This is also the reason why changing the font jumper on the card doesn't change the font used in graphics modes. HungryHorace 10:33, 3 February 2006 (UTC)
It would be great if some knowledgable person could add the pinout of the CGA video connector. A drawing of the physical connector can be taken from the EGA article. -- 84.130.16.237 16:38, 3 July 2006 (UTC)
I made some larger changes to the article, and in order to avoid any needless reverting, I temporarily put them under User:NewRisingSun/cga.
Please review the changes and discuss. The picture markup is probably suboptimal as well. I'm also a little bemused by the constant past tense of the article; while it is appropriate to describe when it "was" sold, the inner workings of the CGA are still the same. ;) -- NewRisingSun
I changed the rather vague "this could be changed" about the black and white in hi-res monochrome mode to this text:
By default the colors were black and white, but the foreground color (white) could be changed to any other color of the CGA palette. This could be done at runtime without refreshing the screen.
I know for certain that this is possible, there is a game [4] that allowed the player to change the foreground color with a keystroke. What I don't know is whether it was possible to change the background color too (as could be done in lo-res). I don't think so, since I've never seen it done (though the background color would often display incorrrectly on a VGA display).
Another thing that bugs me is the following sentence in the paragraph about text mode:
This mode allowed each character a foreground and a background color, both of which could be freely chosen from the entire CGA palette (see table)—e.g. red on yellow text for one character, white on black for the next and cyan on gray for yet another.
Is this really true? As far as I remember, you can't set the background to a bright color in VGA text mode. If you do, the character will blink instead. Somehow it seems unlikely to me that this is a feature that was introduced later, and I'd expect the CGA to behave the same way. -- 213.47.127.75 20:17, 12 March 2007 (UTC)
How did the CGA compare on a techincal level to other graphics adapters, computers, consoles, etc. sold in its time (1981 - 1987)? Shinobu 18:08, 2 September 2007 (UTC)
I feel that the first two images, Image:Arachne CGA Mode.svg and Image:Cosmos bipinnatus0 CGA.png are very bad choices. They were both artificially created much later than the CGA era (and apparently with non-CGA hardware) and they are not representative of the actual use to which the Color Graphics Adapter was put in its time. One is an image of a browser that didn't exist in the CGA era and the other is a down-conversion from a better image. They're both nice enough pictures alright, but they don't inform, they mislead, because they're not depicting the past, but a latter-day reimagination of the past. The flower picture is also misleading because of the way ImageMagick (part of the Wikipedia server software) generates its thumbnails -- ImageMagick makes that picture thumbnail look much better than the exact picture would or could ever have looked on a CGA monitor. I suggest that these images be replaced by more representative pictures. Moving up the Alley Cat image later on in the article would be an excellent choice. That game was well-known and widespread during the CGA era. 86.56.48.12 20:26, 11 September 2007 (UTC)
I have put the image back in.
Removed FS dithered image because it is misrepresentative of CGA. CGA had many different palettes, and the dithering in the image further confuses the adapters abilities.
Regarding the comments posted above in this section:
Shinobu 01:41, 10 November 2007 (UTC)
Why are the images stretched like they are? It looks awful. SharkD ( talk) 03:05, 23 March 2009 (UTC)
...And a reason for not using this image that seems to have been missed by everyone: Doesn't the "C" in "CGA" stand for "color"? This why put a screen capture of black and white graphics at the top of the article?-- Drvanthorp ( talk) 21:31, 18 June 2011 (UTC)
OK. Some anonymous user just reverted the Fractint image back to the Arachne image with the non-CGA aspect ratios. If you want to use Arachne, then please use the one stretched to 640x480. CGA does not use a 1:1 pixel-aspect ratio, it is 1:2.4. Any CGA screen shot that isn't scaled to this aspect, by definition, is not presenting what CGA actually looks like. Shamino ( talk) 14:14, 9 August 2014 (UTC)
Done, an image with a more correct ratio is there. 4throck ( talk) 18:09, 11 August 2014 (UTC)
I emailed the author at http://www.digger.org/index.html and asked permission to use the Digger animated graphic seen on their webpage: http://www.digger.org/animate.gif
It is a perfect example of CGA in action, using a popular game from the period.
Kreline ( talk) 06:12, 11 February 2008 (UTC)
I went ahead and added it. If the animation is found to be annoying, it would be easy enough to edit the image to preserve only the first frame. -- Kreline ( talk) 04:09, 21 September 2008 (UTC)
The story of CGA is not complete without including a mention of this game.
http://www.mobygames.com/featured_article/feature,10/section,40/
http://www.mobygames.com/featured_article/feature,10/section,41/
http://www.mobygames.com/game/dos/icon-quest-for-the-ring/reviews/reviewerId,67846/
This game took the "tweaked text mode" technique to a new height. It used many other ASCII characters that were available, not just the "left block" and "right block" characters. Using drawing techniques of ASCII art, an effective resolution of 320x200 was created.
The 320 comes from 40 columns of text characters, at 8 pixels per character. 80-column mode was not used, because it was too slow, and because of the well-known "snow" bug of CGA's 80-column mode.
The 200 comes from 100 rows of text characters, using only the top 2 pixels of each character, just as in 160x200 mode.
The graphics have a distinctive look, as the available shapes were limited to what happened to be in the top 2 rows of pixels for each of the 256 text characters in the CGA's ROM. For example, the top of the "2" character produced a distinctive shape that looked like a musical slur, useful for drawing graphics that looked like waves in water.
Since this "320x200" mode was a text mode, it could use all 16 colors. This gave the graphics an appearance that could, at first glance, equal the 16-color 320x200 resolution of the EGA.
Perhaps the best example of this can be seen in the title screen of the ICON game: http://www.mobygames.com/game/dos/icon-quest-for-the-ring/screenshots/gameShotId,695/
Kreline ( talk) 06:12, 11 February 2008 (UTC)
Thanks for the feedback. I changed the phrase of "160x200 technique" simply to read "tweaked text mode", to avoid this confusion. The reader can read the rest of the article if they're interested in learning more about the resolutions of the various tweaked text modes.
FYI, the game did in fact achieve a vertical resolution of 200, by using the top 2 pixels of each of 100 rows of text characters. The major drawback was that not all the pixels were individually addressable. This gave ICON its distinctive appearance, as the programmers were limited to shapes found in the top two rows of each of the text characters in the BIOS of the CGA.
-- Kreline ( talk) 22:03, 11 August 2008 (UTC)
This is a forum thread, but maybe this info, particularly the info at post number 4 and 5, could be incorporated into the article? 86.56.122.190 ( talk) 08:42, 22 June 2008 (UTC)
In the RGBI section, is the formula to convert to RGB floating point values supposed to be in C? If then, shoudn't it read something like:
red = 2.0/3.0*(colorNumber & 4? 1:0) + 1.0/3.0*(colorNumber & 8? 1:0); green = 2.0/3.0*(colorNumber & 2? 1:0) + 1.0/3.0*(colorNumber & 8? 1:0); blue = 2.0/3.0*(colorNumber & 1? 1:0) + 1.0/3.0*(colorNumber & 8? 1:0);
Of course it is understandable the way it is, but I think it's a little bit better if it can be correctly executed. Samuel Lowry ( talk) 17:08, 6 November 2008 (UTC)
A. Video memory: The Toshiba 2016 chips are 2kB each and thus there are only 4kB on the board. The other chips are logic only. 4kB are not enough for a Hercules card so this should be a MDA clone (80x25x2 = 4000).
B. Clock: There is a 16MHz crystal on the board. CGA uses the 14.3xx MHz provided by the ISA bus as pixel clock and thus needs none of its own. MDA/Hercules adapters use 16MHz crystals. —Preceding unsigned comment added by 84.149.168.172 ( talk) 18:09, 2 July 2009 (UTC)
Maybe this information (in the yellow box) should go into the article? 31.16.112.242 ( talk) 22:20, 19 June 2011 (UTC)
Did IBM-made CGA cards sold in Europe output PAL? Or NTSC? Or neither? Please add. -- 78.53.146.224 ( talk) 11:45, 14 May 2012 (UTC)
Each byte in memory is represented on screen with pixels from smaller to higher.
I remember, back from my college days in 1988, that the Micro Plato software we used (an MS-DOS port of PLATO running courseware from floppy disk) generated a monochrome graphics mode with more than 200 lines on a standard CGA adapter. Some of our monitors could not display this resolution at all. Those that could were either NEC Multisync displays or needed us to twiddle the hold knobs in order to create a stable image. We typically also needed to adjust the size knobs to make the image wider and shorter in order to fit on-screen.
Is anyone familiar with this software and what it was actually doing to generate this unique graphics mode? Are there any CGA wizards who might have a good theory? Shamino ( talk) 17:39, 10 February 2014 (UTC)
It would seem that when arcade hardware buffs use the term "CGA", what they mean is 15KHz analog RGB, not digital IRGB (which is what CGA really is); needless to say, the two types of signal are not compatible. This usage has become widespread enough on the web to mislead and confuse (just run a web search for "CGA monitor" or "CGA converter" to see what I mean). I wonder if it's just plain ignorance or perhaps there is some sort of reasoning behind this.
At any rate, due to the popularity of this wrong usage of the term, perhaps a short clarification should be appended to the article, to alert readers to the distinction. 79.179.67.98 ( talk) 23:52, 28 April 2014 (UTC)
I reverted the edit that sorted the 16-color palette; all other palettes on the page are unsorted, and viewing the 16-color palette unsorted illustrates the relationship the intensity pin had on color generation. Additionally, most pages that describe 8-bit color modes also show their modes unsorted. Trixter ( talk) 17:04, 30 June 2014 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Color Graphics Adapter. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
{{
dead link}}
tag to
http://www.lauppert.ws/screen1/cga/When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 16:24, 4 September 2017 (UTC)
Some of the example images provided in this page are of copyrighted material, and have been automatically shrunken by the fair use image resizer bots. This is fair enough, but the reason the images are there in the first place is to get an idea of how the palettes listed on this page are used in creative ways. For this, you really want images to be in native resolution, so the bots are spoiling them.
The best way to fix this would be to replace the game images with images of free alternatives if possible, or simply removing them if not. -- 2602:30A:2C3A:6810:20F:60FF:FE0C:539D ( talk) 08:39, 27 June 2018 (UTC)
I guess I don't understand the fascination with this hardware, esp. the recent interest in the composite output which attains a wider color palette as a byproduct of NTSC artifacting and not as an inherent feature of the hardware? Apple was doing that years before the PC.
Video game consoles of the time were more aesthetically competent than IBM's overpriced hardware.
IBM's green monochrome display was a thing a of beauty though, and you actually could do "pseudo" graphics with that if you were willing to manipulate the character set and perform other trickery.
JMHO. 108.200.234.93 ( talk) 06:45, 5 January 2020 (UTC)
I have recently rewritten much of this page, and while a lot of it is valid pending sourcing (I have magazine articles and literature refs, they're just very tedious to add so I haven't done all of them yet) the situation with 160x100 is concerning.
While 160x100 is often referred to as "undocumented" or other such things on other sites, and has been referred to that way here, this isn't quite true true. It is documented, just very poorly. IBM's original technical manual calls it out as a defined mode, "low-resolution graphics," but asserts that it is "not supported in ROM" and gives very little information on how to implement it. They state that it uses 40x25 textmode and not much else.
I've read about this on a number of websites, almost all of which do not quite fit the description in the 160x100 section near the end of this article, or conflict with IBM's documentation. Several describe using 80x25 mode and tweaking control registers, which I don't see in IBM's manual.
I've been all over google books and internet archive's scanned library and I cannot find any direct explanation. I find mentions in magazine articles and books which universally refer to it the same way - as some distant, notional concept that IBM didn't document and which nobody knows anything about. This technique was supposedly used in games, so it must have been learned somewhere, but for the life of me I can't find it.
If this can't be resolved soon, I believe the 160x100 section under the mode list will need to be replaced with text explaining that IBM mentions but does not explain how to use this mode, and *nothing else*, because we don't actually know what IBM intended and Wikipedia's guidelines don't permit us to draw inferences.
The section explaining how to use it further down can be sourced from one of the websites that explains how to do it, but should have text added to the effect that "it is not known if this is the same as the IBM technique." I think this is a clarification, not a conclusion, and should be acceptable. Gravislizard ( talk) 21:34, 15 August 2020 (UTC)
The article states several times that the pixel aspect ratio is 1:1.2 (5/6). This seems to be based on the assumption that the 320x200 area should exactly fill the 4:3 area of the screen (320x200 stretched to 320x240 meaning 200/240=5/6). But is that really the correct derivation?
When going by the 7.16 MHz dot clock in 320x200 mode, as described here, the CGA pixel aspect ratio becomes 1:1.1666... (6/7). Note that the Pixel aspect ratio article goes by dot clock, a.k.a. sampling rate, as well. This would mean that the pixels are a little less tall than what is obtained from the above derivation. How can that difference be explained? Because the monitor's 4:3 area will not just be filled with the 320x200 area, but with the 320x200 area plus the border, and the border thickness is not the same at all edges.
At default register values in 320x200 modes (->Note 1), the horizontal resolution with border will be 376 pixels (->Note 2), and the vertical resolution with border will be 246 pixels (->Note 3), yielding 246/(376*3/4)=~1:1.146, or 41/47. However, we have to account for the fact that the 246 pixels of the CGA's vertical resolution with border are merely the result of the MC6845's Vertical Sync Height being fixed at 16 lines (see 6845 datasheet), and so exceed the actual 4:3 area in the vertical direction. If we force the vertical resolution to analog non-interlaced NTSC's actual value of 242, we get 242/(376*3/4)=~1:1.165, very close to what the pixel clock approach yielded.
Therefore, I question the specified 1:1.2 pixel aspect ratio.
Notes:
-- NewRisingSun ( talk) 12:02, 24 October 2020 (UTC)