Talk:Color Graphics Adapter

message: 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)
replies: text: I took the liberty of adding this information, since I found it important. I hope I did it in the appropriate fashion.85.73.130.104 (talk) 02:26, 25 March 2016 (UTC)
thread_title: High Colour Modes

message: 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 <I>all</I> CGA variants.  (ref: "<CODE>offs=(offs+2)&0x3fff</CODE>" in the text renderers)  --Mr z 23:21, 20 October 2007 (UTC)
replies: text: It's 80×100×2 = 16000 bytes, because each character represents two pixels. Calvero2 13:59, 21 October 2007 (UTC)
replies: text: *d'oh*  I knew I must be missing something obvious.  *chuckle*  Thanks.  --192.94.94.106 20:31, 24 October 2007 (UTC)
thread_title: 160x100 tweaked text mode doesn't fit?

message: 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)
replies: text: Got the reference in there? That would be the handiest thing - David Gerard 15:32, 20 Aug 2004 (UTC)
replies: text: Huh? In graphics mode, yes (IIRC), but in text mode? I seem to recall that there were the full palette of 16 colours available in text mode. Also, all the sources suggest that. Plus the screenshots from the ICONDEMO.exe  are 16 colour. In composite mode there also are 16 colours. Surely you meant that only with reference to the 320x200 4 colour mode? Ropers 20:21, 20 Aug 2004 (UTC)
replies: text: All I'm saying is that people tend to "make up" the 16-color CGA text mode palette with things that seem to make sense, like "FF0000" for "bright red" when in fact that simply wasn't the case.  When you enable the "I" bit, ALL components get intensified.  Black becomes gray, etc.  So "bright red" is really "FF5454".  The actual number of "FE" instead of "FF" is me being picky based on the specs, but those are the actual numbers.  To further clarify, the graphics mode palette colors are identical to the text mode colors that they are based off of.  For example, the "red" in the "red/green/yellow" palette corresponds to the CGA text color "red", etc.  It is not a "different" red.  Now, composite color mode used completely different colors than CGA text/graphics mode, and one of these days I will hook up my old PC to my broadcast equipment and capture the definitive CGA 16-color composite output color chart.  But today is not one of those days :-) Trixter 04:42, 21 Aug 2004 (UTC)
replies: text: If the hex values presently used in the table are precisely correct ... would it be worth listing them visibly in the table itself? - David Gerard 21:58, 24 Aug 2004 (UTC)

text: Never mind, I've just done so - noting they're from the MC6845 spec :-) What's the precise name of the spec? It should go in the 'References' section - David Gerard 22:35, 24 Aug 2004 (UTC)
thread_title:  "Contact Me" is Trixter 

message: 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:
* 160x200 equals 32,000 (that's how many pixels we have.
* 16 colours require 4 bits (2x2x2x2=16).
* 4 times 32,000 equals 128,000. That's how many bits we need to encode 32,000 pixels at 16 colours.
* 128,000 bits equal 16,000 bytes (as 1 byte=8 bits, so 128,000 gets divided by 8).
* 1 KB equals 1,024 bytes.
* Thus, 16 KB equal 16,384 bytes.
* 16,000 bytes should thus fit into 16 KB with room to spare.
Fair enough?
Ropers 22:16, 20 Aug 2004 (UTC)
replies: text: You were right, I screwed it up. Sorry about that. Goplat 22:31, 20 Aug 2004 (UTC)
replies: text: And I (initially) screwed up as well, forgetting about the fact that 1KB = 1024b (that's now corrected, and it doesn't change my point). Thanks for the quick reply :) -- I even got an edit conflict while I was correcting my own screwup ;-) Ropers 22:38, 20 Aug 2004 (UTC)
replies: text: No corrections here, you've got it right.  But what's interesting to note, and what may be adding to the confusion, is that 320x200x4, 640x200x2, 160x200x16, and 160x100x16(tweaked text) ALL took up EXACTLY 16000 bytes... yet there is 16K available on the adapter, which means you actually have 16384 bytes to work with.  What to do with the extra 384 bytes?  Not too much, but I once came across a BASIC program that used them for temporary storage because the BASIC program itself was so big it filled all of the RAM available in a 64K PCjr ;-)  Trixter 04:47, 21 Aug 2004 (UTC)
thread_title: 160x200 composite mode did exist and was possible w/ 16 KB VRAM

