Talk:List of 8-bit computer hardware graphics

message: At http://atariage.com/forums/topic/227441-aquarius-information-about-correct-ypbpr-colours-from-the-palette/ we can have accurate information about the colour palette used on Mattel Aquarius, but i have no idea how to convert it to YPbPr colourspace format - if anyone can help, please do!  — Preceding unsigned comment added by Nitrofurano (talk • contribs) 11:33, 14 July 2014 (UTC)
replies: text: Please would an interested editor assess the table added at User:Nitrofurano/List of 8-bit computer hardware palettes, incorporate it if useful, blank the remaining content on the user page as WP:FAKEARTICLE, and leave a note here when done? – Fayenatic London 20:41, 1 April 2024 (UTC)
thread_title: Mattel Aquarius

message: The Sam Coupé from MGT (Miles Gordon Technology) was an 8 bit and should probably be listed.
Any takers ?  —Preceding unsigned comment added by Sircompo (talk • contribs) 12:06, 28 February 2008 (UTC)
replies: text: In advance, any 8-bit related machine with a propietary color palette fits well here; only B&W (as ZX81) machines not. The actual list is far from being complete, and some other representative cases (as the Atari 400/800 XL) are welcome. In fact, machines not listed here are due to lack of info enough to write an enciclopedic section of the subject. If you wish to see the Sam Coupé or any other interesting machine, please provide technical info (refs, URLs, etc.), or edit the page yourself. Yours. Ricardo Cancho Niemietz (talk) 14:45, 28 February 2008 (UTC)
replies: text:  Ricardo, i added some information there about Sam-Coupé, and also about BBC-Micro and Thomson  —Preceding unsigned comment added by Nitrofurano (talk • contribs) 15:06, 30 November 2010 (UTC)
thread_title: Sam Coupé

message: "Many of early video chips output composite video YPbPr colors, sometimes inaccurately referred as YUV colors."
This is utter and complete nonsense. There is no such thing as "composite YPbPr". Composite video is a quadrature-modulated YIQ (NTSC) or YUV (PAL) signal, nothing else. YPbPr is a component format and was introduced with SMPTE 240M in the mid/late 1980s, after the Apple II and C64. No old video game console uses YPbPr, internally or otherwise. 
"YUV is the color specification used for PAL TV systems, not for composite video;"
Nonsense. PAL is broadcast as RF-modulated composite video, as is NTSC. The author of that line seems to be in complete confusion about what "composite video" is.
"Also, when seen on TV devices through a RF modulator, the perception of these colors may be not corresponding with the original YPbPr ones (most noticiable with NTSC TV color system, due to its YIQ color space plane is not one-to-one compatible with YPbPr and YUV)."
An RF modulator just modulates a baseband composite signal onto a radio frequency carrier --- the same television receiver will produce the same color no matter if fed a baseband composite NTSC or RF-modulated composite NTSC signal.
I guess I'll have to correct this once I have the time. NewRisingSun (talk) 17:47, 8 May 2008 (UTC)
replies: text: I agree, it's YUV/YIQ. YPbPr is only one step in the color conversion line from YUV/YIQ to RGB. Most video IC's with a composite output do not even have RGB or YPbPr as source, because they simply phase shift the color carrier of the composite signal to produce the different chroma values. Fröhn (talk) 21:00, 8 May 2008 (UTC)
replies: text: In the article, I'm talking about "color specifications", not "electrical" nor "signal" specifications. That means: YUV not equal to YPbPr not equal to YIQ. Check the articles for the conversion formulae. I already know that PAL/NTSC/SECAM are RF broadcasted, but the article isn't focused on TV. Original models of early computers (as Apple II) couldn't be plugged directly to TV sets, but to manufacturer's ad hoc monitors. That is, they didn't ship built-in RF modulators. Third party manufacturers provide cheap RF modulators, very susceptible to noise, which slighty changed colors, more or less. That kind of facts are what we're talking about. Maybe edition is needed to avoid confussion. Yours. --82.130.195.150 (talk) 14:22, 24 September 2008 (UTC)
replies: text: I don't see how you justify calling them "YPbPr composite colors." They're not generated that way, and how they're decoded in the monitor is irrelevant. They're generated using phase shifts in YIQ or YUV space, or in simpler cases, just blasting raw bits out the video line. If you want to specify them in YPbPr, that's fine, but calling them YPbPr colors is bogus and deceptive. 24.4.198.162 (talk) 04:17, 18 March 2009 (UTC)
thread_title: YPbPr in 8-bit computers!?

