CPUZ 1.16

**lechenejb** · 08/02/2003, 20h24

CPUZ 1.16

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

**jcinfo** · 09/02/2003, 15h39

oui moide meme

!

**lechenejb** · 09/02/2003, 17h27

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

**Franck@x86** · 09/02/2003, 18h20

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** · 09/02/2003, 19h59

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

**macdriverz** · 10/02/2003, 15h40

Quelles sont les amelioration de la 1.16 ?

**Dagobert** · 10/02/2003, 21h37

CPU-Z 1.16

- Processeurs Barton pris en charge.
- Processeurs Transmeta Crusoë pris en charge.
- Chipsets Intel E7205 (G

, 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** · 10/02/2003, 22h25

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** · 10/02/2003, 22h26

tu programme en koi franck ?

**Franck@x86** · 10/02/2003, 22h58

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

**Dagobert** · 10/02/2003, 23h14

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** · 11/02/2003, 11h39

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** · 11/02/2003, 14h34

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** · 11/02/2003, 14h47

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

**Franck@x86** · 11/02/2003, 15h45

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

**Franck@x86** · 11/02/2003, 15h56

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** · 12/02/2003, 14h56

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** · 12/02/2003, 19h16

oui, la tension ddr !!!

**bjone** · 13/02/2003, 19h06

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...=1&subcat=#bas

**Franck@x86** · 13/02/2003, 19h54

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** · 13/02/2003, 20h01

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

**bjone** · 14/02/2003, 10h45

Envoyé par 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à ...

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** · 14/02/2003, 10h55

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** · 14/02/2003, 12h38

C'est quoi comme southbridge ?

**bjone** · 14/02/2003, 13h19

A7V333 (bios 1016), donc KT333 + VT8233A

**Franck@x86** · 14/02/2003, 23h05

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

**bjone** · 15/02/2003, 01h23

oki :D

**bjone** · 15/02/2003, 01h28

comme j'ai dit dans l'email:

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

Discussion: CPUZ 1.16

Outils de la discussion

Règles de messages