The newer trition PCI-Mainboards in 1995 did not seem to support parity-SIMMS anymore. Since I usualy took the cheaper nonparity-SIMMS anyway, I did not consider this a problem until I put the Gravis-Ultrasound into my machine. Under DOS the SBOS-Driver and Setup/Test utility does complain about "nmi procedure disabled on this p.c.". The manual says I'd better get a better mainboard in that case, not very helpful.
The gravis-ultrasound did work nice in the ASUS-SP3 and ASUS-SP4, inspite of this, but the gravis-ultrasound-max I have here got gmod to kernel panic on both boards, and sometimes when playing au-files via /dev/audio did strange things, like playing the rest of an older, previously played sound after the new one. The sounddriver does recommend a buffer of 65536 with the GUS Max instead of the small one like the GUS - why I do not know. I do not have such a problem with the newer ASUS TP4 XE boards, though. Both are equipped with 1M DRAM onboard. These problems are probably not related to the NMI-problem, but because of the sounddriver?
I heard not only ASUS but most of the newer PCI-Mainboards are lacking in parity/NMI-support.
Strange enough - the ASUS-TP4 (Trition Chipset) does work with the GUS Max - it does load the SBOS-Driver. I have to admit, I am confused.
like SP3, but less buggy saturn chipset
like AP4, but newer, SiS chipset, green functions and all the EIDE, rs232 with 2 16550 and centronics. Only 2 SIMM Slots, Does seem to work with AMD486DX4/120, but was not very reliably on NCR53c810 and various operating systems (Windows-NT, Windows95, OS2), after upgrading to a PentiumBoard ASUS SP4, all the problems vanished, so it must have been the board. Still does seem to work nice for Linux, though.
green functions, 1VL, 3 ISA, 4 PCI slots, only EIDE onboard, no fd-controller, no rs232/centronics. Very small size.
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.)