CPUZ 1.16

[lechenejb]

CPUZ 1.16

et je découvre çà sur ppc ... sans nous prévenir, alors frank ... :(

[jcinfo]

oui moide meme :) !

[lechenejb]

on dirait que franck ne passe plus bcp ici ... :sweat:

[Franck@x86]

Eh oui en effet, la version 1.16 est sortie, j'allais poster mais tu m'as devancé JB.

J'ai envoyé un mail à Samuel, mais PPC a réagi plus rapidement.

Sinon je passe régulièrement, je réponds quand je sais...

[lechenejb]

excuse moa, franck ... mais bon d'hab on est les 1ers prévenu, c pour çà que je me disais ...

[macdriverz]

Quelles sont les amelioration de la 1.16 ?

[Dagobert]

CPU-Z 1.16

- Processeurs Barton pris en charge.
- Processeurs Transmeta Crusoë pris en charge.
- Chipsets Intel E7205 (GB), E7500 pris en charge.
- Nouveaux outils : "northbridge et southbrige dump".
- Informations plus détaillées pour le Pentium IV.
- Correction de quelques bugs.

[Franck@x86]

J'ajouterais même que j'ai enlevé des bugs, oui, mais de nouveaux sont apparus :|

"Long est le chemin qui mène vers le programme sans bug".

[lechenejb]

tu programme en koi franck ?

[Franck@x86]

Tu veux dire pour cpuz ?
95% en C++ et 5% en assembleur, et la plupart du code assembleur est dans les drivers.

[Dagobert]

Bon bah ma DDr-SDram tourne toujours à 3.3 V (dixit CPU-Z US).

Laurent me demandais quel capteur de température j'avais sur ma carte-mère, maintenant j'suis sùr.


Et c'est parti pour une traduction en Fr.

[Doc TB]

Franchement, si j'etais developpeur de soft, ca me saoulerais GRAVE qu'un mec modifie mon soft a la barbare comme ca. Je serais franck, je crypterais l'exe pour les prochaines versions :|

[Dagobert]

roh bah non Sam, lui donne pas de mauvaises idées. :twisted:

Je ne modifie rien dans son programme hormi les textes que je met en français.

En plus, la j'ai du merder parsque une fois traduite en Fr, la 1.16 ne voulait plus fonctionner. :(

[Doc TB]

Ah ben il nous a déjà mis quelques petits checksums :lol:

[Franck@x86]

eh oui ... désolé, j'ai protégé le prog cette fois-ci.

[Franck@x86]

Dagobert j'ai pas fait ça spécifiquement pour toi je te rassure.

Je vais ajouter une gestion multi-langue dans une prochaine version, à partir de là il sera simple de faire une VF.
Et en plus t'auras pas à te taper le boulot à chaque fois, ce qui sera bien plus pratique.

Voilà voilà.

[Dagobert]

