OK. sis.exe only works on my system if L2 is set to AUTO. If I set L2 to WRITE-BACK, sis.exe causes the system to hang up. Speedsys now shows improvement with the 7+1 dirty tag ram strategy. I will past it again here:

L2: WT --------------------> WB (broken) --------------------> WB (working - sis.exe)
L1: 140.66-----------------> 141.67 MB/s ---------------------> 141.67 MB/s
L2: 57.61-------------------> 61.60 MB/s ---------------------->61.62 MB/s
RAM: 47.41-----------------> 37.73 MB/s ---------------------> 46.73 MB/s

So, there is an inconsequential increase in L1 speed, an modest increase in L2 speed, and an inconsequential decrease in RAM speed. All when compared to L2:WT mode. In DOOM, the working L2:WB resulted in 1293 realtics, while for L2:WT, it is 1295 realtics. 2 realtics difference translates to 0.1 fps extra for the working L2:WB mode. 57.76 fps vs. 57.68 fps. This is why, when you have working L1:WB cache that there is little incentive to use L2 cache in write-back mode as well.

Perhaps bakemono could make an NT4 driver for this function? If one is to modify the registers on the motherboard's BIOS, then how will we get the L2 cache back into WT mode without having to reflash the BIOS? Because it looks like we are trying to override the AUTO mode rather than the write-back mode. Is this analysis correct? Or is there a way to modify the write-back mode option for these register edits?

@feipoa, on my board, after i have modified bios, i can still enable/disable L2 cache and set the mode to WT or WB. Everything still works.

Changed bits only change the behaviour of how exactly the WB mode of L2 works.

So we are assuming that "AUTO" on the Asus boards is synonymous with "WT". I will edit my BIOS using MODBIN in the coming days to see what happens.

EDIT: ANother question, were you able to run sis.exe when your BIOS was setup to L2:WB? On my board, sis.exe only works with L2 is set to AUTO.

@feipoa, i don't remember, if i tried this sis.exe or not. By that time, i had my own solution working 100% and kinda lost interest in alternative approaches. I was happy to find a tool called modbin and being able to "fix" the bios by using the datasheet and that tool.

@feiopa and GigAHerZ
Thank you both for the elaboration of setting the correct bit in the chipset for dirty tag. So it seems there is no need to disassemble my dirty tag anymore to test the sis.exe 😀
Keeps this bit saved in BIOS configuration after reboot (soft- and hard-)?

feipoa wrote:

...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

The Mach64 has a feature, i think it is called "packed Pixel". This Card supports with 4MB at 1280x1024 24bpp (60Hz). The only other VLB cards with such a feature are these with Weitek P9100.

The Second Reality Demo was mentioned for 386, and doesn't need a FPU. It also has no benchmark function.

feipoa wrote:

Actually, the less they know the better!

Nice to see that I'm not alone 😀

PC-Engineer wrote:

Keeps this bit saved in BIOS configuration after reboot (soft- and hard-)?

For the Asus board? I don't know yet. I hope so. I'm not sure what the "AUTO" option does for L2 cache and hope it doesn't reset the chipset registers. I'll see if I can find time to modify the BIOS for this motherboard and try it.

What I'd be most interested to learn is if the TAG RAM hack method is the same thing as setting 7+1, or if it will allow us to cache 256 MB of memory in Write-Back mode on other motherboards which have 1024K cache?

PC-Engineer wrote:

The Mach64 has a feature, i think it is called "packed Pixel". This Card supports with 4MB at 1280x1024 24bpp (60Hz)

There's a 4 MB VLB Mach64? I assume it is 2 MB with an expansion socket for another 2 MB. I have the expansion socket, but not the right Mach64 VLB card. I've seem Mach64 cards which have the solder pads for the memory expansion header, but not have the header.

I have attached an image from MODBIN for register's 72h and 50h. I've also enclosed an image of the wording in the SiS 471 preliminary.

