CPC Monitor Gamma?

[arnoldemu]

What determines the Gamma on a monitor and what is the Gamma of the CPC monitor?
I think this may be important to improve emulation...

EDIT: I am thinking more about the Gamma "ratio" or whatever it is called. The Gamma in computer graphics.
I think PC monitors have a gamma of 2.2? And you can adjust this.. I wondered what this value was for CPC monitors.
This would effect the final colours we see on the monitor.

[Gryzor]

Have no idea about the answer to this*, but: I thought, from the subject, that you were talking about the gamma rays emitted from the monitor

*I don't think the specs will be found anywhere, but OTOH I guess it'd be easy enough to determine it with the tools they use to check monitors... of course you'd have to factor aging in, which brings up the question: is what we're seeing now what we used to see?

[Bryce]

Hi Arnoldemu,
         you certainly like the difficult questions don't you I'll attempt to answer your question.....

Firstly, the phrase "gamma correction" (often wildly mis-used) is the function of correcting non-linearity of the luminance of a display for each colour channel. Put simply, if my red value can be anything from 0 to 255, then the steps from dark red to bright red should all have the same size steps throughout the available range of red (if the gamma value is 1.0). Unfortunately the electronics doesn't always manage this, so the colour difference between red 0 and red 10 might be much greater than the difference between red 245 and red 255 (or vice-versa). Gamma correction is simply a method of calibrating the steps so that the colour difference between all steps transmitted from the computer/graphic card is equal to what the monitor is expecting, so that the monitor reflects what the computer "wanted" to show.

The bad news: CPC colour monitors don't have any effective gamma correction. The colour luminance is controlled by three cheap transistors (Q801 - Q803 in the CTM644) and the only adjustments available (VR801 - VR805) would adjust the total colour range and relative strength of each colour but not correct gamma variances.

The good news: Gamma is only relevant for displays that can show a range of values for each of the colours R,G,B. Due to the fact that the CPC has a very limited selection of predefined colours and not RGB values, the gamma offset is completely irrelevant.

Bryce.

[Gryzor]

This reminds me of an old question I've had for quite a while: how does an emu coder go about choosing the colour he uses for the emulated machine's screen output? I never got a convincing answer to this...

[Executioner]

The good news: Gamma is only relative for displays that can show a range of values for each of the colours R,G,B. Due to the fact that the CPC has a very limited selection of predefined colours and not RGB values, the gamma offset is completely irrelevant.

Maybe so on a standard CPC, but a Plus has 15 levels for each of Red, Green and Blue, so it is more relevant.

This reminds me of an old question I've had for quite a while: how does an emu coder go about choosing the colour he uses for the emulated machine's screen output? I never got a convincing answer to this...

Originally WinAPE used a linear mapping from 0-15 RGB to 0-255 RGB (ie. R2 = R1 * 255 / 15). The CPC Plus used a value of 6 for the RGB value for the standard CPC darker (half-tone) shades. A few people seemed to think that was wrong, so I introduced a non-linear palette where the RGB 6 value was actually represented by 127 out of 255. I think a lot depends on the brightness, gamma correction and age of both your PC monitor, and the CPC monitor you're comparing it to.

[Bryce]

Yes, I was just referring to the classic CPC systems, as I have no experience with CPC+ systems. If 15 levels of each colour are possible, then the gamma ratio would have an effect. The question is how much of an effect? On PC systems it can be important when the user is editing photos etc, but is it really that important for a 15 level scale? Obviously it shouldn't be "way off", but as Executioner has mentioned, the brightness and age of the monitor can effect this too (and probably how long the monitor has been turned on too!), so which colour levels should be considered the "real" values? I'm sure if you put 10 of the machines side to side, every one of them would look slightly different, depending on personal preference of brightness and how long the monitor has been used.

Bryce.

[nocash]

Made some tests on my CPC6128, connected to a Philips Philetta TV Set (with RGB input).
The "half" intensity seems to be a little darker than what is seen as "half" on a PC.
For example, on the my CPC, the difference between yellow and pastel-yellow is very small.
So CPCs "half" seems to be more like circa 40% than 50%.
Assuming that the CPC+ does have a more PC-style intensity ramp, that'd also explain why the CPC+ uses "6" (instead or "7" or "8") for the 27-color mode.

Does that yellow (24) almost same as pastel-yellow (25) also apply on official Amstrad CTM monitors?
If yes, the "correct" way to emulate the CPC might be to use 40%. On the other hand, 50% gives more different colors, so even if that's wrong, it's having some advantages, too.