:(
J'peux même plus m'amuser avec alors.

mais si tu fais une interface française, alors j'ai plus besoins de faire moi-même la traduction. :)

Et pour le problème de tension DDR !!!

[lechenejb]

oui, la tension ddr !!!

[bjone]

Franck, ptite question: tu la construit comment la chaine d'identification des modules de RAM à partir de l'eeprom SPD ?

(en passant j'ai aucunes info sur mon A7V333 et mes TwinMOS, fo que tu programmes le support SMBus pour les VIA ? )

cf un petit topic d'un monsieur qui se poses des question sur hfr:

http://forum.hardware.fr/forum2.php3?post=553099&cat=1&page=1&cache=cache&interface=&config=&p=1&sondage=&owntopic=1&subcat=#bas

[Franck@x86]

La tension de la DDR affichée correspond en fait à la tension I/O.
Si le senseur reporte la tension de la mémoire c'est bon, sinon ça correspond à l'entrée suivante, càd 3.3v.
Ca dépend beaucoup du modèle de la carte mère, et en fait les récentes tendent à zapper la tension DDR. Donc bon je devrais penser à l'enlever, malheureusement.

Pour les infos de la ram, s'il y a une interface SMBus ET que la ram est interfacée j'affiche les infos SPD. Le problème semble concerner le débit d'après ce que j'ai lu.
Alors comment ça marche ...
Très simple : à l'offset 10 du bloc SPD le prog lit la valeur de "cycle time" qui correspond au temps de réponse du module en ns.
Par exemple : 70h = 7ns, 65h = 6,5ns
A partir de là j'en déduis la fréquence maxi supportée : 1000/cycle time
Et finalement le débit : pour la DDR c'est 2x8xfréquence.
Exemples :
60h = 6ns = 166MHz = PC2700
50h = 5ns = 200MHz = PC3200
La 3500 c'est de la 4,5ns en principe, et j'en ai pas souvent vu, soit que c'est de la 5ns poussée soit les infos SPD sont pas à jour.

Si t'as pas les infos SPD, deux possibilités :
- l'interface SMBus n'existe pas ou n'a pas été correctement détectée.
- le SPD n'est pas interfacé sur le SMBus.

Pour savoir ce qui cloche génére le fichier "SMBus configuration".
Si l'interface a été trouvée :
- en A1, A3 ... A7 y'a les infos pour chaque module
- en 5B y'a le senseur
- en D3 y'a la PLL
Le prog supporte le SMBus VIA sans souci (enfin en général !)

voilà voilà ...

[lechenejb]

o fait sinon, dans la page html, on a que la barette 1 de ram affiché ...

[bjone]

La tension de la DDR affichée correspond en fait à la tension I/O.
Si le senseur reporte la tension de la mémoire c'est bon, sinon ça correspond à l'entrée suivante, càd 3.3v.
Ca dépend beaucoup du modèle de la carte mère, et en fait les récentes tendent à zapper la tension DDR. Donc bon je devrais penser à l'enlever, malheureusement.

Pour les infos de la ram, s'il y a une interface SMBus ET que la ram est interfacée j'affiche les infos SPD. Le problème semble concerner le débit d'après ce que j'ai lu.
Alors comment ça marche ...
Très simple : à l'offset 10 du bloc SPD le prog lit la valeur de "cycle time" qui correspond au temps de réponse du module en ns.
Par exemple : 70h = 7ns, 65h = 6,5ns
A partir de là j'en déduis la fréquence maxi supportée : 1000/cycle time
Et finalement le débit : pour la DDR c'est 2x8xfréquence.
Exemples :
60h = 6ns = 166MHz = PC2700
50h = 5ns = 200MHz = PC3200
La 3500 c'est de la 4,5ns en principe, et j'en ai pas souvent vu, soit que c'est de la 5ns poussée soit les infos SPD sont pas à jour.

Si t'as pas les infos SPD, deux possibilités :
- l'interface SMBus n'existe pas ou n'a pas été correctement détectée.
- le SPD n'est pas interfacé sur le SMBus.

Pour savoir ce qui cloche génére le fichier "SMBus configuration".
Si l'interface a été trouvée :
- en A1, A3 ... A7 y'a les infos pour chaque module
- en 5B y'a le senseur
- en D3 y'a la PLL
Le prog supporte le SMBus VIA sans souci (enfin en général !)

voilà voilà ...

oki.

bon j'ai regardé, cpu-z me fait un "No SMBus interface found !"

Mais, j'ai hwinfo32 d'installé, et lui aussi n'arrive pas à accéder aux infos SPD.

alors que Hwinfo Dos y arrive. (bizarrement y'a pas de chaines d'indentification sur les TwinMos).

Tu pense qu'un autre driver en mode kernel pourrait pertuber tes routines SMBus & celles de Hwinfo32 ? J'ai par exemple Motherboard Monitor d'installé...

[bjone]

j'ai désactivé le driver de motherboard monitor & de hwinfo, et il me fait toujours un "No SMBus interface found !".

à priori je n'ai pas d'autres .sys d'installé & de chargé en automatique ou en system qui pourrait accéder au SMBus.

[Franck@x86]

C'est quoi comme southbridge ?

[bjone]

A7V333 (bios 1016), donc KT333 + VT8233A

[Franck@x86]

Ah tiens bizarre, pourtant je le gère.
Pourrais-tu m'envoyer un PCI device list depuis cpuz stp ?
Merci ! :)

[bjone]

oki :D

[bjone]

comme j'ai dit dans l'email:

"buh !! ma carte réseau 3com est détectée 7 ou 8 fois !!!"