Register 50 is X'ed out and cannot be altered. I am guessing that this is controlled by the BIOS option of "AUTO" or "WRITE BACK", in which AUTO = write through. The question I have is concerning the statement in the SiS manual. I have written it in the image, but will write it again. It uses an "if" condition but did not provide an "else". Is register 72 ignored if Register 50 is set to WRITE THROUGH? If it is, that is great. If it isn't, then I'm wondering if the board will get stuck in 7+1 mode. Normally on 486 boards, you use 7+1 for L2:WB and 8+0 for LT:WT. In the past, I recall stability issues if this condition is not met, e.g. there was a combination I tested that didn't work well, and I don't recall if it was 7+1 with L2:WT or 8+0 with WB (or both).

I've set register 72 bits 1&2 to 1&1 and will try this out. Hopefully uniflash can handle this otherwise I need to take the system apart due to the EEPROM's location.

EDIT: Doesn't seem like any of the aweflash.exe versions (tried as low as 3 and as high as 7.95), uniflash, or nssi have the ability to write an AWARD 4.51G BIOS on a SiS 471-based motherboard. The oldest chipset uniflash supports is SiS 496, probably due to PCI.

OK, I have changed only register 72 bits 1&2. They were at 0,0, and I changed them to 1,1. No change to register 50 is needed as this is set by the BIOS for WT or WB. Changing between L2:WB and L2:WT seems to work fine because I beleive if Register 50 is set to write-though (or AUTO in the case of the 486SV2GX4), that Register 72 is ignored.

I'm attaching the modified BIOS for this board. It is a modification of the latest BIOS version SV2G4021. I called the new BIOS SV2G4fix.bin

I ran some benchmarks. Quake shareware v1.06 (not Phil's) jumpsts from 17.6 in L2:WT mode to 18.8 L2:WB. DOOM results jumped from 1295 realtics to 1980 realtics. I'm not sure why yesterday using sis.exe for fixing L2:WB showed it as only 1293. With the BIOS modificaion, the fix also works in NT operating systems. If you are only running DOS, Win3.1x, or Win9x, running the sis.exe file is probably sufficient.

Also, using CPUMark99 is very sensitive to L2 cache speed changes. It scored 6.7 in L2:WT mode and 6.81 in L2:WB mode.

If you are wanting to use this BIOS mode, I have tested both of these EEPROMs in this system: Winbond W27C512-45Z and W27E512-12.

EDIT: Second Reality runs fine. Wish they'd have used a timedemo in this, especially with an FPU option. I could really use some FPU benchmarks which target 386 systems.

1280x1024 is a pretty shitty mode to run if you're going to be using a CRT, because the aspect ratio will be squashed vertically. The correct resolution for a 4:3 CRT should be 1280x960, which is possible on some cards, but don't know about the Mach64. I'm not sure why 1280x1024 was ever pushed as a standard resolution in the first place. Anyway, if you run it on an LCD that uses that as the native resolution then it's no problem at all.

The Mach64 cards without the expansion header are the "WinTurbo" cards. They're the cost reduced versions.

I thought I mentioned lcd on this page or the previous. I don’t own any crt’s anymore. Good riddance.

But without a tube you don't get a proper retro experience. I like ones that are 15-17" from the mid 90s. They had some memory and digital adjustment, but still had good quality control. After that they got too big and heavy, and corners were cut.

@feipoa
I decided to open my computer and disassemble it - the curiosity was just too big. 😉
I took your BIOS and changed the cache to 256kB (8x 32k8 + 32k8 tag).

• 1. I measured with my BIOS with L2 WT and L2 WB (without dirty) - no HW hack
  2. Changed the BIOS to yours and measured with L2 WB (dirty / 7+1) - dirty was ok
  3. Changed BIOS back to mine and did the HW hack with L2 (dirty / 8+0) - dirty was ok

Results

• a) your BIOS with dirty and the HW hack with dirty deliver the same results
  b) your BIOS supports 32MB cacheable area, the HW hack with my BIOS supports 64MB cachable area (both with 256kB cache)- so it should be possible to cache with 8+0 and HW-dirty 256MB RAM with 1024kB! But not with this Board 😉
  c) the negative effect of the missing dirty bit is with 256kB cache in DOS much higher, than with 1024kB - tested with 16MB RAM

