Les nouvelles cartes mères trition PCI de 1995 ne semblent plus supporter les mémoires simm avec parité. Comme je prenais habituellement des simm sans contrôle de parité, je ne trouvais pas que cela pose un problème jusqu'à ce que je mette une carte Gravis-Ultrasound dans ma machine. Sous DOS, le pilote SBOS et l'utilitaire de test se plaignait de "nmi procedure disabled on this p.c." (procédure nmi désactivée sur ce PC, nmi signifiant non masquable interrupt). Le manuel qui disait que dans ce cas je ferais mieux d'acheter une meilleur carte mère, n'étais pas d'une très grande aide.
La Gravis-Ultrasound marchais très bien sur une ASUS-SP3 et une ASUS-SP4, malgré cela, mais la Gravis-Ultrasound max que GUS max au lieu du petit buffer pour la GUS - pourquoi, je ne le sait pas. Je n'ai plus ces problèmes avec les récentes cartes ASUS TP4 XE. Ces deux cartes sont équipées d'1M de DRAM. Ces problèmes ne sont probablement pas reliés aux problèmes de NMI, mais au pilote de la carte son ?
J'ai entendu dire que non seulement ASUS, mais la majorité des cartes PCI récentes n'ont pas de support de parité/NMI.
Pour compliquer - l'ASUS-TP4 (chipset triton) marche avec la GUS Max - il charge le pilote SBOS. Je doit admettre que je suis confus.
comme la SP3, mais le chipset est moins buggé.
Comme la AP4, mais plus récente, un chipset SiS, des fonctions d'économie d'énergie et tout en EIDE, rs232 avec 2 uart 16550 et un port //. Il n'y a que deux slots SIMM. Il semble que l'AMD486DX4/120 fonctionne, mais ne semble pas très stable bien marcher avec le NCR53c810 et certains systemes d'exploitations (Windows-NT, Windows95, OS2), apres avoir mis a jour vers une carte pentium ASUS SP4, tous les problemes ont disparus, donc, ca doit venir de la carte. Toutefois, cela semble tres bien marcher avec Linux.
Economie d'energie, 1VL, 3 ISA, 4 PCI, controleur EIDE embarqué, pas de controleur de disquettes, pas de ports rs232, ni de //. tres petite.
Reconnait l'AMD486DX2/66 comme un DX4/100.... does recognice AMD486DX2/66 as DX4/100 only. This can be corrected with soldering one pin (which?) to ground, but I would not recommend a board like this anyway.
The one I tested was broken for OS2 and Linux, but people are said to use it for both.
The VesaLocalbus-Slot is expected to be slower than the normal vesa-localbus boards because of the PCI2VL bridge, but without penalty to the PCI section.
like SP3-SiS, but for Pentium90/100.
has the Triton-Chipset for better performance and supports normal PS2-Simms as well as Fast-Page-Mode and EDO modules.
supports the new EDORAM and upcoming SRAM standards. At least SRAM is said to considerabely increase performance. Did for some reason not accept the 8M PS2-SIMMS working ok in ASUS SP4, after changing them against others, bigger looking ones, (16 chips instead of 8 if I remember right) it worked ok. Has been tested with P90 and P100.
if you have new information on problems with them, please report.
I tried to compare the speed of CPUs in two ASUS Mainboards: for 486 I tested the SP3 SiS (the one with one vesa-local-bus slot) and for 586 I tested the ASUS TP4/XE, each with 16M RAM, always the same unloaded system with another CPU, with whetstone and dhrystone.
I must admit, I have not read the benchmarks-faq yet, and will probably edit the section a loot soon. If you have any comments, please mail me.
I am especially confused about the amd486DX4/100 being faster on dhrystones than the DX4/120 version? I did not see that kind of inconsistency on comparing the P90 and P100.
Perhaps this was at fault: when I plugged in the amdDX4-100, I had the board jumpered for DX2-66. While the BIOS did report it as an DX4-100, the board might have used the wrong clockspeeds... but since DX2-66 uses 33Mhz * 2 and DX4 uses 33Mhz * 3, this would have been correct?
The board running with DX4-120 is jumpered to 40Mhz * 3 = 120 Mhz.
Another thing I wonder about is why the whetstones-result does yield so even numbers on some machines?
The board does like most in that price class -- write-through cache, no write-back. This should not be significant, maybe 3% of performance.
The BIOS supports scsi-drives under DOS/Windows without additional drivers, but with the board come additional drivers which are said to give better performance, for DOS/Windows(ASPI), OS2, Windows-NT, SCO-Unix, Netware (3.11 and 4, if interpreted correctly)
Gert Doering (gert@greenie.muc.de) was saying the SCO-Unix-driver for the onboard-SCSI-Chip was not working properly. After two or three times doing: "time dd if=/dev/rhd20 of=/dev/null bs=100k count=500" it kernel-paniced...
The trouble some people experienced with this board might be due to them using an outboard Adaptec-SCSI-Controller with "sync negotiation" turned on. (This predates the NCR driver release; hence the use of the Adaptec.) Please check that in the BIOS-Setup of the Adaptec-1542C if you use one and have problems with occasional hangups!
There is a new version of the ASUS-Board which should have definitely less problems. It is called ASUS-PCI-I/SP3G, the G is important. It has the new Saturn-chipset rev. 4 and the bugs should be gone. They use the Saturn-ZX-variant and the new SP3G has fully PCI conforming level-triggered (thus shareable), BIOS-configurable interrupts. It has an on-board PS/2-mouseport, EPA-power-saving-modes and DX4-support, too. It performs excellently. If you can get the German computer magazine C't from July (?), you will find a test report where the ASUS-Board is the best around.
Latest information about ASUS-SP3-G: You might experience crashes when using PCI-to-Memory-Posting. If you disable this, all works perfect. jw@peanuts.informatik.uni-tuebingen.de said he believed it to be a problem of the current Linux-kernel rather than the hardware, because part of the system still works when crashing, looking like a deadlock in the swapper, and OS2/DOS/WINDOZE don't crash at all.
Someone else with a very old ASUS-SP3 (saturn-I chipset) reported crashes with using XFree86, which went away when he installed the very latest betaversion which seems to work around a bit of the problems.
Unlike some other reports, I find the mouse pointer moves very smoothy under X (just like the ol' 386) - it is jumpy under some, but not all, DOS games though...
Performance is great!! I ran some large floating point tests and found the performance in 3x33 (100MHz) mode to be almost 1.5x that in 2x (66MHz) mode (large being 500x500 doubles - 4meg or so)... I was a little dubious about clock-tripling but I seem to be getting full benefit :-)
The heavily configurable energy star stuff doesn't work with the current AMD DX4 chips - you need an SL chip
I really need a SCSI disk and a PCI video card :-)
(I had a phonecall by a person who had this problem with the buggy SMC FIFO chipset, after using X-window they hung.)