VOGONS


Evolution of a Socket3 System to a POD @100MHz

Topic actions

Reply 20 of 83, by Anonymous Coward

User metadata
Rank l33t
Rank
l33t

I think the reason the cacheable area is halved with WB mode in many systems is because the dirty bit doesn't have its own IC, but is instead made available by sacrificing a single bit from the main TAG piece. This is probably a form of cost cutting. I think it should be possible to have WB enabled with the dirty bit and cache the full amount of system RAM if you can provide the dirty bit without stealing space in the TAG ram. It might also explain why sometimes you find boards that have a 9-bit TAG RAM instead of using standard 8-bit SRAM cache.

Last edited by Anonymous Coward on 2019-11-19, 14:34. Edited 1 time in total.

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 21 of 83, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie

By modifying bios, you can switch from 8bit tag + dirty into 7bit tag + dirty and then you don't need to mess around physically on the board. (Need to set some register bits in the bios rom and then flash it on the bios chip)
Though, i think you halve the max cachable ram amount this way.

Re: 486 cache/ram speed issue with write-back

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 22 of 83, by mpe

User metadata
Rank Oldbie
Rank
Oldbie
Anonymous Coward wrote:

But there is no performance advantage against WT. On the contrary WT is often faster.

I'd say it's complicated. Long books have been written about this (not just in CPU cache context, but in caching in general).

I guess since your CPU's L1 is already WB mode, no matter how you se the L2 policy most of the WB benefits (unblocking write operations) is already provided by the L1. By setting L2 to WB you are simply optimising CPU's write-back buffers.

I’d interpret your results as “the difference between different L2 cache modes is negligible”.

You could get a very different situation if you had a WT CPU, 64MB of RAM (and a task that could absolutely use that amount of RAM) then allocating par of tag space on dirty would halved the cacheable size which could lead to much bigger impact than <1% framerate differences in DOOM.

If you have 16MB and rest of system that can handle write-back coherency, then yes it absolutely makes sense to use the WB with tag.

Blog|NexGen 586|S4

Reply 23 of 83, by Warlord

User metadata
Rank l33t
Rank
l33t

Pretty nice rig there. I've tossed around the idea of upgrading mine to a pod 83 but have resisted becasue I thought that it's no longer a 486 anymore now its a Pentium and I have a bunch of Pentiums already. 😐

Reply 24 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++

On the Asus SV2GX4 board, I noticed that some VLB graphic cards case use the faster "Transparent" setting, while some needed "Synchronise".

I've run a similar comparison between 1024K VLB vs. 1024K cache PCI systems. Performance comparison of 486 motherboards with VLB-only, PCI-only, and PCI+VLB

For the Asus Sv2GX4 board, did you update the BIOS? I recall a BIOS update being needed for L1 write-back to work properly with certain chips.

Seems odd to use the more optima, but not 100% stable, settings for DOS benchmarking compared to normal operation BIOS settings.. I try to find the stablest point by using various programs in Windows to test for stability, then use the stable settings to benchmark in DOS. Does your system run any Windows version?

I noticed that when you compared the effect of using the L2, write-back, with dirty, that you have L1 set to write-back mode, yet in other benchmarks, you used L1: write-through mode. Why did you test the effect of L2:WB using L1:WB?

Normally, using the Pentium Overdrive 83 in WB mode offers a substantial boost in performance. The problem is that most 486 motherboards don't properly suport the POD in write-back mode. I recall that the Sv2GX4 wouldn't work with the AMD X5 in L1:WB mode unless you updated to the latest BIOS. Have you done this already? I don't know if it will fix the POD's L1:WB operation though (I doubt it).

I might try this dirty mode hack on my SV2GX4 system, but I'd have to take it out of the case. I need to check my past notes about the TAG mode first though. Did you use 128kx8 or 64kx8 for your dirty tag? The photos don't show.

I'm curious if the dirty tag hack shows any performance benefit for situations where the CPU's L1 cache is properly working in write-back mode. Are you able to test the benefit of the dirty tag hack using the P24D in L1:WB and L1:WT modes?