Additional i tested with the transparent mode with: Mach32 (2MB VRAM), V7 Mercury S3 928 (2MB VRAM) and the STB Lightspeed ET4000 W32p (2MB DRAM). Seems that the Miro is the only one which has a problem in Second Reality in transparent mode.

And i tested the AMD 5x86 @160MHz with L1WB / L2WB and the Miro SD in transparent mode. I have no issues with SCSI and with benchmarking, but with Second Realtity (in an earlier sequence than with the POD). In VL sync. mode are no problems with Second Reality observable.

I will post the results/values tomorrow - now i have to go to bed ...

This is interesting! So the TAG RAM piggyback hack with L2:1024k allows us to use direct-mapped L2:WB and cache all 256 MB of RAM on boards/chipsets which support this much RAM, just not this board unfortunately.

The MB-8433UUD works with 256 MB of memory, and can be hacked to support 1024K, Re: The World's Fastest 486 , however it uses the UM8881 chipset and we don't have the pinouts.

I also have a SiS 496 board setup with a cx5x86-133. It has native 1024K, but the BIOS doesn't work with 64 MB sticks. So I use 128 MB of RAM, but have found that L2:WT was either more stable or faster than L2:WB, and this board has the 7+1 BIOS option. I should check to ensure that the register is set properly.

For datasheet availability, we may be limited to the SiS 496/497. I have a few others with 1024K, but don't recall if they work with 64 MB sticks. The Zita Tomato 4DPS board (based on SiS 496) has a BIOS which supports 64 MB sticks, but this board is single-banked only for cache.

I think on some chipsets it's possible the dirty bit is integrated. I think the Acer chipsets would be more likely to have this feature. Does anyone remember off hand?

I know certain ALI chipsets from Pentium era used internal tag space which was sometimes combined with an external tag chip.

It was a bit more complicated as there is no dirty tag per se in Pentium (instead there are MESI bits). In different revisions of the chip it was more or less broken which lead to some crazy low cacheable limits.

There is a nice page documenting quirks of various chipsets. But it is Pentium+

http://www.pchardwarelinks.com/chipsets_pentium.htm

Last week i was grounded by the family, but better late than never ...

Here are the results with 256kB cache

As you can remember the results with 1024kB cache

This is a completely different picture dependent on cache size, in qualitative comparison.

Some of my conclusions:

• The BIOS from feipoa adds successful the missing dirty tag bit
• The BIOS fix (7+1) and the HW-fix (8+0) deliver the same performance
• The effect of missing dirty tag is as higher as smaller the cache size is
• The effect of missing dirty tag is as higher as more RAM usage the program has
• Both caches (L1 and L2) in write through or L1:WT and L2:WB (without dirty bit) are the slowest configurations
• For nearly top performance make sure that at least one cache is configured as write back
• If your MB doesn't support a dirty bit, then switch to wrtite through or fix it!
• The P24T takes a huge (appr. 5%) profit from L1 WB in contrast to the 486 CPUs (Am5x86, AMD SV8B, intel DX4 WB, P24D)
• If one bit of tag is used for dirty bit (7+1), the cacheable area is halved in contrast to write through mode or write back with seperate dirty tag (8+0)
• With 7+1 the 256kB cache can support 32MB RAM in WB mode, with 8+0 the 256kB cache can support 64MB RAM in WB mode

... so take care of the dirty bit ...

Since I had already taken apart the computer anyway, i tested the SV2GX4 as a VLB-High-End-Board with the Socket3-High-End-CPUs. 😀

System:

• Board: ASUS SV2GX4 - 1024kB cache (WB, dirty ok)
  RAM: 2x 8MB FPM 60ns
  Graphics: Miro Crystal 20SD 2MB (S3 864)
  HDD: Seagate ST32122A (IDE) an Prime 2 ISA Controller
  OS: MS-DOS 6.22
  TSR: HIMEM.SYS, UNIVBE5.1, 5x86.exe (for Cyrix M1sc only)

CPUs:

• intel P24T (Pentium Overdrive, POD5V83)
  intel 486 DX4 100 (SK096)
  intel DX2 66MHz (SZ878)
  AMD Am5x86 P75 (16BGC)
  AMD 486 DX4 100 (SV8B)
  Cyrix 5x86 GP100 (M1sc, BTB_EN=ON, LSSER=OFF, MEM_BYP=ON, FP_FAST=ON)