message: The Atari 8 bit computers (400, 800, 600XL, 800XL, 1200XL, 800XE, 65XE, 130XE ...) use a composite output and have a palette of 128 colors (8 lumas * 16 chromas). Following bitmap modes exist:
CTIA/GTIA video chip:
320x192 in 2 colors (monochrome). The chroma for both colors is the same but can be any of the 16 chromas, lumas can be selected without restrictions.
160x192 in 4 colors. Those 4 colors can be chosen from the 128 color palette without restrictions.
GTIA only:
80x192, 16 lumas/1 chroma (monochrome). Unlike the normal 128 color palette this mode allows 16 lumas, but all 16 luma levels are forced to have the same chroma.
80x192, 1 luma/16 chromas. All chromas can be used, but all of them share the same luminance. Pretty useless mode :)
80x192, 9 colors. The 9 colors can be chosen from the 128 color palette without restrictions.
If you wish you can make all modes 200 pixels high, on Atari it's simply a matter of adding more entries to the display list which builds up the screen. It's just that on Atari for some reason 40x24 characters had become standard althought it could easily do 40x25 too.
Also, there is another mode which can be created by a special display list which alternates the 16 luma and the 16 chroma mode every rasterline. Because PAL decoding mixes chroma 50:50 from one rasterline to the other, a 256 color mode with 80x96 pixels resolution can be created without CPU intervention. The downsides of this mode is: Every 2nd rasterline has luminance 0 (almost black) which reduces brightness, and every other rasterline has chrominance 0 (greyscale) which reduces saturation.
Fröhn (talk) 9:38, 9 May 2008 (UTC)
thread_title: Atari 8 bit modes

message: Commodore 128, in VDC mode MOS_Technology_VDC, should be mentioned, either in a section on its onw or along the CGA discussion. Senbei64  —Preceding undated comment was added at 11:52, 20 August 2008 (UTC)
thread_title: Commodore 128

message: At some point, the "8-bit computer", "16-bit computer", etc. denotation should be ditched and something more accurate should be used for a division, like fixed palette vs. flexible palette.  That would eliminate any debate over which video subsystem belongs in which article.
One issue that illustrates this is "IBM AT" video subsystem being defined in the "16-bit" article.  An assumption is made that the AT shipped with EGA (it was optional) and also that EGA was not available for the original IBM PC (it was, after the launch of the AT).  A "fixed palette" vs. "flexible palette" division would eliminate this by properly documenting EGA functionality and not getting hung up on which system it could or could not be inserted into.
Also, a poster above is incorrect in stating that VGA was only available for microchannel systems.  IBM, and many others, released 8-bit VGA cards suitable for the original IBM PC.  So this is another example of where the system classification is simply a bad way to categorize things. --Trixter (talk) 17:51, 30 November 2009 (UTC)
thread_title: Article Classifications

message: Why is there no data for British-origin machines such as the ZX Spectrum or BBC Micro? Can anyone get data for these machines?  —Preceding unsigned comment added by 82.17.144.241 (talk) 16:19, 30 March 2010 (UTC)
thread_title:  No British machines! 

message: The TI 99/4a home computer should be mentioned alongside the MSX systems, since they used the same video chip.
Later MSX systems used upgraded chips, as mentioned in the article.  rhyre (talk) 01:37, 10 March 2011 (UTC)
thread_title:  TI 99/4a and TMS99x8 chips 

message: The screen-12 of the MSX2+ has 19268 colors. But the palette shown at the right side of the macaw image shows only 5075 colors (counted using GIMP Colors->Info->ColorCube Analysis). Is that right?  — Preceding unsigned comment added by 189.26.25.198 (talk) 23:56, 31 December 2012 (UTC)
thread_title: MSX2+ Screen12 (YJK) palette seems incomplete

message: Have a look at the black, cyan, magenta, and light grey image. Now have a look at the 16 colour image. Why is the perch light grey in one image but not in the other image? Also, why are the bright and dark versions of the palette using what seems to be the same image?  — Preceding unsigned comment added by CarlKenner (talk • contribs) 08:32, 20 October 2012 (UTC)
thread_title: CGA images don't match

message: Added that remark, because the article lacks references. I don't doubt the information, since it comes mostly for each computer's individual page, but it needs at least one reference by machine.
Another issue is the simulation of actual palette values in arbitrary color spaces.
How where those values calculated?
The original machines outputted RGB or YUV/YIQ, that was then converted into PAL or NTSC. That's the only thing to take into account.
Where do the YPbPr values come from? And why use them, since they have little real world value?
This is obvious by looking at the C64 entry, where the NTSC captures image show a very different result than the simulation.
An in the case of multiple monitors being used, shouldn't both outputs be shown (like RGB x NTSC composite) ?
4throck (talk) 07:54, 15 July 2014 (UTC)
thread_title: Multiple issues

