Your described problems pointing to an issue with L1:WB in combination with DMA access. This was a common problem in 486 platforms with introducing of WB-CPUs. The WB-mode needs a tight management of changed and writen adresses in RAM and caches. A two layer WB-mode (L1+L2 in WB) in combination with a component, which writes into the RAM in parallel to the CPU and the cache line (called DMA) is not easy to manage. The world of 486 were early pioneers ...

feipoa wrote on 2019-12-28, 21:01:

No I don't, sorry. I thought SV2GX4 had the greatest potential for L1:WB?

There may be another user here, who has a board with SIS 85C471 + POD + L1: WB + Adaptec SCSI in use and can give us the hint ... please! 😀

Hate to bump this thread but could anyone of you SV2GX4 owners check whether your board works with a POD and a GUS (Max or PnP) for Duke3D/ROTT/Raptor? Duke and Rott have issues with Midi, while sounds work fine. With Raptor it's the other way around.
I have a SV2GX4 Rev 1.7 here which butchers the sound for above games whenever I try to use the GUS with my POD83 - so far the only fix I found was disabling L1 cache altogether.
Also noted that CTChip hangs when attempting to fix the dirty-bit whenever I have 1024K L2 cache installed - however it works fine with 256K in place. I'll check the modified BIOS later today.

shock__ wrote on 2020-10-04, 06:05:

Hate to bump this thread but could anyone of you SV2GX4 owners check whether your board works with a POD and a GUS (Max or PnP) for Duke3D/ROTT/Raptor? Duke and Rott have issues with Midi, while sounds work fine. With Raptor it's the other way around.
I have a SV2GX4 Rev 1.7 here which butchers the sound for above games whenever I try to use the GUS with my POD83 - so far the only fix I found was disabling L1 cache altogether.
Also noted that CTChip hangs when attempting to fix the dirty-bit whenever I have 1024K L2 cache installed - however it works fine with 256K in place. I'll check the modified BIOS later today.

Hi Shock,

I don’t have a GUS but I’ve had issues getting sound effects working with Duke3D when I have a POD installed on the GX4. I’ve tried a SB32PNP, Awe64, and an ESS. All three will lock up my machine when trying the sound test. If I install an AMD 5x86, all else being equal, sound effects work fine. I think our issues are related. Are you using Feipoa’s bios or original Asus bios? I’m using Feipoa’s myself.

Update: disabling L1 cache also resolved the sound issue for me, obviously not ideal 🤣

Update 2: Moved jumper 21 to position 2-3 for L1 WT and set L1 to WT in the bios and this resolved my issue. You lose the WB performance boost but it’s much better than disabling L1 altogether. Thinking about adding a toggle for this. Please try it and let me know!

In case someone else comes across this, what I landed on for L1 cache settings, I set JP21 to position 3-4 for write back and in the bios config I set L1 to WB for Quake or L1 to WT for Duke3d. There are some garbled sound fx when laundhing Duke but plays fine in game. An acceptable compromise for me, so I don't have to keep swapping the JP21 jumper back and forth. Also placing this here so I don't forget what I did 🤣.

Hi, I know this thread has been inactive for a while, but if anyone sees it and can help me, I'd appreciate it. I mean, I have an MS-4312G motherboard and in another thread they recommended I use the Asus motherboard BIOS. The problem is that now MS-DOS gives me this error: HIMEM.SYS detected an untrusted XMS memory address at 0046C242h. I've tried reinstalling DOS but it's still the same. Otherwise, the motherboard is working fine. Another thing I don't know if it's possible is to change the name that appears in the BIOS POST, as I don't like how it appears.
As I said, if anyone can help me or fix this problem, I'd appreciate it.
I'll leave the thread I talked about before here: https://www.vogons.org/viewtopic.php?t=80886

The memory failure has nothing to do with Naming.
I would bet on bad cache or memory. Try to increase the timings and bursts for cache and RAM in BIOS first. In second step deactivate the 2nd level cache in BIOS, to whether the cache is involved.
In worst case you have to substitute cache or RAM.