BIOS (402 11/03/95):

And here are the results (edited):

My conclusions:

• The fastest 486 is the Am5x86, but it doesn't scale as well with the clock like the P24T, the Cyrix and the intel DX4
• The Am5x86 gets only a small increase in Doom from 133 to 160MHz in transparent mode - not so in synchronize mode seems to be a problem with clock
• The P24T overrules all other CPUs in this board except Doom - but it is no 486!
• The typical 486 (Am5x86) needs more than 160% of the clock of the Pentium (P24T) to beat it in an infrastructure which was optimized for 486
• The intel DX4 is much more efficient per clock, than the AMD 486
• The 486 CPUs doesn't take profit out of L1:WB (with L2:WB) like the Pentium does
• The P24T with L1:WB cannot used with SCSI in the board, all other tested CPUs have no problems with it in L1:WB
• Would be interested of a Cyrix 5x86 GP133 in this board with this configuration
• The AMD DX4 is a disappointment for me
• I love this Mainboard! 😁

In addition to my previous experiences in this threat i found a solution with VL in transparent mode with this graphics card. I switsched the jumper on the Miro 20SD to the other prosition. Now i can run "Second Reality" without any problem (and all other programs too). Don't know about the function of this jumper, but is has zero! influence to the benchmark results.

edit: found the root cause that the Am5x86 performed bad in Doom with 160MHz: Had to set Jumper 26 from ND (no delay) to D (delay), but got two (not reproducable) freezes while benchmarking with that config in transparent mode. In synchronize mode i had no issues regardless the jumper possition.

Nice concise summary of results there.

It was interesting to see how the POD100 was only 3% faster than the AMD X5-160 in DOOM, but 55% faster in Quake.

So all 486 chips work with SCSI VLB when the WB jumper is set? Or you didn't have to set the WB jumper on the SCSI card for the system to work properly?

In heavily graphic applications, the Cyrix 5x86-120 is slightly faster than the Cyrix 5x86-133 due to the faster VLB bus speeds. With more CPU intensive applications, the cx5x86-133 is faster. You can view these results in this thread: Voodoo 1 vs. Voodoo 2 on a 486 I benchmarked more than a dozen Windows games.

Very interesting result of finding the magic jumper on your Micro 20SD card. Did you happen to benchmark the Micro 20SD in transparent vs. synchronise mode to see how much difference there was? I'd be curious to know this information for these test resuts.

It would be a good idea to normalise the data because the overall scores (the length of the summed up bar) does not award even weight to each game/benchmark. This is very evident when comparing the Cx5x86-120 Mhz to the Am5x86-160. In this circumstance, the Am5x86 beats the Cx5x86 in DOOM, Quake, PCPBench, and PCPbench, but because the synthetic score of the Speedsys result favours the Cyrix cx5x86 by 7.86 fps, the total lengh of the bar for cx5x86 comes out ahead of the Am5x86. This is a deviation of reality because the bar chart is taking a sum of the 5 results and plotting that length on a chart. If each benchmark game had an equally weighed score, that would be OK, but that is not the case.

The issue arrises because small frame-rate changes, e.g. in pcpbench the Am5x86 scores only 1.3 fps more than the cx5x86, are actually large percent changes, which is 10.7% in this case. Now take a look at DOOM. The Am5x86 scores 1.5 fps more than the cx5x86, but this 1.5 fps is only a 2.7%.. So when making a bar chart that just takes the sum of whatever the results are, you giving more weight to the DOOM result compared to the PCPBench (640x480x8) result, when in fact the PCPBench result should be weighed 4x more.

I recall Phill's benchmark chart and spreadsheet doing this unfair weighing of the games/benchmarks and it always troubled me. In the cast of your latest chart, would you be able to normalise the data for each game/benchark to that of the P24T-100/L1-WB. The results will all be decimals, but I usually then multiply all results by 100 to look more pleasing to the eye. With this method, each game/benchmark has an equal contribution to the final result or tally. If you view the Ultimate 486 Benchmark Comparison, you can see this being done in the charts and data tables.