I can't recall off the top of my head if the SV2GX4 has a hidden 7+1 TAG mode in the BIOS. Have you checked the BIOS in modbin? I find that some boards permanently place the TAG in 8+0 mode and cannot use L2 write-back cache properly unless that feature is unhidden in the BIOS. Since this board only supports up to 64 MB of RAM, using the original TAG for dirty has no impact on max RAM cacheable size. If the board could accept 256 MB, then I can see the advantage of a separate dirty TAG, that is, assuming it would cache all 256 MB of RAM in L2:WB mode.

Warlord wrote:

Pretty nice rig there. I've tossed around the idea of upgrading mine to a pod 83 but have resisted becasue I thought that it's no longer a 486 anymore now its a Pentium and I have a bunch of Pentiums already. :neutral:

I had a POD at 100 MHz in a case once. I ran out of empty cases and replaced it with an X5-160.

Plan your life wisely, you'll be dead before you know it.

Reply 25 of 83, by PC-Engineer

User metadata
Rank Member
Rank
Member
Warlord wrote:

I thought that it's no longer a 486 anymore now its a Pentium and I have a bunch of Pentiums already. 😐

Yes, youre right, its no 486 anymore. In the beginning of this project it shold get a typical 486 with VLB, but as i found out, that my Pentium Overdrive was able to run with 100MHz i changed the mission. 😀 On the other hand i have no typical Pentium system in this class and i am going to build up a typical 486 ISA system for the 486 world.

feipoa wrote:

On the Asus SV2GX4 board, I noticed that some VLB graphic cards case use the faster "Transparent" setting, while some needed "Synchronise".

The STB Lightspeed and Miro 20SD run both well in transparent mode. Additional i can do tests with a ATI Mach32 and a Spea Mercury (S3 928) with 83MHz if you want, because both doesn't supply above 33MHz VLB Speed.

feipoa wrote:

I've run a similar comparison between 1024K VLB vs. 1024K cache PCI systems. viewtopic.php?f=46&t=46122

I knew your tests, and read it very interested, thanks!. I wasn't able to dissolve the dependencys of the different graphics chips and vendors. Maybe my tests with other boards are useful additionally.

feipoa wrote:

Seems odd to use the more optima, but not 100% stable, settings for DOS benchmarking compared to normal operation BIOS settings.. I try to find the stablest point by using various programs in Windows to test for stability, then use the stable settings to benchmark in DOS. Does your system run any Windows version?

I run windows 3.11, but only sound applications, office and WinTach, without any crashes. In my experiences the Second Reality Demo reacts very bitchy on instabilities because it is programmed very hardware-related. The issue i found out in transparent mode takes place any time at the same spot. Also the ctramtest runs the RAM stability to the limit. Otherwise i have not experienced any crashes. Which Windows version and which program would you recommend? I am going to install Win95 in the christmas holidays.

feipoa wrote:

I noticed that when you compared the effect of using the L2, write-back, with dirty, that you have L1 set to write-back mode, yet in other benchmarks, you used L1: write-through mode. Why did you test the effect of L2:WB using L1:WB?

The answer is simple, i did the benchmarks in all modes. But it gives a better focus here for comparision if i only post the three values. And where yus ask here are all values with WB and WT for L1 and L2 😀

benchmarks cache POD83.JPG
Filename
benchmarks cache POD83.JPG
File size
91.64 KiB
Views
1300 views
File comment
Pentium Overdrive @83MHz Cache comparision
File license
Fair use/fair dealing exception
feipoa wrote:

Normally, using the Pentium Overdrive 83 in WB mode offers a substantial boost in performance. The problem is that most 486 motherboards don't properly suport the POD in write-back mode. I recall that the Sv2GX4 wouldn't work with the AMD X5 in L1:WB mode unless you updated to the latest BIOS. Have you done this already? I don't know if it will fix the POD's L1:WB operation though (I doubt it).