message: It might be worth mentioning a couple of extra points:
* Original IBM PC motherboards (8088 processors) had a small trimmer capacitor on the 14.318318  quartz oscillator labelled "Color Adjust" - since the IBM CGA card derived its 3.58 MHZ NTSC color subcarrier frequency from the motherboard clock, which was distributed on the original XT expansion bus. All that to save a 39 cent crystal on the CGA card! 
* The CGA card had both an RGB connector and a composite video output.  The composite video could be connected to a household (NTSC,525-line 60 Hz) TV set, just like a home computer.  I did see this used in an industrial context when a PC with a CGA card was hooked up as a text display on a plant-wide closed circuit TV system - an ingenious way of recycling old hardware. 
* A common rookie PC user mistake of the early 1980's was trying to plug in a color monitor to a monochrome display adapter, or the reverse - they used the same DE-9 female connector. Legend had it that some monitors were destroyed by this, though I never managed to do it myself. 
* A CGA card and IBM monitor produced really terrible-looking text, even using an RGB monitor.  Since the 320*200 color mode was worthless for serious graphics, nearly all "business" PCs used either MDA or a Hercules card, both of which produced text that looked even nicer than that on a Kaypro 10. --Wtshymanski 21:11, 23 May 2005 (UTC)
replies: text: Trimmer: agreed, probably something to mention (but here or on the 5150 page?).  Composite: already mentioned in the article.  Hookup up monitors: not entirely sure where that would be approprite (btw, not possible to break either monitor on either card this way; the frequencies were different, but not exceedingly high which is what breaks monitors).  "Terrible" text:  That's quite subjective; I rather like the way text looks on my 5153 :-).  I've spend decades looking at 80-col on it and never thought it was terrible. --Trixter 21:05, 7 February 2006 (UTC)
thread_title:  CGA trivia 

message: 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:
* Graphics mode (640×400) with the CGA 16-colour RGBI palette. I know it had that one because GEMPaint wouldn't work without it (used for drawing colour graphics).
* 4-colour palette with #0000A8 (blue) instead of #000000 (black) in addition to magenta, cyan and light grey. Some games (like Alley Cat) would flash between this palette and the normal one for alerting the user.
* 4-colour palette with #A8A800 (yellow) instead of #A85400 (brown) in addition to black, red and green. I saw this at least on one game, Double Dragon, where I remember the game would switch between the normal palette (black, magenta, cyan, light grey) and what I called "Chinese colours".
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)
:Of these, the 640x200x16 mode is unique to the PC1512, and isn't available on normal CGA. The other two are entirely standard; you get the first one by selecting magenta/cyan/white and then setting the background to blue, and the second by selecting red/green/brown and turning on high intensity --HungryHorace 16:35, 4 Jun 2005 (UTC)
replies: text: Great! Thanks for educating me on that. I was wondering how much hacking went into the ol' PC1512. --Shlomital 13:15, 2005 Jun 11 (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)
replies: text: You added a red-cyan-white palette. What about the red-green-yellow palette mentioned by Shlomital? Another game I know to use this is Legacy of the Ancients. -- 145.254.132.115 14:57, 1 February 2006 (UTC)
replies: text: That's the same palette as the red-green-brown, just with the high-intensity bit turned on.  It's not a fundamentally different third palette. Trixter 21:11, 2 February 2006 (UTC)
thread_title:  Additional palettes 

