Les derni�res cartes m�res PCI ne g�rent plus les barettes SIMMS � parit�. Comme j'achetais habituellement des barettes SIMMS sans parit� � cause de leur co�t, je ne pensais pas que ce soit un probl�me avant de rajouter une carte Gravis-Ultrasound dans ma machine. Sous DOS le pilote SBOS et l'utilitaire de test se plaignent de la sorte "nmi procedure disabled on this pc". La documentation conseille de changer de carte m�re dans ce cas, ce qui n'aide pas beaucoup.
La Gravis-Ultrasound fonctionne bien dans les cartes ASUS-SP3 et ASUS-SP4, malgr� cela, mais ma Gravis-Ultrasound-Max g�n�re avec gmod un "kernel panic" sur les deux cartes. De plus, de temps en temps, le fait de jouer des fichiers .au sur /dev/audio provoque des choses bizarres, comme jouer le reste d'un son pr�c�dent apr�s le nouveau. Le gestionaire de son recommende un buffer de 65536 octets avec la GUS Max contrairement au petit buffer de la GUS - je ne sais pas pourquoi. Les deux cartes poss�dent chacunes 1Mo de DRAM. Ces probl�mes ne sont peut-�tre pas li�s au probl�me NMI mais pl�tot au gestionaire de son ?
J'ai entendu dire que ce n'est pas seulement ASUS mais la pluspart des cartes r�centes qui ne g�rent pas la parit� et le NMI.
De plus en plus bizarre, la carte ASUS-TP4 � chipset Triton fonctionne bien avec la GUS Max - il charge bien le pilote SBOS. Je dois admettre que je ne comprends pas tout.
comme la SP3, mais le chipset Saturn est moins bugg�.
comme la AP4 mais plus r�cente, chipset SiS, fonctions d'�conomie d'�nergie, EIDE, rs232 avec 2 16550 et port centronics. Seulement 2 connecteurs pour barettes SIMM, a l'air de fonctionner avec l'AMD486DX4/120 mais pas tr�s fiable avec le NCR53c810 et sous diff�rents syst�mes d'exploitation (Windows-NT, Windows 95, OS2). Apr�s mise � jour vers une carte Pentium ASUS SP4, tous les probl�mes ont disparus ce qui confirme que cela venait de la carte. A l'air de bien fonctionner quand m�me sous Linux.
fonctions d'�conomie d'�nergie, 1 slot VLB, 3 slots ISA, 4 slots PCI, seul le contr�leur EIDE est int�gr�, il n'y a ni contr�leur de disquettes, ni rs232/centronics. Tr�s petite taille.
Prend l'AMD486DX2/66 pour un DX4/100. On peut corriger �a en soudant une broche (laquelle ?) � la masse, mais de toute fa�on je ne recommenderais pas cette carte.
Celle que j'ai test� ne fonctionnait ni sous OS2 ni sous Linux bien que certaines personnes l'utilisent avec ses deux syst�mes.
Le slot VLB est cens� �tre plus lent qu'un slot VLB normal � cause du pont PCI vers VLB, mais sans nuire � la rapidit� du cot� PCI.
Identique � la SP3-SiS, mais pour Pentium90/100.
Peut utiliser la nouvelle ram EDO et la future SRAM. La m�moire SRAM devrait augmenter les performances de fa�on consid�rable. Cette carte n'a pas accept� les barrettes PS2-SIMMS de 8Mo qui marchaient sans probl�me sur une ASUS SP4. Apr�s �change contre d'autres barettes plus volumineuses (16 puces au lieu de 8 si je me souviens bien) cela s'est mis � fonctionner. Test�e avec un P90 et un P100.
J'ai essay� de comparer la vitesse CPU sur deux cartes ASUS : pour le 486 j'ai test� la SP3 SiS (celle qui a un slot VLB) et pour le 586, la TP4/XE. Les deux cartes avait 16 Mo de RAM, le syst�me �tait inutilis�. Les tests whestone et dhrystone ont �t� employ�s en changeant le CPU.
Je dois reconnaitre que je n'ai pas encore lu la faq sur les benchmarks et que je serais donc amen� � beaucoup modifier cette partie bient�t. Si vous avez des commentaires, n'h�sitez pas � me les envoyer par courrier �lectronique.
Je suis sp�cialement �tonn� par le fait que l'AMD486DX4/100 est plus rapide au test dhrystones que le DX4/120 ! Je ne retrouve pas cette incoh�rence en comparant les P90 et P100.
Le probl�me vient peut-�tre du fait que lorsque j'ai branch� l'amdDX4-100, la carte �tait configur�e pour un DX2-66. Bien que le BIOS voyait bien qu'il s'agissait d'un DX4-100, la carte a peut-�tre utilis� les mauvaises fr�quences d'horloge... mais puisque le DX2-66 fonctionne � 33Mhz * 2 et le DX4 � 33Mhz * 3, cela aurait du �tre correct ?
La carte avec le DX4-120 est configur�e en 40Mhz * 3 = 120 Mhz.
Je me demande aussi si le test whetstone fournit des chiffres aussi �gaux sur d'autres machines ?
Comme la plupart des cartes de cette cat�gorie elle n'offre qu'un cache m�moire en lecture (perte de performances estim�e par rapport aux cartes avec cache en �criture : environ 3% (?)).
Le BIOS prend en charge les disques SCSI sous DOS/Windows sans pilote additionnel (ASPI livr�) Autres pilotes fournis : OS2, Windows-NT, SCO-Unix, Netware (3.11 et 4, d'apr�s ce que j'ai compris).
Gert Doering (gert@greenie.muc.de) affirme que le pilote fourni pour SCO ne fonctionne pas correctement. Plusieurs commandes "time dd if=/dev/rhd20 of=/dev/null bs=100k count=500" m�nent � un "kernel panic".
Il semble pr�f�rable, lorsque l'on emploie le circuit embarqu� d'origine Adaptec, de ne pas employer l'option de "sync negotiation" (configuration accessible gr�ce au setup en BIOS de la carte Adaptec).
Attention : de graves accidents d'exploitation ("kernel panic") surviennent parfois lors du red�marrage du syst�me apr�s un changement de configuration. Cela ne semble pas pr�ter � cons�quence (le red�marrage suivant se d�roule correctement) mais ... Test� par votre serviteur ! NdT.
Une version plus r�cente de cette carte-m�re existe (ASUS-PCI-I/SP3G, le `G' est important) et ces probl�mes ont probablement �t� corrig�s. Elle emploie le nouvel ensemble de circuits Intel (version 4) "Saturn-ZX" et supporte donc les options PCI les plus �volu�es (level triggered shareable and BIOS-configurable). En sus : port souris PS/2 (aux), dispositif d'�conomie d'�nergie EPA et support pour DX-4.
Les derni�res informations disponibles indiquent que certains utilisateurs de cette carte (ASUS-SP3-G) constatent qu'elle ne supporte pas (crashes sous Linux) l'option "PCI-to-Memory-Posting". Tout fonctionne parfaitement lorsque cette option est d�bray�e. jw@peanuts.informatik.uni-tuebingen.de pense que cela peut relever d'un probl�me avec le noyau Linux car certaines parties du syst�me semblent continuer de fonctionner lors des crashes, ce qui peut r�v�ler un bogue dans le code du swapper. MS-DOS, OS/2 et Windows ne pr�sentent pas ce sympt�me.
Contrairement � d'autres compte-rendus, j'ai trouv� que le curseur souris de d�place de fa�on tr�s souple sous X (comme sur le bon vieux 386) - par contre il sautille avec certains jeux DOS...
Les performances sont tr�s bonnes ! J'ai fais tourner des gros tests de calcul en virgule flottante ( 500x500 doubles - � peu pr�s 4megs) et j'ai constat� que les performances en mode 3x33 (100Mhz) �tait � peu pr�s 1.5x sup�rieures � celles en mode 2x (66Mhz)... J'�tais un peu sceptique � propos du triplement de fr�quence mais il me semble que �a tient ses promesses :-)
Le syst�me hautement configurable de gestion de la consommation "energy star" ne fonctionne pas avec les processeurs AMD DX4 actuels - il faut un processeur SL.
J'ai vraiement besoin d'un disque SCSI et d'une carte vid�o PCI :-)
(J'ai re�u le coup de t�l�phone d'une personne qui a eu le probl�me du composant d�fectueux SMC FIFO. Ils se plantent apr�s l'utilisation de X-window.)
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:43