message: I know there are conversion formulas you can find for YUV and YCbCr to RGB all over the net, but I have yet to find one for YPbPr to RGB. I believe it uses different weighting factors for the color channels, but I have yet to find any documentation on it. I was going to create a program in VB6 that uses the Commodore64 color palette, but I need to convert your YPbPr numbers (in the range of -1 to +1) to RGB numbers (in the range of 0 to 255). I do not know any proper conversion formula for YPbPr to RGB, and there none on the internet that I can find with a Google search. Can someone here on Wikipedia please post the proper formula on this page about 8-bit computer color palettes? Benhut1 (talk) 01:41, 4 September 2014 (UTC)
replies: text:  I don't get is why you are doing it. The original values for 8bit computers are either RGB, YIQ (NTSC) or YUV (PAL), and are related to memory bits. Those are the only values that matter. YPbPr is just a conversion to a modern standard. Don't know where those values came from, doesn't make much sense. So better convert back to RGB, that's what computers and emulators use. Look at the reference for the C64 section ( http://www.pepto.de/projects/colorvic/ ) You have the relation of bits to YUV values. So that's what should be on the color tables, not that YCbCr  nonsense. All else is original research. Non sourced values have no place here and I'll probably just remove them. We shoudn't be spreading false information. Added an original research warning to the article.  4throck (talk) 09:12, 4 September 2014 (UTC)
thread_title:  YPbPr to RGB conversion? 

message: is making odd grammatical errors, changing, for example
* For color palettes of 16-bit personal computers (all RGB based), see the List of 16-bit computer hardware palettes article.
to
* For color palettes of 16-bit personal computers, (all RGB based) see the List of 16-bit computer hardware palettes article.
Does anyone else agree with this change?  There are a total of three changes, most of which can be better (IMO) fixed by removing the parenthetical remark entirely. — Arthur Rubin  (talk) 14:17, 16 April 2015 (UTC)
thread_title:  Grammar 

message: As far as I can tell, the sentence referencing HighColor and TrueColor had been stable at
:For current RGB display systems for 32-bit and better PCs (Super VGA, etc.), see the 16-bit RGB for HighColor (thousands of colors) and 24-bit RGB for TrueColor (millions of colors) modes.
for some time.  I assume that's because, as noted in the respective articles, Apple called the modes "thousands of colors" and "millions of colors".
An editor (the same one as the one referenced in the preceding section) added counts (66 thousands of colors) and (17 millions of colors).
I added 216 and 224 instead of those counts, and the editor changed them to 2^16 and 2^24.  I would like a third opinion as to what should be in the article.  I tend to think the original version is best, without numbers.  However, summarizing the problems,
:* As for the "small" counts (65, 17)
:**The counts probably shouldn't be there at all, as those are Apple's names for the display modes.
:**The counts "66" and "17" are misleading, as they are rounded up. They probably should be "64" (using the computer-science definition of "thousands" as 1024) or "65" (representing the fact that at least 65,000 colors are available) and "16" (for either reasoning) respectively.
:* As for the exact number.
:**They probably shouldn't be there at all, but I find them preferable to the other numbers.
:**The editor mentioned above has the idiotic view that 2^16 is the "modern notation" for 216.  (I'm not saying the editor is an idiot, just that the view is idiotic.  As noted in the section above, the editor has idiotic views of English punctuation, as well.)
Any thoughts?
— Arthur Rubin  (talk) 15:33, 17 April 2015 (UTC)
thread_title:  HighColor and TrueColor 

message: I seem to recall the CPC+ range had additional colours available. Can anyone recall? Tim (Xevious) (talk) 16:19, 22 July 2015 (UTC)
thread_title:  GX4000 and CPC+ 

message: The palette shown here is the color palette from the 40x48 pixel Lowres mode. The majority of Apple graphic applications used the Hires mode, which had 280×192 pixels (effectively 140x192 on a color monitor). This mode only allows six colors; black, white, blue, orange, green, and purple. So the Apple II section of this article is very lacking, and should be expanded because the wikipedia page for Apple II graphics links to it.  — Preceding unsigned comment added by 2602:306:330A:D0D0:5DE7:1B58:17F0:7E7A (talk) 17:07, 5 October 2016 (UTC)
replies: text: The medium green color (no. 12, with hexadecimal value of #1bcb01) uses white text, because the Y value in YPbPr is 0.5.
Why the color #1 (#722640) is named magenta, not red? --2403:6200:8837:6844:E5AB:FB9C:6CBB:48BB (talk) 09:30, 10 February 2019 (UTC)

text: Fixed that. TreeNamedUser (talk) 23:10, 6 November 2020 (UTC)
thread_title:  Apple II 

message: Hello fellow Wikipedians,
I have just modified 5 external links on List of 8-bit computer hardware palettes. 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/20100401162933/http://www.fpgaarcade.com/resources/6561.txt to http://www.fpgaarcade.com/resources/6561.txt
*Added archive https://web.archive.org/web/20090105232121/http://www.canberra.edu.au/~scott/C%3DHacking/C-Hacking12/gfx.html to http://www.canberra.edu.au/~scott/C%3DHacking/C-Hacking12/gfx.html
*Added archive https://web.archive.org/web/20070927025035/http://plus4.emucamp.com/kb.php?id=500107 to http://plus4.emucamp.com/kb.php?id=500107
*Added archive https://web.archive.org/web/20071130055705/http://www.work.de/nocash/portar.htm to http://www.work.de/nocash/portar.htm
*Added archive https://web.archive.org/web/20071130055705/http://www.work.de/nocash/portar.htm to http://www.work.de/nocash/portar.htm
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) 00:14, 17 May 2017 (UTC)
thread_title:  External links modified 

message: They are supposed to be 0.3125 for 0.313 (5 in fourth decimal place, from 5/16), and 0.46875 for 0.469 (7 in fourth decimal place, from 15/32). Why the YPbPr values show only three decimal digits due to the rounding into three decimal digits. Also, the Pb and Pr value in YPbPr are rounded, too, as 0.383 is come from 0.3828125 (8 in fourth decimal place, from 49/128), 0.707 is come from 0.70703125 (0 in fourth decimal place, from 181/256), and 0.924 is come from 0.923828125 (8 in fourth decimal place, from 473/512).
:Also, it is supposed to use the rounding of YPbPr values within three decimal digits, and the YPbPr values are using binary fractions, obviously, they are used to being all binary fractions for these values.
:Noticeably, there are sign bit for marking for negative numbers.
--2403:6200:8837:2083:94CA:664D:1B0:59AB (talk) 03:51, 19 February 2019 (UTC)
thread_title:  Why the YPbPr values in Commodore color palette rounded to three decimal places? 

message: :
Number — name	Y    	Pb (rel.)	Pr (rel.)	Number — name   	Y    	Pb (rel.)	Pr (rel.)
0 — black    	0    	0        	0        	8 — orange      	0.375	         	
1 — white    	1    	0        	0        	9 — brown       	0.25 	         	
2 — red      	     	         	         	10 — light red  	0.5  	         	
3 — cyan     	0.625	         	         	11 — dark grey  	     	0        	0
4 — purple   	0.375	         	         	12 — grey       	     	0        	0
5 — green    	0.5  	         	         	13 — light green	0.75 	         	
6 — blue     	0.25 	1        	0        	14 — light blue 	     	1        	0
7 — yellow   	0.75 	−1       	0        	15 — light grey 	0.625	0        	0
*Note: Numbers with link blue-colored are going over three decimal digits.
:Yep, It says for the  is , not  . -- () 09:30, 9 March 2019 (UTC)
thread_title: In Commodore 64 with more accuracy of Pb and Pr in YPbPr

message: Which CGA low cyan or  is darker?
:Low cyan is purposed to be darker than , but the color contrast ratio is lower than . As color contrast ratio:  and . Please note the color  is darker than  due to the brightness and color difference, as , where  while using white text, but  and  while using black text for  and  by order. Obviously,  is darker than . -- () 09:44, 11 March 2019 (UTC)
thread_title:  Which CGA low cyan or high red is darker? 

message: Here you go:  -- () 06:00, 20 March 2019 (UTC)
thread_title:  What's the List of 8-bit computer hardware palettes by Nitrofurano archive? 

message: Been reordering the article to group different systems by palette type (RGB, composite, number of bits, etc). 
I think this helps future expansion and perhaps the creation of specific articles for each palette type.
4throck (talk) 14:12, 12 May 2021 (UTC)
thread_title: Systems grouped by type of palette

message: Had to revert dozens of nonsense edits by 78.70.38.73 They were random and/or only added repeated information.4throck (talk) 00:05, 17 November 2021 (UTC)
thread_title: Reverted nonsense random edits

message: I check pages listed in :Category:Pages with incorrect ref formatting to try to fix reference errors. One of the things I do is look for content for orphaned references in wikilinked articles. I have found content for some of :List of 8-bit computer hardware graphics's orphans, the problem is that I found more than one version. I can't determine which (if any) is correct for this article, so I am asking for a sentient editor to look it over and copy the correct ref content into this article.
Reference named "auto":
From Personal computer: Roy A. Allan, A Bibliography of the Personal Computer [electronic resource]: the Books and Periodical Articles, Allan Publishing – 2006, p. 73
From Cathode-ray tube: 
From Thomson TO7: 
I apologize if any of the above are effectively identical; I am just a simple computer program, so I can't determine whether minor differences are significant or not. AnomieBOT⚡ 16:34, 11 May 2022 (UTC)
replies: text: Fixed this one: "From Thomson TO7: "TO7-70 Circuit Diagram". dcmoto.free.fr." 16:49, 11 May 2022 (UTC)
thread_title:  Orphaned references in [[:List of 8-bit computer hardware graphics]]