message: 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)
replies: text: I agree. The MC6845's data sheet makes no mention of any color values at all --- the color values mentioned are just what you get with the RGBI color model (with the exception of color 6). Let's remove that table if nobody objects. NewRisingSun 21:12, 16 December 2005 (UTC)
replies: text: Please don't remove the table; the hex values were created by me based on research from how the TTL actually operates.  If you'd like to "fix" the rounding then please do so but do not change the basic color mix which is correct.  (For example, most people guess at the "brown" and "intensity" colors and always get them wrong.) Trixter 1:12, 23 December 2005 (UTC)
replies: text: You claim that these values are "adapted from the MC6845 specification", even though the MC6845 specification contains no such information. Now you say it's based on your research on the "TTL", even though the CGA doesn't use a TTL monitor (that one is used by the MDA/HGC card!)... I guess I'll just call the table "Full CGA 16-color palette" and correct the values. NewRisingSun 20:46, 21 December 2005 (UTC)
replies: text: Actually, both the CGA and MDA use TTL monitors; TTL in this context just specifies which voltage ranges on the pins mean "on" or "off". From the IBM PC tech ref, page 1-158, describing the IBM Color Display: "Horizontal drive: Positive-level, TTL-compatibility, at a frequency of 15.75 kHz." Identical wording is used on page 1-132 to describe the IBM Monochrome Display except that the frequency is 18.432 KHz. HungryHorace 22:45, 21 December 2005 (UTC)
replies: text: That would make the EGA's Enhanced Color Display (IBM 5154) a TTL monitor as well.... but if you say so. In any case, I'd still like to get a copy of that ominous "MC6845 specification" that supposedly lists the color values.... the 22-page data sheet from Motorola (plus 2 pages revised addendum) certainly has no such information. NewRisingSun 23:42, 21 December 2005 (UTC)
replies: text: If you want to remove "MC6845 Specification" then go ahead and do so.  I wrote that originally as a deterrent to people guessing at the colors, when you can clearly see that the interface is RGBI not just RGB.  But please don't alter the values beyond rounding them upward (ie. changing FE into FF) ... like I wrote earlier, most people think that "light red" is "#FF0000" which is blatantly incorrect because they don't take the "I" component into account.  The table has the correct color mix.  And yes, the 5154 is also a TTL monitor. Trixter 04:56, 22 December 2005 (UTC)

text: The RGBI color model translates the digital TTL bits to analogue voltage factors of 0, 1/3, 2/3, 3/3. On a digital scale from 0 to 255, that translates to 0, 55, AA, FF. Since the VGA's color registers accept only 6 bits, the scale is from 0 to only 63, which would be 0, 15, 2A, 3F. If you simply multiply these by four (or shift by two bits), which is what most programs do, you'll get 0, 54, A8, FC. In other words, the differences are merely rounding errors. NewRisingSun 20:10, 27 February 2006 (UTC)
replies: text: The original palette (the one mentioned in "adapted from MC6845 specification") was created by me, using the bit shift method, which is why the values were 54, A8, FC (truncation).  I have since re-evaluated that position and now stand by the 55, AA, FF (rounding) numbers because they more closely resemble what they are modeling (ie. full TTL white output = full RGB white output).  --Trixter 21:55, 27 February 2006 (UTC)
replies: text: First, thanks for the convincing explanation. So 54 and A8 and FC are the result of algorithmic upsampling from a lower bit-depth, while 55 and AA and FF are the result of intelligent upsampling according to the specification (the 0/3, 1/3, 2/3, 3/3 factors mentioned above). Second, I've now done one even better and prepared a 48-bit PNG image of the palette, with the values 0000, 5555, AAAA, FFFF. It's on my user page. --Shlomital 18:03, 28 February 2006 (UTC)
thread_title:  "hex values adapted from MC6845 specification" ?? 

message: 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)
thread_title:  Original name of the card 