As you can see in the picture above, i can confirm you, that the POD83 delivers a substantial boost in performance with L1 WB. I updated the BIOS before the buildt up to the latest official non BETA version (i guess) - to version 402.1. I read about your and vetz experiences with this BIOS version and the L1 setting to AUTO, but by had no success with L1 in WB. On the other hand saw a similar effect on the QDI, only after BIOS update it posted with the P24D in L1 WB mode (didn't try the P24T there).

feipoa wrote:

I might try this dirty mode hack on my SV2GX4 system, but I'd have to take it out of the case. I need to check my past notes about the TAG mode first though. Did you use 128kx8 or 64kx8 for your dirty tag? The photos don't show.

I used 128k8 chips (ISSI from china) for tag and dirty. It is possible to use a 64k8 too. The idea is to add the dirty tag bit to the tag, so i think you should use the same chip like the tag, but maybe i am wrong and you can mix it...

feipoa wrote:

I'm curious if the dirty tag hack shows any performance benefit for situations where the CPU's L1 cache is properly working in write-back mode. Are you able to test the benefit of the dirty tag hack using the P24D in L1:WB and L1:WT modes?

Yes i was. Here you can see, that the WB for the POD has a lot more effect than for the P24D. Curiously, the P24D in L1WB/L2WB is slower than in L1WT/L2WB.

benchmarks cache P24D.JPG
Filename
benchmarks cache P24D.JPG
File size
90.74 KiB
Views
1300 views
File comment
P24D @66MHz Cache comparision
File license
Fair use/fair dealing exception
feipoa wrote:

I can't recall off the top of my head if the SV2GX4 has a hidden 7+1 TAG mode in the BIOS. Have you checked the BIOS in modbin? I find that some boards permanently place the TAG in 8+0 mode and cannot use L2 write-back cache properly unless that feature is unhidden in the BIOS. Since this board only supports up to 64 MB of RAM, using the original TAG for dirty has no impact on max RAM cacheable size. If the board could accept 256 MB, then I can see the advantage of a separate dirty TAG, that is, assuming it would cache all 256 MB of RAM in L2:WB mode.

I didn't try modbin because i had no empty 512kBit EPROMS anymore to try out. An other reason, that i did the HW hack for dirty tag, was the hope, that then the problem with the Adpatec SCSI controller will be solved - unfortunately without success.

Very nice and interesting questions, thanks! 😀

Epox 7KXA Slot A / Athlon 950MHz / Voodoo 5 5500 / PowerVR / 512 MB / AWE32 / SCSI - Windows 98SE

Reply 26 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++
PC-Engineer wrote:

The STB Lightspeed and Miro 20SD run both well in transparent mode....33MHz VLB Speed...

I meant the VLB graphics cards run at 40 MHz along with the VLB SCSI adapter present. Does Transparent still work?

PC-Engineer wrote:

Which Windows version and which program would you recommend? I am going to install Win95 in the christmas holidays.

I noticed that 3D Winmark test from Ziff-Davis 3D Winbench97 suite and and the Graphics WinMark from the Ziff-Davis Winbench96 suite to cause errors with some less stable CPU configurations, paritcularly when the CPUs have already been running other benchmarks for 30 minutes prior, like letting WinQuake autoplay in loop first. 3DMark99max is another stressful benchmark program for a 486. Installing Win95 is another good first test. Running MemTest 4.00 overnight is also a good idea.

PC-Engineer wrote:

I updated the BIOS before the buildt up to the latest official non BETA version (i guess) - to version 402.1.

From the BIOS zip archive: sv2g4021.bin VL/I-486SV2GX4 Beta BIOS 0402.001 (1999)
Looks like you are using the necessary Beta BIOS.

PC-Engineer wrote:

As you can see in the picture above, i can confirm you, that the POD83 delivers a substantial boost in performance with L1 WB. ...Here you can see, that the WB for the POD has a lot more effect than for the P24D. Curiously, the P24D in L1WB/L2WB is slower than in L1WT/L2WB.

I originally looked at the POD in Quake. With benchmarks starting with L1/L2:WT/WT, then switching to L2:WB (no dirty), we get a 17% increase, then switching to L2:WB (dirty hack), we get an addtional 3.5% boost. So that's a 20.8% boost total.
Still using the POD in Quake. With benchmarks starting with L1/L2:WB/WT, then switching to L2:WB (no dirty), we get a -1.9% decrease, then switching to L2:WB (dirty hack), we get a 3.3% increase (on that -1.9%.), for an overall boost of only 1.4%

Thus for the POD running its L1 in Write-through mode, in Quake, the dirty tag write-back L2 cache hack offers a 3.5% benefit over the unhacked write-back L2 mode. When running the POD in L1: Write-back mode, then the dirty tag write-back L2 hack offers a 3.3% benefit over unhacked write-back L2 mode, or an overall net benefit of 1.4% compared to L2 being run in write-through mode.

Looking now at the P24D in DOOM. Benchmarks starting with L1/L2:WT/WT, then switching to L2:WB (no dirty), we get a 3% increase, then switching to L2:WB (dirty hack), we get an addtional 0.3% boost. So that's a 3.3% boost total.
Still using the P24D DOOM. With benchmarks starting with L1/L2:WB/WT, then switching to L2:WB (no dirty), we get a -0.3% decrease, then switching to L2:WB (dirty hack), we get an addtional 0.7% increase, for an overall boost of only 0.3%

Thus for the P24D running its L1 in Write-through mode, in DOOM, the dirty tag write-back L2 cache hack offers a 0.3% benefit over the unhacked write-back L2 mode. When running the POD in L1: Write-back mode, then the dirty tag write-back L2 hack offers a 0.7% benefit over the unhacked write-back L2 mode, or an overall net benefit of 0.3% compared to the L2 being run in write-through mode.

PC-Engineer wrote:

I didn't try modbin because i had no empty 512kBit EPROMS anymore to try out. An other reason, that i did the HW hack for dirty tag

I checked Modbin, but there is NOT a hidden option to set the TAG mode from 8+0 to 7+1. So on this motherboard, the TAG hack may be necessary to properly use L2 in write-back mode.

PC-Engineer wrote:

was the hope, that then the problem with the Adpatec SCSI controller will be solved

I am able to get the Adaptec VLB SCSI controller, a VLB graphics card (S3 Vision968 w/4MB) in synchronise mode, a 40 MHz FSB, and L1:write-back working with an Am5x86-160, using 1024K cache and 64 MBR RAM.

I'm trying to determine if I want to engage the effort of taking the whole case apart for a 0.3 to possibly 1.4% in total performance gain. I'm adding to to my ever growing list none-the-less. Thank you for point this out to everyone.

Plan your life wisely, you'll be dead before you know it.

Reply 27 of 83, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote:
PC-Engineer wrote:

I didn't try modbin because i had no empty 512kBit EPROMS anymore to try out. An other reason, that i did the HW hack for dirty tag

I checked Modbin, but there is NOT a hidden option to set the TAG mode from 8+0 to 7+1. So on this motherboard, the TAG hack may be necessary to properly use L2 in write-back mode.

I also didn't have it, but was able to enable 7+1 mode by changing directly the register bits.

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 28 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++
GigAHerZ wrote:
feipoa wrote:
PC-Engineer wrote:

I didn't try modbin because i had no empty 512kBit EPROMS anymore to try out. An other reason, that i did the HW hack for dirty tag

I checked Modbin, but there is NOT a hidden option to set the TAG mode from 8+0 to 7+1. So on this motherboard, the TAG hack may be necessary to properly use L2 in write-back mode.

I also didn't have it, but was able to enable 7+1 mode by changing directly the register bits.

Hmmm... CHCHIP34 can probably set 7+1, but that doesn't help for use in NT4. Could you provide instructions for how your are setting the register bits for 7+1?

Plan your life wisely, you'll be dead before you know it.

Reply 29 of 83, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie

@feipoa, it's in the earlier link i posted: Re: 486 cache/ram speed issue with write-back

modbin allows to set arbitrary register values as well. Using the chipset's datasheet, i just changed the necessary bits to enable 7+1 mode.

Later in thread, i think someone created a dos application to set bits on the fly.

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 30 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Oh, perhaps PC-Engineer can test this DOS program out to see if the results using the register mod method are the same as the tag hack mod?

Plan your life wisely, you'll be dead before you know it.

Reply 31 of 83, by PC-Engineer

User metadata
Rank Member
Rank
Member
feipoa wrote:
PC-Engineer wrote:

The STB Lightspeed and Miro 20SD run both well in transparent mode....33MHz VLB Speed...

I meant the VLB graphics cards run at 40 MHz along with the VLB SCSI adapter present. Does Transparent still work?

Yes it works, but only, if the SCSI Controller is plugged into the VLB port near the CPU. This effect is independent from VL Mode (transp. vs synchr.). The only issue with transparent mode, i found out until now, was the problem with Second Reality. Did you observed problems with transparent mode and VLB frequency? If i should find out any problems (by testing in Windows 95) with using VLB with two devices @40MHz i would switch to Ithe 1542CP (ISA). It is only minimal (appr. 20%) slower with my current HDD, but would cause a serious loss of 😎 -factor.

feipoa wrote:

I noticed that 3D Winmark test from Ziff-Davis 3D Winbench97 suite and and the Graphics WinMark from the Ziff-Davis Winbench96 suite to cause errors with some less stable CPU configurations, paritcularly when the CPUs have already been running other benchmarks for 30 minutes prior, like letting WinQuake autoplay in loop first. 3DMark99max is another stressful benchmark program for a 486. Installing Win95 is another good first test. Running MemTest 4.00 overnight is also a good idea.

Ok, thanks! I will test it as soon as I have Windows 95 installed, hope earlier than christmas ... 😀

feipoa wrote:

I originally looked at the POD in Quake. ... the dirty tag write-back L2 cache hack offers a 3.5% benefit over the unhacked write-back L2 mode.

With the SV2GX4 we have two effects, which help to reduce the disadvantage of missing dirty tag: A really fast memory interface in the SIS471 and a cache size of 1024kB. With smaller cache size and/or programs with more memory or cache usage and/or slower memory interface you have a higher difference.

feipoa wrote:

I am able to get the Adaptec VLB SCSI controller, a VLB graphics card (S3 Vision968 w/4MB) in synchronise mode, a 40 MHz FSB, and L1:write-back working with an Am5x86-160, using 1024K cache and 64 MBR RAM.

Maybe we talk about different problems with SCSI. My problem has nothing to do with the 40MHz bus speed or VL-mode. With activated L1/WB and (Adaptec VLB and ISA) SCSI i have the following szenario: The post is general normal (can enter MB-BIOS and SCSI-BIOS), but cannot boot from SCSI. Also a boot from IDE with installed SCSI BIOS (connected SCSI-HDD) makes system freeze. If i keep the VLB-SCSI Controller installed and disconnect the SCSI-HDD, the boot via IDE is without problems.

feipoa wrote:

Oh, perhaps PC-Engineer can test this DOS program out to see if the results using the register mod method are the same as the tag hack mod?

Hmmm, for this test i have to dismount my HW-hack first, to see the effect of SW solution only. I actually thought I'm done with my project 😉

@GigAHerZ
Thanks for your support too! 😀

Epox 7KXA Slot A / Athlon 950MHz / Voodoo 5 5500 / PowerVR / 512 MB / AWE32 / SCSI - Windows 98SE

Reply 32 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++

My issue is with the S3 968 when using the faster transparent mode at 40 MHz. I must use synchronise. If I use a Mach64, I can leave it on transparent.

There is a jumper on the Adaptec VLB SCSI controller that you need to set when the CPU is being used in L1:WB mode. This fixes problems I encountered with L1:WB. It may only work for 486 CPU's, I'm not sure. Did you set this jumper for the POD?

I actually thought I'm done with my project

Seems like we are never really finished.

Plan your life wisely, you'll be dead before you know it.

Reply 33 of 83, by PC-Engineer

User metadata
Rank Member
Rank
Member

I understand your issues with your graphics card. Does this problem persists even with the clock at 33MHz? Will test my other two VLB cards the next days and their behavior in transparent mode. Do you can run Second Reality with your Mach64 in transparent mode?

I have the older version of 2840VL, which doesn't have the Jumper (J5) populated, but intended on PCB. I soldered a little bridge, but with no effect. Maybe there are other components in the corresponding circuit. Within the next days i expect another VLB SCSI controller (SP-360, no idea which manufacturer and which driver i need, will see what the SCSI BIOS says) and with luck the newer version of the 2840 ... Will report here as soon i have new information.

feipoa wrote:

Seems like we are never really finished.

Please tell my wife this. 🤣

Epox 7KXA Slot A / Athlon 950MHz / Voodoo 5 5500 / PowerVR / 512 MB / AWE32 / SCSI - Windows 98SE

Reply 34 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++
PC-Engineer wrote:

I understand your issues with your graphics card. Does this problem persists even with the clock at 33MHz? Will test my other two VLB cards the next days and their behavior in transparent mode. Do you can run Second Reality with your Mach64 in transparent mode?

It has been many years since I assembled and tested my 486 VLB system for the most optimal hardware conditions, so I don't recall with certainty, but I think it was due to the 40 MHz. Since my LCD monitors on my two office desks are native at 1280x1024, I want a VLB graphics card which has 4 MB so it can output at 16-bit colour. Thus, I use the S3 968 in place. I have not tried the Second Reality demo, but I have downloaded it just now. Does it make use of floating point operations? Will it generate any benchmark stats?

PC-Engineer wrote:
feipoa wrote:

Seems like we are never really finished.

Please tell my wife this. :lol:

Actually, the less they know the better!

GigAHerZ wrote:

In there, there is a register 72, bits 2 and 1. Both should be set to 1. For my bios, modbin showed, it was 1 and 0. I changed it to 11. Next, for good measure because of the note, i also changed register 50 bit 3 to 1.

Any chance you have tried this on the motherboard mentioned in this thread? Could the "auto" L1 mode override what you input for these registers in MODBIN? If so,then I can see the appeal of the software solution in DOS, but that won't help when using NT. If I have time, I might try the sis.exe file that another user posted.

Plan your life wisely, you'll be dead before you know it.

Reply 35 of 83, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote:
GigAHerZ wrote:

In there, there is a register 72, bits 2 and 1. Both should be set to 1. For my bios, modbin showed, it was 1 and 0. I changed it to 11. Next, for good measure because of the note, i also changed register 50 bit 3 to 1.

Any chance you have tried this on the motherboard mentioned in this thread? Could the "auto" L1 mode override what you input for these registers in MODBIN? If so,then I can see the appeal of the software solution in DOS, but that won't help when using NT. If I have time, I might try the sis.exe file that another user posted.

I only have my own Soyo board, but it's based on Sis471 chipset like the board here, so i would suggest the possibilities are the same.

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 36 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++

GigAHerZ, did your BIOS also have just these two options for L2: AUTO and WRITE BACK? Btw, I've pulled my system out of the closet and have it setup now.

Plan your life wisely, you'll be dead before you know it.

Reply 37 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I ran SIS.EXE on my Asus VL/I-486SV2GX4, but nothing happens. I just see a blinking cursor with no way to exit except for hitting the reset button. The same thing happened when I tried to run CTCHIP34 sis471.cfg, which has never happened to me before.

I can confirm that there is a noticeable speed drop in Speedsys when using the WRITE-BACK L2 feature in the BIOS. Speedsys records the changes as:

L2: WT --------------------> WB (broken)
L1: 140.66----------------->141.67 MB/s
L2: 57.61------------------->61.60 MB/s
RAM: 47.41----------------->37.73 MB/s

The L2 results improve, but the main memory speed takes a drive.

Plan your life wisely, you'll be dead before you know it.

Reply 38 of 83, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie

@feipoa, it has an option to set L2 into WT or WB mode in addition to just enable/disable L2 cache.

After running the sis.exe, does any benchmark show any change?

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 39 of 83, by feipoa

User metadata
Rank l33t++
Rank
l33t++
feipoa wrote:

I ran SIS.EXE on my Asus VL/I-486SV2GX4, but nothing happens. I just see a blinking cursor with no way to exit except for hitting the reset button. The same thing happened when I tried to run CTCHIP34 sis471.cfg, which has never happened to me before.

I cannot run anything after running sis.exe

Plan your life wisely, you'll be dead before you know it.