rad wrote:

Somehow the CPU wasn't stable at the default voltage of 3.3V so I bumped it to 4V. Placed a 60cm fan to blow over its heatsync and it is not getting ever warm. With 4V it seems stable at this time. Actually I've enabled all of those higher FSBs 2 hours ago and still didn't have enough time to test stability and so on.

I haven't had success getting 2x66 running reliably on SiS 496/497-based boards. I tested 4 or 5 different boards. Have you run any Windows 9x benchmarks to determine if your setup runs reliably?

... I'm running 2x60 right now @ 3.3v and it seems to have installed win95 fine (after some problems with the HDD). After I'm done installing win95 I'll switch to 66x2 @ 4v and stick a V2 in - see how it runs. It doesn't seem to like EDO at 60 and 66Mhz fsb witch is disappointing - but I'll be fine if it's stable at 133MHz.

It is best to leave EDO RAM out of all 486-class motherboards. Even when you think you find a board which works with EDO, you will later find out that it is not reliable. Sometimes it works fine, other times it does not, sometimes it crashes randomly. I've been down this road many times. Save yourself a lot of eventual frustration and keep EDO out of 486 machines.

When running your 2x66 tests, set your Memory Read to 2 ws and Memory Write to 0 ws. Set your cache to 3-2-2-2. Set the I/O Recovery Time to 4 and IBC DEVSEL to slow. PCI CLK to 1/2. L2 to Write-back.

Actually, if you are interested, I modified my Biostar MB-8433 BIOS to set as default all the required setting for successful operation at 2x66.

Actually I was able to get my LS486E board mentioned at the beginning of the thread stable at 2x66 MHz operation few months ago. Sill working and pretty solid. To achieve that there are few important settings to set:
Cache Write Cycle: 2, Cache Burst Read Cycle: 2, L2 Cache/DRAM Cycle WS: 3 (Which I think is what feipoa means by 3-2-2-2)
DRAM RAS-to-CAS: 3, Write Cycle: 0, Write CAS Pulse: 1, CAS Precharge Time: 1, RAS to MA Delay: 1, DRAM Speed: Slowest, Slow Refresh: Disable, CPU L1: WB

In order to achieve full stability, I've been forced to set also:
L2 Cache to WT with 8 tag bits; With WB on L2 cache I wasn't able to achieve stability.
CPU->PCI Mem Post Write Buf: Disable; When Enabled there were very random lock-ups. For example PC restarts when I point the music control buttons in WinAmp during playback.

The memory I'm using is 2x32MB Micron 50ns EDO sticks. No problems with EDO have been noticed so far. I'm interested to know how to find out and test if EDO memory could cause any troubles.

Thanks to feipoa for his guide on his UMC board, I've also hardware modded the board to add a voltage regulator. The chip is different on SiS boards, but the approach is basically the same, just need to calculate properly the resistors and their ratio values. I can give you here the exact numbers and what and where to modify if you want. The IBM CPU is currently running fine at 2x66MHz stable at 3.8V.

I completed several short and long (32MB) runs of SuperPI on Windows 95. Also a lot of hours playing mp3s with winamp. Haven't tested on other windows versions, but on several other games and benchmarks. Tomorrow I can upload some photos on the modded board + screenshots with results if there's interest.

rad, this success is certainly encouraging! Is the speedsys shot you posted on page 1 from the final optimal/stable CMOS values?

Try letting MemTest run for 20+ hours. You can also try try transferring 30 GB or so over the network. I noticed the network test to be a great way to determine if something wasn't quite stable. Did you try playing an mp3 file uninterrupted for 2-3 hours with FP_FAST enabled? What about running Quake or GLQuake in loop for 1-2 hours? I would be surprised if your system could handle this and not crash. My system can handle it, but only if I used FPM memory. I am also using 2x64 MB of RAM, which requires a little more CPU voltage compared to 1x64 MB for some reason.

How did you arrive at 3.8 V? Was 3.75 V unsuccessful? I ended up running my IBM 5x86-133 system at 3.735 V as the min. voltage that could handle my stability tests.

Photos? There's always interest!

kanecvr wrote:

Thanks for this guide! My 100Mhz 5x86-100GP is also stable at 133Mhz / 4v - now if we could find a way to run it at 3.6v, it should be safer for the CPU and still get enhanced performance. (since the 133MHz cyrix runs at 3.6v according to specs)

I know it might be trivial, but weren't there some 133MHz 5x86's that ran at 3.7v instead of 3.6v? Iirc this was the case with the 24 133MHz parts from cpu-world some years ago and as I was pretty much somewhere in the front line of the group buy, I decided to pick a 3.6v one.

Btw, I'm pleasantly surprised people are still looking for undocumented jumper settings and coming with new information for Socket 3 boards. I've been considering writing a Vogons wiki entry specifically about 486 undocumented jumper settings, but all the information on Vogons seems to be kinda fragmented across several threads spanning several years.

Feipoa, do you happen to have some kind of list or database containing or at least linking to the information about undocumented jumper settings on 486 boards? If so, as soon as I have gathered enough information, I could condense all the relevant information onto a single page so the data is easier to find 😀

I tend to run my 5x86-133/4x chips at 3.70 V to be safe, although the 3.7 V marked chip seems to run fine at 3.60 V and 3.65 V. I only put it through some abuse at 3.65 V though.

I found the undocumented jumper settings on these 486 boards to be nearly all the same since they use similar clock generator chips. From memory, I think all UMC8881-based boards have the same jumper settings, as do all SiS496-based boards. I have the undocumented jumper setting written down for most of my 486 motherboards. If you are interested, I could type them all up and post them sometime. The Biostar MB-8433UUD setting are in my custom manual on the "world's fastest 486" link.

feipoa wrote:

I tend to run my 5x86-133/4x chips at 3.70 V to be safe, although the 3.7 V marked chip seems to run fine at 3.60 V and 3.65 V. I only put it through some abuse at 3.65 V though.

I found the undocumented jumper settings on these 486 boards to be nearly all the same since they use similar clock generator chips. From memory, I think all UMC8881-based boards have the same jumper settings, as do all SiS496-based boards. I have the undocumented jumper setting written down for most of my 486 motherboards. If you are interested, I could type them all up and post them sometime. The Biostar MB-8433UUD setting are in my custom manual on the "world's fastest 486" link.

I'm definitely interested and no need to rush 😀
Just see when you have some spare time, I'll need to make some time myself. I'll go check out the thread you mentioned and start absorbing the relevant data 😀

feipoa wrote:

rad, this success is certainly encouraging! Is the speedsys shot you posted on page 1 from the final optimal/stable CMOS values?

Thanks! The first two posts were from the first attempts, many things have changed since then. Here are my current stable CMOS values:

And here is SpeedSys screenshot:

It shows some very interesting results for memory throughput, although the DRAM speed is set to Slowest in the CMOS (actually I haven't played so far with this setting, because even now this setting seems very aggressive to me with 2x66 operation). Unfortunately the BIOS is not showing more specific and verbose settings, but as you can see it can handle 61.48MB/s speed, very close to L2 cache speeds. The same fast results are being shown in CACHECHK as well (in the next post) - it reports 84.5 MB/s with effective RAM access time (read) of 49ns.

feipoa wrote:

Try letting MemTest run for 20+ hours. You can also try try transferring 30 GB or so over the network. I noticed the network test to be a great way to determine if something wasn't quite stable. Did you try playing an mp3 file uninterrupted for 2-3 hours with FP_FAST enabled? What about running Quake or GLQuake in loop for 1-2 hours? I would be surprised if your system could handle this and not crash. My system can handle it, but only if I used FPM memory. I am also using 2x64 MB of RAM, which requires a little more CPU voltage compared to 1x64 MB for some reason.

I left it this morning to run MemTest and will leave it until tomorrow morning.
MP3 playback - yes, with FP_FAST. I've used it in my office as a music player for several hours (Windows 95 with WinAmp). Those are the settings I'm using for all Windows sessions:

I've run just 3-10 loops on Doom and Quake. I can loop them for few hours to try that.
About network traffic does it matter if it is transferred over Windows or over DOS? Tomorrow morning after MemTest I can try that as well, although I've transferred already 500+ MB of MP3 files before.

feipoa wrote:

How did you arrive at 3.8 V? Was 3.75 V unsuccessful? I ended up running my IBM 5x86-133 system at 3.735 V as the min. voltage that could handle my stability tests.

Photos? There's always interest!

Actually when I tested it before I remember that 3.7V was unstable. Then I played with various values in the interval 3.8-3.95V up to 4V until find stability. When I achieved that with the CMOS settings, Memory, etc I lowered the voltage to 3.8V and continued to run tests for stability and fun. Like listening MP3 files and browsing the Internet at the same time 😀 Since then I haven't tried 3.75V because everything is running fine so far (although that could be the sweet spot), but maybe I'll give it a shot.

Here are the promised results from CacheChk and other benchmark programs:

I can upload screenshots and results from several other programs as well (pcpbench, 3dbench 1 and 2, SuperPI with all various runs, Doom and Quake benches, vidspeed, etc)

Hardware mod - add variable resistor (potentiometer) for adjusting CPU voltage. This SiS board has 3.3/4V jumper option in addition to 5V option. With multimeter I've measured that 3.3V line gives me 3.45V output, whereas 4V line gives me 4.19V

3.3V is being used for many CPUs so I've decided to alter 4V line, in the same fashion as feipoa did. The voltage regulator used on this SiS496/497 board is LP2951:
http://www.ti.com/lit/ds/symlink/lp2950-n.pdf
Look at schematics on page 22 with the sample programming the output voltage. The approach on the board is the same, but instead of modifying the output voltage, it modifies the input one ( pin 8 ) with the output (pin 1) tied to the ground. The ratio is retrieved with group of 2 resistors out of 3:
3.3V: R32 + R36, i.e. 27k + 15k
4V: R33 + R36, i.e. 36k + 15k
The jumper setting sits on the "+" sign above, i.e. it switches the between R32 and R33. This is where the stable (feedback) voltage is produced with value of 1.23V (PIN 7)

The formula for calculation is the same as the one noted in the PDF on page 22, whereas:
R2 = 15k; R1 is either 27k or 36k.

The variable resistor I've decided to use is Bourns 3296w-1-503lf with 50k/0.5W values, which replaces R1 in the above formula, which equals to R33 on the board itself.
http://www.digikey.com/product-detail/en/3296 … LFCT-ND/3759199

Here are the pictures of the board before and after the mod:

Very nice! I haven't had any success with SiS 496 boards and 66 MHz FSB operation. I wonder if your success is in some way related to the small PCB size of this board - less cross talk, line capacitance, impedance mis-match issues, etc.

Did you try to reduce some values of your cache CMOS settings further?

Also, on my UMC 8881 board, I did not have the set the DRAM to slowest. Maybe you could experiment with that some.

You should be able to enable slow refresh, which is the faster setting.

PCI IRQ Activated by LEVEL is optimal. Did LEVEL not work?

What issues did the CPU-PCI Mem Post Write Buf cause when enabled?

The difference between your RAM and L2 speed may be too small for Speedsys to differentiate, so I am not sure if 61.5 MB/s is refering to your L2 cache or your RAM speed. Try to speed up your cache a little so that Speedsys detects the difference. Your L1 speed is 4 MB/s faster than what I got on my UMC 8881-based board.

I originally reported 56.5 MB/s for my Speedsys memory speed. However after extensive testing, and 2 years later, it was determined that I had to add an extra wait state to CMOS memory read to achieve the stability I was after. Now stable Speedsys memory score is 51.3 MB/s. This is likely due to me using 2x64 MB (128 MB) of RAM and 1024 KB cache. Your system has less to address, so you can handle these faster timings.

Are you after a fully stable configuration? You could also try to install NT4 and SP6a.

I would be very interested to compare our two IBM 5x86-133 systems with a Voodoo2 and GLQuake. Quake should fly on your system too. I would also be intereted to see if you are able to run Quake 2 in 3dfx mode when FP_FAST is enabled. If I leave FP_FAST enabled, Quake 2 will crash within 30 seconds, but GLQuake is fine.

Are you using a single stick of 64 MB, or two 32 MB FPM sticks? Using a single 64 MB FPM stick should help with stability and faster CMOS timings.

With extended longevity of your CPU, 3.75 V might be more ideal than 3.80 V.

Cachechk is reporting your main memory speed from your L2 cache. If you want to know your true memory speed, you could either a) try to increase your L2 speed in CMOS, b) disable L2 cache in CMOS and rerun cachechk/speedsys.

