Adding High/Low temperature readings

[The Coolest]

Been working on the layout a little bit. Adding the very much requested Low/High temperature readings:


Also split out the menu at the top; Settings, systray setup and always on top is in options and the rest is in tools.

Any thoughts?

[CoreTemp-User115]

current version for Vx64 is 99.4 temps read 20ish degrees higher(unadjusted, seen feedback of them being to lower before offset applied) then Speenfan and HWmonitor(PCWizard) and one other one i uninstalled a couple weeks ago. Also Core #'s are opposite, no big deal really, am satisfied getting core temps.

how about a mini OSD similar to PCWizard when that is minimized perma-set to be on top of all windows tho, even if its just the 2 temps - like in system tray now. Also, would like to see ambient/case temp when in window mode or some other reference temp

[The Coolest]

This is a Beta bug-fix release. Please report if you find any problems or have any suggestions please let me know so they can be fixed/implemented before the final release.

Version 0.99.4 (Build 75) - 27rd January, 2009

- Add: Show high/low temperatures. (Press F6 or the Tools menu to reset values)
- Add: On/Off switch for G15 applet in Tools menu.

- Fix: Settings window would open centered, and sometimes out of the desktop area.
- Fix: System tray icon very small in Windows 2000/XP/2003.
- Fix: AMD Athlon X2 4x50e series detected as 3x50e.
- Fix: Add support for Mobile Athlon 64 X2 TK-xx series and Turion 64 MK-xx series.
- Fix: Workaround added for when Core Temp fails to find supported CPUs on Phenom based systems.

- Change: Reorganized menu.
- Change: Only detect ES status for Core 2 series. Core i7 and Atom detection was incorrect.
- Change: TjMax for mobile Atom processors changed to 90C.
- Change: "Lion" codename for AMD Turion was changed to "Griffin".

32bit
64bit

Skibo1219:
I'll add the OSD to the to do list.
Regarding the higher temps, if you have a 65nm Athlon64 based system then AMD issued a fix for the bad reading most/all of these CPUs were reporting. (The fix is a 21C offset).

[CoreTemp-User118]

The latest 0.99.4.76 still cannot properly detect my Turion 64 mk36. Now it is shown as mk-22. with 0.99.4.65 it was AMD Processor 2200+. My other turion x2 tl-60 still has the frequncy problem but it is shown correctly.

Actually the tl-60 has the cool'n'quiet and the frequancy problem occurs. the mk36 doesn't has this cool'n'quiet (something with bios) and the frequncy is detected properly. Maybe tis can help.

my bug report:
http://alcpu.com/forums/viewtopic.php?t=531

[The Coolest]

Oops, as always, missed a line of code.
The next public build release will include a fix for this

Regarding the frequency. I'm going to rework the whole system of frequency detection and try to read the HTT/FSB speed instead of basing it on an out dated algorithm that's pretty much broken.

How do you like the new addition of High/Low values?

[CoreTemp-User118]

Oops, as always, missed a line of code.
The next public build release will include a fix for this

Regarding the frequency. I'm going to rework the whole system of frequency detection and try to read the HTT/FSB speed instead of basing it on an out dated algorithm that's pretty much broken.

How do you like the new addition of High/Low values?

I've not seen the code for the frequency detection but can't you just use the code from 0.99.3? I've seen other people (here in the forum) that are experiencing the same problems with the frequency. And they all say that 0.99.3 worked fine. It'll be great to make a new inplementation for it but maybe for the time being you have to revert to the code from 0.99.3. It's a workable solution untill you write the new one.

High/Low values:
Nice idea, but I don't know if it is consistent between program restarts. Every time I restart the program I've got new values which means that the lowest value (after restart) will be calculated from the currect temperature. So it won't be exactly the lowest one. If you put it in a file you have to manage to reset it in time periods like days or weeks. So maybe the lowest value won't have any significant meaning. Maybe you just have to leave the highest one (my personal opinion).

By the way: the current temp is shown in kind of brown colour when it is about 60C. Why don't you leave the colour to just black or let the user adjust it?

Some ideas about the layout:
It consists of 2 types of data:
1. One that changes like woltage, frequency, temp.
2. One that is a constant (chipset, id, etc)
Why don't you put the significant one on the left side and left the less important on the right side? I don't think that people are interested in seeing what kind of chipset they are using and the cpuid. This info should be there but it's not that important and maybe you can separate it in one place in the programe. Thie is of course my personal opinion.

[The Coolest]

The frequency problem will be fixed in a future release.

High/Low values are of course collected from program startup for monitoring highs and lows in a certain period of time. I see no point in saving that information in a file for future runs...

The color changes when the temperature goes above a certain preset value in the processor, it alerts you that the processor is running warm and red means it's running hot.
You can adjust the colors from the ini file (if you haven't deleted the ini from 0.99.3, you'll have to do so for Core Temp to create a new file with all the needed entries).

The values are formatted in a BGR hexadecimal format when 0xFF000000 tells Core Temp to use the default system colors.

Regarding the layout, I'm planning to implement a "mini-mode", so whenever you don't want to see all that extra information it can be hidden.

[CoreTemp-User115]

This is a Beta bug-fix release. Please report if you find any problems or have any suggestions please let me know so they can be fixed/implemented before the final release.

Version 0.99.4 (Build 75) - 27rd January, 2009

- Add: Show high/low temperatures. (Press F6 or the Tools menu to reset values)
- Add: On/Off switch for G15 applet in Tools menu.

- Fix: Settings window would open centered, and sometimes out of the desktop area.
- Fix: System tray icon very small in Windows 2000/XP/2003.
- Fix: AMD Athlon X2 4x50e series detected as 3x50e.
- Fix: Add support for Mobile Athlon 64 X2 TK-xx series and Turion 64 MK-xx series.
- Fix: Workaround added for when Core Temp fails to find supported CPUs on Phenom based systems.

- Change: Reorganized menu.
- Change: Only detect ES status for Core 2 series. Core i7 and Atom detection was incorrect.
- Change: TjMax for mobile Atom processors changed to 90C.
- Change: "Lion" codename for AMD Turion was changed to "Griffin".

32bit
64bit

Skibo1219:
I'll add the OSD to the to do list.
Regarding the higher temps, if you have a 65nm Athlon64 based system then AMD issued a fix for the bad reading most/all of these CPUs were reporting. (The fix is a 21C offset).

Hmmm, I'll look for that, thanks.

BTW, I agree with pepe on the low temp not being needed on the other hand if/when you get the 64 bit graph done it would be nice to see it there.with a timestamp, maybe.

[GigaByte]

Nice progress with CoreTemp over the last year or so (since the last time I posted here), and I really like the min/max temp readouts. Keep up the good work.

[The Coolest]

New beta is up here:
http://www.alcpu.com/forums/viewtopic.php?t=547

[Rhialto]

How do you like the new addition of High/Low values?

I would drop the low and replace it with time the highest was obtained.

I think we all want to avoid critical high temp (I don't care about the lowest I can get, it's when I power the cmoputer anyway).

With the timestamp, it could help spot what program could have been running at that time, etc.

My 2 cents

[The Coolest]

If you really want to see a specific time, you can simply turn on logging and see what time it was when the highest temperature was reached.
Regarding the grapher, I'll see what can be done.
But I'm really short on time, so I'm not sure when I'll be able to work on it.