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.)