message: 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)
replies: text: I always got the first 128 characters from F000:FA6E (BIOS of course), and the second 128 from where interrupt 1F pointed to (which on my machine eventually leads to C000:2D06).  The second location is clearly the CGA, so I'm confused... Trixter 00:22, 6 February 2006 (UTC)
replies: text: C000:2D06 is not the CGA, but your EGA/VGA. The CGA doesn't come with its own BIOS at C000 ;)NewRisingSun 00:28, 6 February 2006 (UTC)
replies: text: You are correct, I just (5 minutes ago, damn you're quick) ran it on my EGA/VGA.  Let me run the same program on my 5150... --Trixter 00:31, 6 February 2006 (UTC)

text: Well, that was educational.  F000:FA6E is indeed the first 128 chars, and Int 1F points to F000:0000 which (on the 5150/CGA) contains garbage.  So I stand corrected, and I'll alter the text in the article to reflect HungryHorace's concerns.--Trixter 02:33, 6 February 2006 (UTC)
thread_title: Fonts and the BIOS

message: 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)
thread_title:  Pinout? 

message: I made some larger changes to the article, and in order to avoid any needless reverting, I temporarily put them under User:NewRisingSun/cga.
* Rewrote and expanded the "composite" section. I also plan to write a dedicated "Artifact color" article, discussing the matter from a more general technical point of view; after all, the technique is basically the same from CGA to Apple II to Atari to Coco.
* Moved the second and third paragraphs to the end of the article, since the CGA's market penetration goes better along with the mentioning of its competitors.
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
:Considering I'm still developing for it as a hobby, I agree :-)
:I have no suggestions whatsoever -- as always, you did a fine, thorough job and I am especially looking forward to the composite artifacting article.  One of these days I'll re-convert 8088 Corruption to take advantage of composite artifacting. --Trixter 21:49, 2 September 2006 (UTC)
replies: text: Ok. I have copied over the changes into the article. With regards to my claim "making for a total gamut of well over a hundred colors", I need to calculate how many these are exactly. It should be quite a few though, mostly because of the sixteen different possible settings of color 0. NewRisingSun 23:41, 2 September 2006 (UTC)
replies: text: When writing how many colors are available, see if you can produce two figures:  One for the total number of colors available using all palettes, and another number for how many are distinctly visible (and/or addressable?) on a single screen.  I'm assuming the latter will be 16, but I'm hoping it's otherwise...--Trixter 21:41, 3 September 2006 (UTC)
thread_title:  Changes 

message: 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  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).
:Correct, on CGA only the foreground color can be changed.  It's the same port write for all three modes, actually:  Writing to color select register changes the foreground color in 640x200; changes the background (ie. color index 0) in 320x200; and changes the overscan/border color in text modes. --Trixter 18:05, 15 March 2007 (UTC)
replies: text: Thanks for clearing that up. Maybe you could put this into the article? -- 213.47.127.75 16:19, 16 March 2007 (UTC)
replies: text: It's already mentioned in the section "Further RGB graphics modes and tweaks".  --Trixter 20:58, 16 March 2007 (UTC)

text: You can turn of the blinking, both on CGA cards and on VGA cards, but you have to write to a different port. Calvero2 20:17, 13 March 2007 (UTC)
replies: text: Was this a documented or an undocumented feature? -- 213.47.127.75 16:19, 16 March 2007 (UTC)
replies: text: Fully documented, as far back as the CGA tech ref :-)  --Trixter 20:58, 16 March 2007 (UTC)
thread_title: Two details

message: 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)
replies: text: Agreed! That would definitely be a better top-of-page image than the Arachne screenshot (an animation on top of the page might be a tad annoying, but the preview could just be a single frame, while the animation could be viewable after clicking it). 77.127.164.59 (talk) 15:02, 16 May 2008 (UTC)
thread_title:  Digger 