Your Norton Sysinfo v8.0 result is the best I've seen.

Could you run Quake 1.06 in DOS without sound and default resolution?

I find most boards use SMD for the VRM set resistors, which is unfortunate. it means you need to be careful when storing your MB's such that adjacent MB's don't bang into the Bourns trimmer. I've had one solder pad ripped off because of this. I fixed it with some epoxy. I now store my MB's which have the Bourns on SMD with RAM installed in the SIMMs, which are usually near the Bourns, to help prevent other MB's from banging the Bourns.

You are able to use LINBRST on a SiS496 board? Are you sure it is enabled?
EDIT: If so, it is probably due to a very late revision on your SiS496 chipset. Your revision is PR, which is one I have never see before, nor experimented with. I wonder if this late revision chipset is also, in part, responsible for your 66 MHz success.

Well I agree that the difference between RAM and L2 cache speed is too small for programs to detect that, but I think the reason behind that is not that the programs are referring L2 cache as the speed of RAM, but the opposite - actually RAM speed is very close to the speed of the L2 cache. As a proof I've disabled L2 cache completely and re-run all tests to compare the results:

Just take a closer look on the memory interval between 16kB and 256kB. Speedsys and CelemCacheTest are measuring a straight steady line after the first 16kB where no cache is in effect anymore. The values of CacheChk and the other 2 programs haven't changed at all when L2 cache is off compared to L2 on, which makes me truly believe those are values of RAM speed. CacheChk still reports speed of 84.5MB/s and the speeds of 13us/KB which are populated in the table are now not only from 512kB block size, but from 32kB and above. L2 cache speeds were a little faster - 11us/KB. And it makes perfect sense, since I'm using 66MHz bus speed which affect CPU-RAM bandwidth and throughput.

I really would like to try with faster CMOS settings for the Cache, but unfortunately the system is not stable as far as I remember. I've tried today to lower Cache Burst Read Cycle from 2 to 1, but this caused some Explorer.exe crashes in Windows, so this is no go. Maybe I'll try anyway again tonight to see if I can lower L2 Cache/DRAM Cycle WS from 3 to 2 since I don't remember if this was an issue or not in the past. I need to calculate that, but maybe this is the limitation of the actual cache chips - I've 4+1 TAG chips of 15ns (as it can be seen from the first screenshots on the first page). The other settings related to DRAM are already at the tightest possible values. I just need to test DRAM Speed to something higher that "Slowest" and DRAM Slow Refresh: Enable as well, since I didn't played with those settings yet.

Here is another screenshot I took this morning after running more than 23 hours of MemTest, which proves memory is running completely fine with those settings and speeds:

These results are very promising. I look forward to your further optimising and stability testing. Running Quake and GLQuake in loop is another good way to test for stability. That is the fastest memory throughput I've seen thus for on a socket 3. I hope you can benchmark the system with Quake, GLQuake, Quake 2, Doom, and the like. Try to source some 10 or 12 ns cache.

Hey feipoa I'll be more than happy to test further and provide more screenshots and results both for stability and performance. The memory that currently I'm using is this:

2 double-sided sticks of 32MB EDO each of 50ns. Actually I've 4 total (128MB) but since the cache on my board is only 256kB I didn't placed the other sticks on the board.

LINBRST is enabled and what is more interesting - although I'm setting this one explicitly, it is enabled by default all the time. After running the Peter Moss utility here are the settings I'm using under DOS: (compared for Windows sessions BTB is OFF and LOOP_EN is ON - as you can see from the screenshot from yesterday)

