VileRancour wrote:

• CGA type (new/old): doesn't have to be adjustable in real-time, although that's nice for testing. A config property would do for this, especially if it's "Changeable::Always".

I was also thinking about making it this way:
toggle: composite old/composite new/RGB/auto
(auto is only for mode 6 that doesn't change much between cards so could be left old as default)
or:
composite old/composite new/RGB/auto old/auto new
or:
composite old/composite new/RGB
kicking auto away from shortcuts at all.

And maybe temporarily we could assign old/new selection to ctrl-alt-F12

robertmo wrote:

I was also thinking about making it this way:
toggle: composite old/composite new/RGB/auto
(auto is only for mode 6 that doesn't change much between cards so could be left old as default)

This one sounds good (the default can stay "auto", which Qbix likes). Mode 6 does visibly change in hue between the two card types, but having "auto" default to "old" in that mode is fine by me.

robertmo wrote:

f12 - toggles emulated monitor type (composite, rgb, auto)
f11 - toggles hue/brightness/contrast/saturation/cgaversion
ctrl-alt-f11/ctrl-alt-12 - adjusts what was chosen by f12

What for? These settings are set once per game, and then never again. They belong in the config file, as they don't need to be adjusted in-game. If people want something to play around with, make these things mappable in the key mapper, but don't assign them by default.

reenigne wrote:

How does the TV know whether to use composite or RF mode? Or does it go by which input is selected?

Well, older TVs only have RF input, which is why I consider that variant so relevant. But for newer TVs, yes, it depends on the input selected.

reenigne wrote:

Don't forget that the color burst signal generated by the CGA card is a square wave and not the NTSC standard sine wave, so there's an additional factor of sqrt(2).

SMPTE-170M speaks of peak-to-peak amplitude for the color burst, not RMS.

reenigne wrote:

What do you mean by that?

The maximum/minimum excursion of a composite signal can be expressed as CVBS=luma ± chroma; chroma=SQRT(I*I+Q*Q). Multiplying composite by 0.5 will result in multiplying demodulated luma by 0.5, but not in multiplying demodulated I or Q by 0.5, thereby it won't result in multiplying decoded R/G/B by 0.5. Therefore, a contrast control must not work on the composite signal. Also see below:

reenigne wrote:

Consider a dark yellow, RGB (0.5, 0.5, 0). That has a peak-to-peak saturation of 0.5.

Uh, no:

1Y = 0.299*0.5 + 0.587*0.5 + 0.114*0.0 = 0.443
2R-Y = 0.5 - 0.443 = 0.057
3B-Y = 0.0 - 0.443 =-0.443
4
5U = 0.493 * (B-Y) = 0.493 *-0.443 =-0.218399
6V = 0.877 * (R-Y) = 0.877 * 0.057 = 0.049989
7
8C = SQRT(U*U + V*V) = SQRT(-0.218399*-0.218399 + 0.049989*0.049989) = SQRT(0.050197023322) = 0.2240469

A 0.5 yellow has a chroma signal of amplitude 0.224 and angle of 167.1 degrees. I am using U and V instead of I and Q for simplicity. It works the same way with I and Q.

reenigne wrote:

To get Tandy colours with my patch, you'd need to adjust pixel_clock_delay by 135 instead of hue_adjust.

No, in my algorithm, the pixel clock delay must be 135 for mode 6, and 315 for mode 4. Ultima II looks like this (because the screen has so much black in it, taking a TV picture would completely fail with my current setup):

NewRisingSun wrote:

reenigne wrote:

Don't forget that the color burst signal generated by the CGA card is a square wave and not the NTSC standard sine wave, so there's an additional factor of sqrt(2).

SMPTE-170M speaks of peak-to-peak amplitude for the color burst, not RMS.

It also says the color burst is supposed to be a sine wave. I suppose it depends on how the monitor measures it, but I think measuring the amplitude of that frequency would be much easier to do with analogue electronics than finding the true peak-to-peak amplitude. When you filter out the higher frequencies, the peak-to-peak amplitude of the 3.57MHz sine wave that you're left with will be sqrt(2) times the peak-to-peak amplitude of the square wave you started with.

NewRisingSun wrote:

Multiplying composite by 0.5 will result in multiplying demodulated luma by 0.5, but not in multiplying demodulated I or Q by 0.5,

I disagree. With an input signal C:
I = average(sin(t*2*pi*3.57MHz)*C)
Q = average(cos(t*2*pi*3.57MHz)*C)
For the doubled signal
I' = average(sin(t*2*pi*3.57MHz)*2*C) = 2*average(sin(t*2*pi*3.57MHz)*C) = 2*I
Q' = average(cos(t*2*pi*3.57MHz)*2*C) = 2*average(cos(t*2*pi*3.57MHz)*C) = 2*Q

NewRisingSun wrote:

A 0.5 yellow has a chroma signal of amplitude 0.224 and angle of 167.1 degrees. I am using U and V instead of I and Q for simpli […]
Show full quote

Copy code to clipboard

1Y = 0.299*0.5 + 0.587*0.5 + 0.114*0.0 = 0.443
2R-Y = 0.5 - 0.443 = 0.057
3B-Y = 0.0 - 0.443 =-0.443
4
5U = 0.493 * (B-Y) = 0.493 *-0.443 =-0.218399
6V = 0.877 * (R-Y) = 0.877 * 0.057 = 0.049989
7
8C = SQRT(U*U + V*V) = SQRT(-0.218399*-0.218399 + 0.049989*0.049989) = SQRT(0.050197023322) = 0.2240469

A 0.5 yellow has a chroma signal of amplitude 0.224 and angle of 167.1 degrees. I am using U and V instead of I and Q for simplicity. It works the same way with I and Q.

Okay, now do the same calculation with RGB (1, 1, 0) and you'll see that all the following are equivalent:

• doubling RGB
• doubling YIQ or YUV
• doubling Y and saturation
• doubling composite (the active picture part, not including the color burst).

NewRisingSun wrote:

No, in my algorithm, the pixel clock delay must be 135 for mode 6, and 315 for mode 4.

Ah, okay. That seemed very bizarre to me at first but now that I think about it, it must just mean that low-res mode is shifted horizontally by 1 low-res pixel from the high-res mode. I can certainly see how that could happen in the Tandy ULA.

Should we add the Tandy composite mode to DOSBox (by making F12 work the same for machine=tandy as for machine=cga)? The CGA-equivalent modes would be easy - it's essentially just new style CGA with a different (mode dependent) pixel_clock_delay (the DAC resistors are also slightly different but not significantly so - that could easily be included for completeness as well). Presumably the 160x200x16, 320x200x16 and 640x200x4 modes can also be used with a composite monitor, though, and those would be more difficult to shoehorn into the current algorithm since the colour of each decoded pixel depends on more bits of video memory.

reenigne wrote:

I = average(sin(t*2*pi*3.57MHz)*C)
Q = average(cos(t*2*pi*3.57MHz)*C)

I don't understand that. Why average?

reenigne wrote:

doubling composite (the active picture part, not including the color burst).

Well, there's the rub. Any automatic gain control would apply to the whole signal, not just the active picture part. And contrast would probably simpler to implement for the R,G,B signals as well.

reenigne wrote:

That seemed very bizarre to me at first but now that I think about it, it must just mean that low-res mode is shifted horizontally by 1 low-res pixel from the high-res mode. I can certainly see how that could happen in the Tandy ULA.

For some reason, for the CGA (old and new), I need to add a 90 degree phase delay to get expected results. I see that DosBox does, or should according to you, this as well:

1 double hue_adjust = (-(90-33)+hue_offset+pixel_clock_delay)*tau/360.0;

Here's from my current algorithm, which incorporates current findings for CGA old and new and for the Tandy, to match my experiments:

1switch (cga->model) {
2  case old:   phaseDelay = 90 + 14.6; burstAmplitude = 0.717948; break;
3  case new:   phaseDelay = 90 +  1.2; burstAmplitude = 0.287526; break;
4  case Tandy: phaseDelay = 90 + 45.0; burstAmplitude = 0.287526;
5              if (cga->modeRegister & 0x11)
6                 phaseDelay += 180 + 14.6;
7              else
8                 phaseDelay += 1.2;
9              break;
10}

The 14.6 and 1.2 are taken from the CGA part but match the visible results quite well.

Speaking of hue shifts: while making no functional difference, the algorithm is wrong in calling the chrominance signals I,Q. They should only be called I,Q when you're actually doing wide-band decoding for I. Since DosBox uses equiband decoding, they should properly be called U,V. Then the -33 could be removed from the above equation as well, and the decoding matrix could be the simpler YUV-to-RGB matrix (which is the YIQ matrix shifted by 33 degrees), which means two multiplications less, because R-Y and B-Y each have one zero coefficient. Again, it makes no functional difference, but right now it's a bit mistakable.

(Of course, the whole terminology is a bunch of crap anyway: in general quadrature modulation literature, I and Q just refer to the "in-phase" and "quadrature" component. In NTSC literature however, I and Q specifically refer to a wideband and narrowband color-difference signal shifted 33 degrees against the subcarrier, and wideband I can only partially be recovered by quadrature, so I is no genuine QAM "in-phase" signal. The equiband non-shifted color-difference signals are either called UV or just R-Y and B-Y, the latter of which is misleading, since they're scaled R-Y and B-Y, not the R-Y and B-Y themselves.)

reenigne wrote:

Should we add the Tandy composite mode to DOSBox (by making F12 work the same for machine=tandy as for machine=cga)?

I think composite support should be added to Tandy and PCjr, and you know what I think of the F12 thing.

reenigne wrote:

Presumably the 160x200x16, 320x200x16 and 640x200x4 modes can also be used with a composite monitor, though, and those would be more difficult to shoehorn into the current algorithm since the colour of each decoded pixel depends on more bits of video memory.

I haven't followed the DosBox-specific discussion closely, but it would indeed be difficult if you work on video memory directly. My algorithm has two parts, the first converting video memory to a 640x200 composite video signal, and the second doing NTSC decoding on that.

NewRisingSun wrote:

reenigne wrote:

I = average(sin(t*2*pi*3.57MHz)*C)
Q = average(cos(t*2*pi*3.57MHz)*C)

I don't understand that. Why average?

Average over time to implement the notch/bandpass filter. I should have left that bit out - it's not relevant to the issue of I and Q linearity.

NewRisingSun wrote:

reenigne wrote:

doubling composite (the active picture part, not including the color burst).

Well, there's the rub. Any automatic gain control would apply to the whole signal, not just the active picture part.

Well, the color burst is used as the reference amplitude, so its amplitude is constant after the AGC and therefore has no more effect on the saturation. I maintain that it would not be possible to tell from twiddling the contrast knob and looking that the resulting image whether the contrast knob works by scaling the composite signal right before YIQ separation or by scaling the final RGB values.

NewRisingSun wrote:

And contrast would probably simpler to implement for the R,G,B signals as well.

It's 1 multiplication if performed before YIQ separation or 3 after.

NewRisingSun wrote:

For some reason, for the CGA (old and new), I need to add a 90 degree phase delay to get expected results. I see that DosBox doe […]
Show full quote

For some reason, for the CGA (old and new), I need to add a 90 degree phase delay to get expected results. I see that DosBox does, or should according to you, this as well:

Copy code to clipboard

1 double hue_adjust = (-(90-33)+hue_offset+pixel_clock_delay)*tau/360.0;

The 90 degrees here is to compensate for the phase of the chroma signals in the "chroma_signals" array, as set in the "phases" array. I could just as easily remove the 90 from the hue_adjust calculation and add it to all the entries in "phases" - the only reason I didn't is because that's the way the code evolved.

NewRisingSun wrote:

Here's from my current algorithm, which incorporates current findings for CGA old and new and for the Tandy, to match my experim […]
Show full quote

Here's from my current algorithm, which incorporates current findings for CGA old and new and for the Tandy, to match my experiments:

Copy code to clipboard

1switch (cga->model) {
2  case old:   phaseDelay = 90 + 14.6; burstAmplitude = 0.717948; break;
3  case new:   phaseDelay = 90 +  1.2; burstAmplitude = 0.287526; break;
4  case Tandy: phaseDelay = 90 + 45.0; burstAmplitude = 0.287526;
5              if (cga->modeRegister & 0x11)
6                 phaseDelay += 180 + 14.6;
7              else
8                 phaseDelay += 1.2;
9              break;
10}

The 14.6 and 1.2 are taken from the CGA part but match the visible results quite well.

Odd that the Tandy would have the 14.6 degree delay in 640x200 mode but 1.2 in 320x200 mode - I'd expect the two modes to be exactly 180 degrees apart, not 193.4. Does it really look closer that way? Of course, who knows exactly what's going on with the logic delays in that ULA...

NewRisingSun wrote:

Speaking of hue shifts: while making no functional difference, the algorithm is wrong in calling the chrominance signals I,Q. They should only be called I,Q when you're actually doing wide-band decoding for I. Since DosBox uses equiband decoding, they should properly be called U,V. Then the -33 could be removed from the above equation as well, and the decoding matrix could be the simpler YUV-to-RGB matrix (which is the YIQ matrix shifted by 33 degrees),

Either way (YIQ or YUV) is fine with me. Though I think the terms "in phase" and "quadrature" are perfectly applicable to composite signals - they are after all used with other forms of QAM, not just broadcast NTSC with its weird bandwidth asymmetry between the I and Q bandwidths.

NewRisingSun wrote:

which means two multiplications less, because R-Y and B-Y each have one zero coefficient. Again, it makes no functional difference, but right now it's a bit mistakable.

If this code was speed-critical, I'd want to fold the YIQ-separation, band-limiting and YIQ->RGB matrix into a single (vector-valued) filter kernel which was precomputed anyway - if you do that there's no speed advantage to YUV, though I agree that having fewer coefficients floating around is nicer.

NewRisingSun wrote:

I haven't followed the DosBox-specific discussion closely, but it would indeed be difficult if you work on video memory directly. My algorithm has two parts, the first converting video memory to a 640x200 composite video signal, and the second doing NTSC decoding on that.

That's the way I'd ideally like DOSBox to go too, if we can figure out a way around the 8-bit palette problem. Going directly from video memory to palette entries is a bit of a hack to make it possible to use a limited palette, but it does also have the nice property of being really fast.

reenigne wrote:

It's 1 multiplication if performed before YIQ separation or 3 after.

You'll have to do more than one multiplication for S-Video or RGB inputs anyway. Since all modern TVs, and European TVs since 1980 or so, have to be able to handle RGB signals, applying contrast to the RGB signals will be the easiest way to take care of all possible inputs.

reenigne wrote:

I'd expect the two modes to be exactly 180 degrees apart, not 193.4. Does it really look closer that way?

Yes. Of course it could be that I did something else wrong, and spreading them apart this way counterbalances that. I wouldn't know what, though.

reenigne wrote:

Of course, who knows exactly what's going on with the logic delays in that ULA...

I would still like to know why monochrome mode doesn't work...

reenigne wrote:

Though I think the terms "in phase" and "quadrature" are perfectly applicable to composite signals

I agree with that. It's just that NTSC's I and Q signals are not the in-phase and quadrature signals, even though the letters are chosen as if they were. 😀

reenigne wrote:

not just broadcast NTSC with its weird bandwidth asymmetry between the I and Q bandwidths.

This is another reason to avoid the terms I and Q: no modern studio encoder, and no decoder after 1955, does wideband I decoding, so it's something to best be avoided.

Although it would be interesting to see how a CGA image would look with wideband I decoding...

reenigne wrote:

Should we add the Tandy composite mode to DOSBox (by making F12 work the same for machine=tandy as for machine=cga)? The CGA-equivalent modes would be easy - it's essentially just new style CGA with a different (mode dependent) pixel_clock_delay (the DAC resistors are also slightly different but not significantly so - that could easily be included for completeness as well). Presumably the 160x200x16, 320x200x16 and 640x200x4 modes can also be used with a composite monitor, though, and those would be more difficult to shoehorn into the current algorithm since the colour of each decoded pixel depends on more bits of video memory.

Not supporting composite output for these extended Tandy modes would be functionally incomplete emulation, and I don't exactly like the idea in principle. But as far as DOSBox is concerned, the question will pop up sooner or later - did any games use these modes specifically for artifact color generation?

A non-paletted approach would be ideal, of course, but the problems with that have been mentioned. Not impossible to tackle at a future date, but for now we can either forget about Tandy/PCjr and focus on the CGA, or restrict Tandy composite support to modes 4-6.

NewRisingSun wrote:

You'll have to do more than one multiplication for S-Video or RGB inputs anyway. Since all modern TVs, and European TVs since 1980 or so, have to be able to handle RGB signals, applying contrast to the RGB signals will be the easiest way to take care of all possible inputs.

True, that's a good reason for a TV to do the brightness and contrast on the RGB side.

NewRisingSun wrote:

I would still like to know why monochrome mode doesn't work...

It's probably just that your TV doesn't have a proper "colour killer" circuit - it continues to decode chroma even with a very tiny color burst signal - there are enough 3.57MHz signals bouncing around that one of them is strong enough for the oscillator to lock onto.

An interesting experiment to do would be to making the entire screen a single nybble pattern in mode 6 (with color burst disabled) and see what colours you get with different values. If it ends up using that pattern for its color burst, that pattern will come out to the same hue (probably yellow) no matter what pattern you use. If it comes out as different different hues depending on the nybble you use, that means that some particular 3.57MHz signal is leaking out into the blanking signal, and your TV is locking on to that.

I have a similar problem with my capture card - it doesn't disable chroma decoding even when the color burst amplitude is so low that it can't lock on to it at all - so, if the color burst is disabled then you get random lines of colour all over the screen whereever there is a 3.57MHz pattern.

NewRisingSun wrote:

It's just that NTSC's I and Q signals are not the in-phase and quadrature signals, even though the letters are chosen as if they were. 😀

Well, I is in-phase with *something*, it just so happens that the carrier it's in-phase with doesn't exist (unless you're displaying something orange). Yeah, it's not great terminology.

NewRisingSun wrote:

Although it would be interesting to see how a CGA image would look with wideband I decoding...

It would. I've only played with fixed kernels but it seems like it would be quite possible to have a kernel with whatever frequency cut-off you like - I believe blargg's NTSC libraries can do this to implement variable amounts of color fringing, but they don't have separate frequency cut-offs for I and Q.

reenigne wrote:

It's probably just that your TV doesn't have a proper "colour killer" circuit

According to the service notes, all color processing is done by the Motorola MC44002P "Chroma 4 Multistandard Video Processor", so beware.

reenigne wrote:

An interesting experiment to do would be to making the entire screen a single nybble pattern in mode 6 (with color burst disabled) and see what colours you get with different values.

Just did that. The results: different patterns produce different colors. In fact, if I compare mode 6 with mode register 1A and 1E, the colors in 1E are the 1A colors minus the 14.6 (or so) degrees hue shift mentioned earlier. How strange!

reenigne wrote:

I believe blargg's NTSC libraries can do this to implement variable amounts of color fringing, but they don't have separate frequency cut-offs for I and Q.

I'm not sure if it's as simple as using a different cutoff for I. SMPTE EG-27 states: "The second NTSC optimized the color resolution within the available 4.2 MHZ bandwidth by specifying
different bandwidths for the modulated I and Q components. The I signal, which corresponds to the eye's greatest color resolution sensitivity, was allocated a wider bandwidth than the Q signal. This was accomplished, when the two signals were placed in quadrature, by limiting the bandwidth of the Q signal and allowing amplitude, as opposed to quadrature, recovery of the lower sideband of the I signal. When added to the lower spectrum of the I signal recovered through the quadrature demodulation process, this yielded a wider bandwidth channel for the I signal."
Apparently you need to do what we already do for the quadrature recover, then do something else to recover the lower sideband if the I signal, then add the two I signal components.

Sherlock Holmes in "Another Bow"
a game simmilar to I, Damiano: The Wizard of Partestrada by the same company.
It says on the box it is for IBM PC and PCjr.
It has screenshots on the back of the box so we may know how the game should look like. Anyway it is not possible to set it correctly in dosbox. The screenshots on pc and c64 boxes are the same.
http://www.mobygames.com/game/sherlock-holmes … eCoverId,74759/
Could it look OK on PCjr?

Another game designed for new cga
http://www.mobygames.com/game/dos/willow/scre … meShotId,17283/

Hard to say with this one...
Greg Norman's Shark Attack! The Ultimate Golf Simulator
http://www.mobygames.com/game/greg-normans-sh … -golf-simulator

as for sierra games and shades of blue-green it looks only amiga
http://www.mobygames.com/game/amiga/kings-que … eShotId,331787/
http://www.mobygames.com/game/amiga/kings-que … eShotId,331770/
and atari st
http://www.mobygames.com/game/atari-st/kings- … eShotId,515686/
http://www.mobygames.com/game/atari-st/kings- … meShotId,62737/
had proper palettes for these games.

Championship Baseball
http://www.mobygames.com/game/dos/championship-baseball
This one is strange as it looks it is for the old one as the new one will have blue grass. Although both have green sky 😉

Edit:
screenshots on the next page

Quadrel looks better with the new one

Funny thing but it looks that none of 64 ega colors would suit the light blue-green for sierra games.

NewRisingSun wrote:

robertmo wrote:

f12 - toggles emulated monitor type (composite, rgb, auto)
f11 - toggles hue/brightness/contrast/saturation/cgaversion
ctrl-alt-f11/ctrl-alt-12 - adjusts what was chosen by f12

What for? These settings are set once per game, and then never again. They belong in the config file, as they don't need to be adjusted in-game. If people want something to play around with, make these things mappable in the key mapper, but don't assign them by default.

Switching to rgb is very useful for reading text while playing adventure games if you don't want to hurt your eyes 😉
Also trying to adjust TV/monitor settings with TV/monitor turned off is not really easy, actually i never tried that 😉
And forcing people to assign keys before adjustment isn't very user friendly. Those keys can be unmapped if someone for some reason don't like them, but that should be a rather rare case.

VileRancour wrote:

The idea sounds great in principle, but I don't know if such a scheme would be user-friendly enough for most people. F11/alt-F11 do give feedback on the console window; I usually run DOSBox fullscreen so the console isn't visible, but for now these keys only control a single property (hue_offset) so it's not too confusing.
If we let F11 cycle through the various adjustable parameters, that's an additional state change that the user has to remember, and can be disorienting without clear visual feedback

Maybe it would be possible to make dosbox's screen change a bit (forward and back) when function is being changed. For example screen will become brighter/darker for a while which would mean brightnest was chosen, etc. But I am not sure whether those features will go into the main dosbox build, so that doesn't have to be a problem as people using custom builds are rather smarter in these matters.

reenigne wrote:

Should we add the Tandy composite mode to DOSBox (by making F12 work the same for machine=tandy as for machine=cga)? The CGA-equivalent modes would be easy - it's essentially just new style CGA with a different (mode dependent) pixel_clock_delay (the DAC resistors are also slightly different but not significantly so - that could easily be included for completeness as well).

PCjr/Tandy had 16 colors from the beginning without any composite tricks, so what would be the use for composite mode for Tandy/PCjr? I guess those modes were useful only if someone had to use his tandy with a TV.

robertmo wrote:

Maybe it would be possible to make dosbox's screen change a bit (forward and back) when function is being changed. For example screen will become brighter/darker for a while which would mean brightnest was chosen, etc. But I am not sure whether those features will go into the main dosbox build, so that doesn't have to be a problem as people using custom builds are rather smarter in these matters.

As for the main build, seems like Qbix has indicated some interest (as long as there's no new machine type, and the auto-detection feature is retained). But even if it's just for unofficial builds, these things have to be clear and easy to control. If we start mapping keys with multiple properties, and adding visual cues to figure out what's going on, then it's getting out of hand - we'd need Mame32-style dialog boxes for that ;)

earlier I wrote that brightness control might not be needed, but this Championship Golf game says otherwise... I plan to do some testing later on, with adjustable brightness and saturation, to see what we get from a representative range of games. Not everything needs to be adjustable in the final patch, but this could help us see if there's an optimal saturation value that could be hard-coded, for instance.

Trying to mess around with adjustable saturation/brightness, for testing.

What would be a good algorithm for brightness control?

There are various models for calculating brightness, but we'd want something that produces similar results to NewRisingSun's Championship Golf images (top of page 17 in this thread): it almost looks like a gamma adjustment, but as far as I can tell, it isn't. Anything linear doesn't seem to do the trick.

VileRancour wrote:

Trying to mess around with adjustable saturation/brightness, for testing.

What would be a good algorithm for brightness control?

There are various models for calculating brightness, but we'd want something that produces similar results to NewRisingSun's Championship Golf images (top of page 17 in this thread): it almost looks like a gamma adjustment, but as far as I can tell, it isn't. Anything linear doesn't seem to do the trick.

Brightness is just a constant value added to the composite signal, or equivalently luma (or equivalently R, G and B before doing any gamma correction). Probably the easiest way is to add it to luma, changing:

1Y/=4.0;

to

1Y = Y/4.0 + brightness;

If that doesn't look like NewRisingSun's images then I don't know what he's doing.