Knut Roll-Lund wrote:
Actually no, to me KEGS does the colors more like NTSC. Maybe there is a kind of saturation difference which I think is not possible with RGB colorspace (would have to be YUV colorspace).
Ok, so we're talking about digital RGBI (like CGA, 16 colors only)? I thought this was an analog RGB thing as the IIgs is. In analog RGB you can of course do much the same colors as in YUV, but RGBI is by its nature limited to the 16 CGA colors.
Actually I find that the CGA monitor has a quirk there with the number 5 color, brown has distinctly more red than green interpolated with the rest of the colors it would have the RGB values R=170, G=170, B=0 but I think what I found on the net 170, 85, 0 is correct. All colors except brown are regular R,G,B gives 170 on the respective R,G,B while intensity adds 85 to all three (170+85=255 and 0+85=85). (0=0/3, 85=1/3, 170=2/3 and 255=3/3...)
That's correct. Brown is an exception. But I think all RGBI monitors do it this way (170, 85, 0) since "dark yellow" (170, 170, 0) is so ugly and not very useful.
I wonder how the real AppleColor 100 monitor displays the colors... Does anyone know how the "summing network" in the AppleColor 100 monitor is?There is also another difference with the RGB card, I get color in RGB in some situations that is white on NTSC and I get white in some situations that is colored on NTSC. For example. On the test/demo disks for that RGB card 'Apple Extended 80-Column Text - AppleColor Card Demo, The' I got from the net. ProDos side (2of2) 'DHR COLORS' display the text except the title is white while on NTSC it is really mixed up colors. DOS3.3 side (1of2) on RGB the startup logo is colored in stripes like the real logo while on NTSC it is white. Obviously this is not same as the original II. How does it fit with IIc and IIgs. The emulators does same as NTSC (text is unreadable). I now realize that IIgs might be more compatible in this regard than a IIe with RGB.
The IIgs uses analog RGB. Very different from RGBI. Also it emulates relatively closely the way the IIe hardware cooperates with the NTSC TV decoder to produce the colors. Only the color values themselves are not quite right.
This is what the 'DHR COLORS' looks like on CGA (I found that I could not take a satisfactory photo so this is a drawing, that is very similar to what I see).http://home.online.no/~kr-lund/AppleColor-CGA.png
The Text is obviously far more readable than on any "standard" Apple. It seems your RGB card interprets single-pixel wide lines as white to improve text readability, not as coloured like a standard Apple does.
This is the same grabbed from the Kegs emulator and looks much like NTSC, but on NTSC it is easier to read the text.http://home.online.no/~kr-lund/AppleColor-KEGS.png
KEGS supposedly uses the same algorithm as a real IIgs to decode color. So this should be very close to what you would see on a IIgs equipped with a RGB-analog monitor.
Here is an NTSC frame grab of the same, note that the framegrabber isn't that good and adds both general noise, sampling noise and conversion noise (YUV to RGB). But you can see that here the text, although colored, is readable. I think the fringes are from the YUV to RGB conversion.http://home.online.no/~kr-lund/AppleColor-NTSC.png
The fringes are normal to some extent. They're unavoidable because of the way standard Apple NTSC color works - for example the white box always has a bit of a purple and a green fringe at the left and right edges (or an orange and blue fringe).
I think that this difference in the emulated colored text pixels and NTSC is because what is a colored quad "pixel" in RGB is in YUV space and you get a Y component (luminance) that corresponds to the white pixel (of RGB) while UV (Chrominance) covers the quad. I think the emulators aren't doing this right...
Take a look at yae (Yet Another Apple Emulator). Try version 0.6, the last beta. It does it at least mostly right even though it's not been updated since 1997 or so - at least as good as you can do it without using some sort of softening filter and heuristics. I'm currently playing around with that emulator code a bit but I haven't found an easy way toward improving the graphics, beyond a "scanline" effect reached by darkening the lower of the two PC graphic lines it uses per Apple graphics line.
Knut