Another thing that affects colors is that R,G,B are tied together via resistors to produce the monochrome luminance signal. The resistors are of course also working in the opposite direction, so, for example, dark R,B levels will pull-down G.
I've checked the R,G,B voltages today, they are actually pulled up/down by each other.
The "min" and "max" levels seem to relative strong, they aren't affected too much by the other colors.
The "half" level is the weakest: It drops by 7% (0.05V on a 0.7V scale) when the other two colors are "min".
I'll upload some pictures of the R,G,B signals tomorrow.

Btw. the luminance should theoretically increase from color 0 to color 26. But what I've measured is a little zig-zagged; in some cases color N seems to be a little darker than color N-1. Not too important, and it may be caused by tolerance in the resistors or gate array, so maybe the zigzag effect doesn't occur on all CPCs.

[OCT]

I recall that when Amstrad Action came up with the proposal for a SCART cable back in issue AA41, numerous readers wrote in suggesting that resistors (most commonly: slightly below 330 ohms) should be connected "in series to the colour signals [...] for improving picture quality" (AA45, June 1989, FORUM, p. 23), so they seem to have appeared overblown in comparison to the CTM644s' back in the day.

[Apollo]

I feel a bit like I am stopping the party, but did nobody of you all read the excellent grimware page?
There are a lot of interesting measurements and Osci pictures of the color output of the GateArray.

Here the ink codes and the values in RGB measured:
http://www.grimware.org/doku.php/documentations/devices/gatearray#inkr.color-codes

Here the Osci-pictures where you can see the non-linearity and non-50% of the RGB levels:
http://www.grimware.org/doku.php/documentations/devices/gatearray#irgb.outputs

I can just recomment to read Grims great made site as I learned a lot from it!
I thought myself to check some stuff, especially the audio part but also some timing issues with an oscilloscope but as always time is the limiting factor to start with it!

@Grim: I regular check your page and always hoping you added something new as I think it is the most complete technical description of the CPC I ever found! Please, pretty please continue this great documentation!!

[Executioner]

but did nobody of you all read the excellent grimware page?

Not recently, very interesting.

@Grim: Any chance you could document what the GA does with the CPU signals (eg. WAIT, CLK etc) for various instructions (eg. extending all reads/writes and IO reads/writes).

[Gryzor]

Grim's pages are filled to the brim with goodies as always.

However, and with regards to what Executioner said: with all respect, but you're still not measuring what we see! From what I understand, both methods (stepping in Winape, measuring the RGB output on Grim's pages) only measure the CPC's output, but not what we actually see on the monitor itself. Which, I believe, is more important btw. To measure that, you'd need a few monitors, all of them at the same level of usage, preferably new, and start running photo/spectrometry or whatever tests on them... Only this would give you the correct values.

...and, of course, you'd then have to create colour profiles for your programs etc etc...

[Bryce]

Another thing that affects colors is that R,G,B are tied together via resistors to produce the monochrome luminance signal. The resistors are of course also working in the opposite direction, so, for example, dark R,B levels will pull-down G.
I've checked the R,G,B voltages today, they are actually pulled up/down by each other.

The resistors linking the colours are very high values (1K / 3.3K / 10K) compared to the output resistors (220 or 270 ohm). Does this really have an effect on colour cross-talk? It should only have a microscopic effect. Maybe the "pulling down" you've measured is coming from somewhere else?

Btw, wasn't aware of Grims site, excellent resource, will have to read some at the weekend.

[arnoldemu]

Grim's pages are filled to the brim with goodies as always.

However, and with regards to what Executioner said: with all respect, but you're still not measuring what we see! From what I understand, both methods (stepping in Winape, measuring the RGB output on Grim's pages) only measure the CPC's output, but not what we actually see on the monitor itself. Which, I believe, is more important btw. To measure that, you'd need a few monitors, all of them at the same level of usage, preferably new, and start running photo/spectrometry or whatever tests on them... Only this would give you the correct values.

...and, of course, you'd then have to create colour profiles for your programs etc etc...

This is why I asked about Gamma (as artist call it).

The colours come from the gate-array, are modified by a resistor network and then go to the monitor for display. What I was wondering, was then does the monitor perform a uniform "gamma-correction"/"gamma-adjustment" before display.
I know all CPCs and all monitors could produce slightly different colours, but based on an ideal value, e.g. 2.2 for PC displays, would this be true for cpc monitors?

