Well on mildly happy news at least...

...I've finally been sitting down and stepping my machine through it's paces with a combination of Prime95 and RMClock to determine just how well my processor actually binned before being labelled an ML-class part, especially since it was originally sold before they officially acknowledged MT-37 as even being possible, let alone available. So the sheer fact it ran at 2.0Ghz at 35 Watts meant they stopped testing and binned it immediately.

Normally, the spec calls for this CPU to run at:
2.0Ghz @ 1.450 Volts @ 24 Amps for about 34.8 Watts of total power draw.
0.8Ghz @ 1.000 Volts @ 24 Amps for about 24.0 Watts of total power draw.

Turns out mine's currently survived two... make that three test stages wish Prime95 in Blend Mode at:
2.0Ghz @ 1.250 Volts @ 24 Amps for about 30.0 Watts of total power draw.
0.8Ghz @ 0.950 Volts @ 24 Amps for about 22.8 Watts of total power draw.

No huge savings at the low end... but good god I have a damn good chip for it to pull off only 30 watts at 2.0Ghz. I'm going to go for 1 hour of Prime95 Blend before I call this final, but it bombed out at 1.225 Volts instantly and 0.900 Volts just as instantly. 0.925 Volts resulted in some odd musical glitches as I was running WinAMP in the background for an audible 'system lockup detector' but that might have been as I was running a streaming radio station so I'll re-test at 0.925 once I've verified my peak power level.

Then comes the monotonous testing of the other 11 stepping levels I'll have defined, with their requisite 1 hour per level.

And sadly all this will be for nothing, as the Linux Athlon-64 stepping driver sadly only supports the 4 'officially documented' levels (Max, Max-0.2Ghz, Max-0.4Ghz, and 0.8Ghz) for the CPU. I find this amusing, actually, that nobody's modified the driver to support highly-granular stepping like the RMClock utility does. My one attempt at doing so resulted in numerous lockups becuase I simply don't understand what the code is really doing.

Also, mind you that all the above power-draws are peak power draws @ 100.0% Load. They aren't nominal or minimal power draws, which are MUCH lower once I re-enable the HLT-based idling RMClock adds. (Yeah, fancy that... Windows XP apparently doesn't issue full HLT instructions every chance it gets in it's idle-loop. Why am I not surprised?)

Edit: Looks like 1.250 was optimistic, finally blue-screened at about 30 minutes in. Bumped to 1.275, let's see if that works. =^.^=

Math-geekery Boredom...

Ever had an image set for a specific background color, that you wanted on some other background color?

Me too.

I decided to attack it from a mathematical angle.

It turned into something... mutant. Able to take two renderings with an object added, and convert that added object to an 'overlay' effect that could be toggled seamlessly on or off of the image.

But... it's still kinda slow for my tastes. Because I'm still trying to reduce the math to a fixed 'calculate alpha' approach instead of iterating through all the possible alpha values until it finds one that works.

Anyone out there feel like cracking their head against the math? I just figured this out in the last ten minutes or so, this is the basic formula set up for 0-255 integer-math images.

Test.Alpha = 1;
while (1) {
  Test.Color = (Overlay.Color - (Background.Color * (255 - Test.Alpha))) / Test.Alpha;
  if ((Test.Color >= 0) && (Test.Color <= 255))
    break;
  Test.Alpha++;
}

Color is to avoid having to repeat the same line identically for Red, Green, and Blue over and over again. It'll still be a maximum-of-alpha-needed-for-all-three-channels operation, but I'd like to avoid the 'step through all 200+ alpha values' problem this code runs into. It works wonderfully, but it's kinda obnoxious from a standpoint of effeciency.