Seems, that my diagram suggest a ranking. It is difficult to reed between the lines. The intention was to list the absolute results for direct compairison of individual values from other users.
I am not a fan of synthetic results like NU or Speedsys too, but many users ask for the results, so i listed it ...

Ok, now a real ranking - Only for this four DOS Benches and this mainbord.

CPU scaling via overclocking: 33MHz - 40MHz FSB (+20%)
intel DX2: +19,5%
intel P24T: +19,5%
intel DX4: +19,4%
Cyrix 5x86: +19,2%
AMD Am5x86: +18,5% (edit)
AMD DX4: +16,6%

edit:
The Am5x86 @160MHz runs in a anomaly with JP26 position in ND (no delay) and VL transparent mode - Doom takes only an increase from 55,5 (@133MHz) to 57,5 FPS (@160MHz). In general the Am5x86 need 160MHz to be appr. equal with the POD @100MHz closely followed by the intel DX4 @120MHz. And additionaly the high clock causes hardware anomalies with this board and this graphics card.
Anyway, the Am5x86 keeps the fastest available, original 486 - overclocked @160MHz

edit:
My Opinion: If i would make a real fast, original 486 with overclocking, i would take the intel DX4, because there is clock sensitive SW and HW (e.g. the Terratec Maestro 32/96 Rev.1). The Am5x86 @160MHz is in Doom and Quake 20% faster than the intel @120MHz and in PCPBench are both equall. But i think the intel DX4 is in general more compatible than the Am5x86 @160MHz. And i like CPUs which are more efficient clock for clock.

feipoa wrote:

So all 486 chips work with SCSI VLB when the WB jumper is set? Or you didn't have to set the WB jumper on the SCSI card for the system to work properly?

I got a 2842A and and replaced the 2842VL. The Jumper of the 2842A was allways set. Do you have any indication that the jumper has a negative influence?

feipoa wrote:

In heavily graphic applications, the Cyrix 5x86-120 is slightly faster than the Cyrix 5x86-133 due to the faster VLB bus speeds. With more CPU intensive applications, the cx5x86-133 is faster. You can view these results in this thread: viewtopic.php?t=61639 I benchmarked more than a dozen Windows games.

I would be interested in the scaling. The 133GP has a quad multiplier, the 100GP has a tripple multiplier and scales near maximum. How the 133GP scales between 25MHz FSB and 33MHz FSB. This would maybe give an indication for the reason why the Am5x86 scales weak.

feipoa wrote:

Very interesting result of finding the magic jumper on your Micro 20SD card. Did you happen to benchmark the Micro 20SD in transparent vs. synchronise mode to see how much difference there was? I'd be curious to know this information for these test resuts

I thought this would be a wait-state jumper, but without a performance drop (only measured in transparent mode) by toggeling. I beleave it must have another function (interrupt?). Couldn't found a hint for it until now. And no, i didn't consider the synchronize mode in the comparison. Do you have an expection?

feipoa wrote:

The issue arrises because small frame-rate changes, e.g. in pcpbench the Am5x86 scores only 1.3 fps more than the cx5x86, are actually large percent changes, which is 10.7% in this case. Now take a look at DOOM. The Am5x86 scores 1.5 fps more than the cx5x86, but this 1.5 fps is only a 2.7%.. So when making a bar chart that just takes the sum of whatever the results are, you giving more weight to the DOOM result compared to the PCPBench (640x480x8) result, when in fact the PCPBench result should be weighed 4x more.

I know what you want to say 😀 The selection of the tests alone already leads to a weighting. This is a fact that AMD and INTEL have been arguing about for ages. So we have the only option to perform as many different (Application-) benchmarks as possible and don't take average values over the tests. So that any user can find his own conclusion.

My diagrams suggests a ranking, that is really unfavorable. Maybe i find a better way to visualize the values for a comarison.

feipoa wrote:

If you view the Ultimate 486 Benchmark Comparison, you can see this being done in the charts and data tables.

I love your benchmark tables. Mostly i look to the absolute values to compare with my results to check that i am on the right way. You've done a great job helping the retro community with these benchmarks. Many thanks from my side!