I did a run of Quake 1.06 demo under DOS on default resolution full-screen (actually the BAT file from Phil's VGA benchmark suite). Here is the result:

Now we come to the biggest problem, with the setting of "CPU->PCI Mem Post Write Buf" set to Disabled. I'm sacrificing maybe around 20% of PCI bandwidth because of that setting. Quake 1.06 demo drops from 16.5 to 16.1 3DBENCH2 drops from 102.1 to 83.3. PCPBENCH VGA drops from 24.4 to 23.5 and SVGA drops from 12.3 to 10.0 (!!!) DOOM timedemo drops from 1353 realtics to 1587 realtics. VidSpeed is also giving me interesting results for 640x480x8bit (default) - with the CMOS setting disabled I have:

Copy DRAM to banked VGA: 15.85 million bytes per second
Copy DRAM to linear framebuffer: 16.96 million bytes per second

But If I enable the setting:

Copy DRAM to banked VGA: 23.96 million bytes per second
Copy DRAM to linear framebuffer: 26.54 million bytes per second

Unfortunately Windows (for now only in Windows) is not stable with that settings. If Network is enabled soon after DHCP gives it an address sometimes the PC restarts. The same happens if I start WinAmp and play some MP3 and hover the mouse over the play controls (during playback). Very weird but this happens everytime. The PCI peripherals can't handle it someway. And when PC restarts it starting to BIOS and testing memory in some awful resolution. Very strange.

This is a common problem with SiS496-based systems using PCI network cards and fast cache timings. I'm going off of memory here, but I recall you can either have the cache write cycle set slower (like at 3) and leave the Mem Post Write Buffer enabled, or keep the cache write cycle set at 2 and disable Mem Post Write buffer. This has nothing to do with running with a 66 MHz FSB - I encountered it with a 33 MHz FSB. I don't recall if this is a Cyrix/IBM 5x86 specific issue or not. Anyway, I did not like either of those solutions so I went with an ISA network card. The MB-8433UUD does not have his problem, however as I am using a Voodoo2, I did not have an extra PCI slot and still had to go with an ISA network card.

Could you run Quake 1.06 directly, that is, not using the VGA Benchmark Suite? All my benchmarks, including those of my ultimate 486/686 benchmark comparisons are tallied when using Quake 1.06 directly and with default Quake settings. Ensure that you disable sound with the -nosound command line, or remove any sound card.

Sure, I'll try that tonight or tomorrow morning and post results here. I'm going to look for a Voodoo2 card as well, so that I can run Quake in 3dfx modes and compare the results 😀

Regarding the PCI problems I don't remember having those issues on 33MHz FSB. I was experimenting with AMD processors before (even on 40MHz) plus this IBM/Cyrix but on 33 MHz FSB. On both processors I've had that setting enabled. Because of the problem with the network card I've replaced it with 3COM ISA card and now there are no problems anymore with the network under Windows. But in addition to the problem with the WinAmp playback and mouse hover on the player buttons I've got one additional BSOD during loading of windows "VFAT initialization error" or something like that. In order to remove this from the equation I'll have to find out an IDE controller not integrated on the board to the PCI bus, like in my case. But again I'm left with the video card and possible PCI issues around it. Can you recommend stable video card for our case? I was looking for Tseng ET6000 for some time but still haven't found cheap one. All described issues here are not experienced on 33Mhz FSB with Enabled option *and* 66Mhz FSB with disabled option as well.

I'll try to test with Cache Write Cycle to 3 if this will fix the PCI issues and report here agian...

Did you set the jumper to run your PCI bus at 1/2 FSB freq? This is essential. Your PCI bus should be running at 33 MHz.

The issue with the PCI network card with a 33 MHz FSB did not manifest itself immediately, but after a few minutes of sustained network file transfer.

The onboard IDE controller should work fine if you have the 1/2 FSB jumper set. I never use onboard IDE on a 486 though. I like to use Adaptec 2949U2W SCSI cards in PCI-based 486s. For IDE/SATA, I have had success with the Promise SATA150 TX2. For IDE-only, I think the Promose ATA66/100/133 should work fine. That card is a little fussy about where you attach your CD-ROM though. I can't recall if it required me to attach the CD-ROM as slave, or use as master on the secondary IDE port. Some were also sensitive about using 80 wire vs. 40 wire cables.

Running with the cache write cycle at 3 will reduce your benchmark cache or DRAM results quite a bit.

Why do you think there is an issue with your existing PCI graphics card (Millennium II?) I use a Matrox G200 combined with a Voodoo2 in my setup, however, since you are using a board with a SiS496 chipset, you should be able to use a Voodoo3 PCI card.

OK here's the thing. I think I've found the culprit with the strange PC restarts. You won't believe but the issue is coming from the .... sound card.

First I was testing with various other options.... tried Cache Write Cycle 3, tested various ISA speeds, different memory WS and so on, even with some of the Cyrix features off, turned L1 and L2 completely off... nothing worked. On 60/66 MHz FSB there is a problem. Then somehow I've decided to remove the sound card. I was using Creative Sound Blaster Pro 2.0 ISA sound card, non PnP, all setup by jumpers. When the card is configured and drivers in windows load, sometimes immediately, sometimes when playing mp3s, the PC restarts.

I've replaced the Creative's card with ESS 1938s PCI sound card. Plugged in, loaded it's drivers in Windows and voila... no more problems. MP3s are playing fine, PC seems stable in Windows now with the "CPU->PCI Mem Post Write Buf" set to Enabled. Since PCI freq is truly 33MHz (I'm using the PCI/FSB divider set to 1/2) the only affected speeds are those of the CPU, memory, cache. Of course we've got the PCI bus connected to the FSB via the SiS496 PCM and the ISA bus via SiS497 ATM, but their speeds are fixed.