I plan to measure the r,g,b outputs on all my cpc's so I can add to Grim's results and also I may be able to show if there are slight differences in outputs for different machines.

[arnoldemu]

Not recently, very interesting.

@Grim: Any chance you could document what the GA does with the CPU signals (eg. WAIT, CLK etc) for various instructions (eg. extending all reads/writes and IO reads/writes).

@Executioner: You'd be better to ask on cpcscene forums in case Grim misses this post.

[Gryzor]

What I was wondering, was then does the monitor perform a uniform "gamma-correction"/"gamma-adjustment" before display.

But, of course, although you're getting one step closer, you still don't measure what the actual output is. Ok, maybe the difference is negligible, but then again maybe there is something there...

And, of course every machine has a slightly different output, that's why I said oen should measure a bunch of them

[nocash]

Did knew the Grim pictures, nice! Just showing what I wanted to upload today... except, they don't show the effect where R gets affected G and B. Maybe Grims scope picked up too much noise to see it... or it doesn't occur with all hardware configs. It seems to confirm that "half" intensity is only 40%, not 50%.

So, anyways, here are my own pictures, http://cpcwiki.eu/index.php/CPC_Palette they aren't too beautiful quality, but the effect is well visible (it isn't dirt from the scope, you can see the "steps" clearly where scanlines with new color are output).

---

For measuring what is seen on the monitor... I have taken a picture of the TV screen (see above) but my camera didn't "see" it the same way as I did see it. Maybe that could be fixed by white balance or other manual calibrations - but then you'd have an subjective/adjusted result.

Measuring voltages is easier, gives better precision, at least concerning the "what happens in the CPC" part. Of course the monitor may interprete them this way or that way. So after all, one won't get around to compare the CPC screen with the PC screen.

[arnoldemu]

Thank you for the pictures.

I think the pictures show: (left-to-right is time, bottom-to-top is voltage)

But I am not sure of the "scale".
For ink 26, what is the voltage here, and what is the voltage difference between this and ink 25.
EDIT: Looking at the screen for green for example.

You mention the divider. Does that refer to the darker lines?

What about measuring other signals on the cpc, int, halt, other ga pins?

[nocash]

> But I am not sure of the "scale".
> You mention the divider. Does that refer to the darker lines?
Yes, the square fields are the dividers, each square is 100mV in height, and 500us in width. Thought that'd be self-explaining. Oops, no. Just noticied, the 500us was wrong, forget about that part. Anyways, the width is the time.

> For ink 26, what is the voltage here, and what is
> the voltage difference between this and ink 25.
Uhhh. Don't know :-) The min/max values: ink26 is circa 1.0V, ink0 is circa 0.25V. Yeah, that isn't very specific. I made the pics mainly to show the "stair steps" effect, the voltages as such didn't seem to be too important to me.

> What about measuring other signals on the cpc, int, halt, other ga pins?
Okay... /INT... In BASIC, /INT is between 1us and 5us LOW. Apparently the CPU must finish the current opcode (thus the different timings). Once when the CPU executes the interrupt, /INT goes high, though I don't know which signals do acknowledge the interrupt here (?) If the CPU doesn't execute interrupt, ie. when DI, then /INT stays LOW forever.

[Grim]

Any chance you could document what the GA does with the CPU signals (eg. WAIT, CLK etc) for various instructions (eg. extending all reads/writes and IO reads/writes).

I planned another scope session this spring, so I will take a close look at this. If there's any other requests, just leave me a message here (or PM).

Sorry for the lack of update on Grimware recently, I should commit all the change soon (ie. 1 month or so, after I recover from Breakpoint :).

[nocash]

Hi OCT, added the info on resistors to the http://cpcwiki.eu/index.php/TV_SCART_cable page.
I wonder how it "improves" the picture... Maybe it just decreases brightness, to match up with the brightness of TV channels... though I don't have resistors in the cable, and the picture always looked okay to me.

Just noticed, the scart page says "A TV SCART cable allows to connect the CPC/CPCplus to the TV set."
Shouldn't there be a BIG warning, saying that the TV must have a RGB input?
And maybe some statistics, saying how rare/popular that kind of TVs are.
Back in the eighties, I've bought a TV with RGB input, specifically for the CPC, I think back then, those TVs were rare. No idea if their popularity has increased/decreased since then?

Another fundamental requirement would be that the TV must have a SCART connector, but I guess people can figure out THAT part themselves before they build a SCART cable ;-)