message: 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)
replies: text: You wrote "This game took the 160x200 technique to a new height." You're confusing the 160x100 "tweaked" text mode with the 160x200 composite mode. ICON used the tweaked text mode, but instead of tweaking the 80x25 text mode (like e.g. Moon Bugs did), it tweaked the 40x25 text mode, but achieved a higher apparent resolution than would be possible with ordinary tweaking (w/ the ASCII 221/222 half-block characters) by using ASCII art. 86.56.122.190 (talk) 21:26, 14 June 2008 (UTC)
replies: text:  And, interestingly, it's doing some things I came to this page to ask whether anyone ever attempted - IE, something akin to 160x100 (or 80x200...) mode but taking advantage of a limited number of other already sort-of-graphic characters in the 437 codepage. IE the 25/50/75% shade blocks, the line/window-drawing characters, etc. Thus you might have otherwise slightly chunky, blockmode-like graphics, but with a number of readymade dithers to show a greater number of apparent colours (maybe as much as 128 just with 50%, 256+ with 25/75%?), and a few thinner lines and patters that can be thrown in here and there. Clever :)  — Preceding unsigned comment added by 193.63.174.211 (talk) 13:48, 6 June 2014 (UTC)
thread_title:  ICON: Quest For The Ring 

message: 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)
thread_title:  Monitor 

message: 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)
thread_title:  Ambiguous/misleading formula for converting to RGB? 

message: 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)
replies: text: Well spotted. This card also misses the composite connector. —Ruud 18:03, 11 August 2009 (UTC)
thread_title:  The picture "KL CGA Unknown.jpg" is not a CGA card 

message: Maybe this information (in the yellow box) should go into the article? 31.16.112.242 (talk) 22:20, 19 June 2011 (UTC)
thread_title:  Blinking needed to be switched off for "tweaked text" 160x100 16 colour graphics mode 

message: 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)
replies: text: There was no such thing as a CGA with PAL output, even in the European market.  As far as I know CGA cards sold in PAL countries were identical to those sold elsewhere - you just couldn't take advantage of the composite output, so in effect you were limited to RGB. -- 82.80.137.100 (talk) 13:36, 4 June 2012 (UTC)
thread_title:  PAL in Europe? Or just RGB? Or NTSC? 

message: 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)
replies: text: It's probably because yer typical CGA monitor was a multistandard (although not multifrequency) device and had TTL, analogue RGB and composite inputs. Certainly any I've seen which don't use a captive flylead have these separate sockets, although the shape and pin count of the RGB ones does vary. So if they go buy a CGA monitor and don't get a less common digital-only model, they can plug it into an analogue or digital board, so long as it outputs at approx 15.7kHz line frequency. 193.63.174.211 (talk) 13:30, 6 June 2014 (UTC)
thread_title:  Misuse in arcade game terminology 

message: 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)
thread_title: Palette sort order

message: 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:
*Added archive https://web.archive.org/web/20060618101547/http://members.chello.at/theodor.lauppert/games/cga.htm to http://members.chello.at/theodor.lauppert/games/cga.htm
*Added  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.
Cheers.—InternetArchiveBot (Report bug) 16:24, 4 September 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  Example images getting shrunken by bots 

message: 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)
thread_title:  CGA 

message: 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)
thread_title:  160x100 mode 

message: 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:
#IBM Personal Computer Hardware Reference Library: IBM Color/Graphics Monitor Adapter (p/n 6361509), pg. 17
#Horizontal Total Register +1 minus Horizontal Sync Width Register times eight =($38+1 -$0A)*8 =376
#Vertical Total Register +1 times the Maximum Scan Line Address Register +1 plus the Vertical Total Adjust Register minus the MC6845's fixed Vertical Sync Height =($1F +1)*($07 +1) +$06 -16=246 
-- NewRisingSun (talk) 12:02, 24 October 2020 (UTC)
thread_title:  Pixel Aspect Ratio