I can't explain why an old ISA sound card has issues with this buffer which should be only between CPU and PCI. The only answer I can come up right now is because of DMA on the sound card and the fast speed of the main memory. Furthermore if that was the case disabling that buffer shouldn't fix the issue, should it? But on the other hand ESS card don't have any issues, although it also has DMA mode. Is it because card in ISA slot has frequency of only 8.33 MHz compared to 33MHz on the PCI card? Very strange.

On the other hand there is one interesting paragraph in the Sis496/497 datasheet, uploaded here:
SiS 486 Chipset Datasheets

Page 77, point 2.5. wrote:

Posted write buffer contains the address, data and control posted write buffer. PCI master memory write cycles destined to ISA memory are buffered in a 32-bit Posted Write Buffer. As soon as a PCI master has posted a memory write into the posted write buffer, the buffer is scheduled to be written to the ISA Bus. Any subsequent PCI master cycles to the 85C497 (including ISA Bus) will be pending until the posted write buffer is empty. If the posted write buffer is disabled, the 85C497's response to a PCI master memory write is dependent on the state of the ISA Bus. If the ISA Bus is available and the posted write buffer is disabled, the cycle will immediately be forwarded to the ISA Bus. Prior to granting the ISA Bus to an ISA master or the DMA, the PCI master posted memory write buffer is flushed. Also, as long as the ISA master or DMA owns the ISA Bus, the posted write buffer is disabled. A PCI master write can not be posted while an ISA master or the DMA owns the ISA Bus.

I'm not sure if this has any relation with the CPU-PCI mem post write buffer, but at least it mentions the ISA bus into the equation.

I'm really interested to understand how the 66MHz vs 33MHz FSB is related to the ISA sound card. And how disabling the CPU-PCI mem post buffer is workarounding that issue.

The ISA frequency is usually a CMOS-selectable divisor of the PCI frequency. Did you try setting the ISA speed to PCI/3 instead of PCI/4, to see if speeding it up helps?

I ran into a similar problem with my AWE64Gold card on my 66 FSB 486 system. I thought it was everything else but the sound card. This took 2 years to finally nail down. I needed to set the I/O Recovery Time to 4 BCLK instead of 2 BCLK. 2 BCLK worked fine for 33-40 MHz FSB, but not at 66 MHz FSB. If your BIOS doesn't have the I/O Recovery Time feature visible, you could try to use modbin to unhide that feature. Or you can send your BIOS image to me and I can look at it.

You should also set your PCI IRQ activated by LEVEL, if you have not done so already.