OK, I implemented that change via modbin into the bios, and verified with my DOS tool that dumps the registers for this board (which I will post here as well). Register changed as expected.

Benchmark scores before and after are attached. I only ran one test so far, but definite improvement. Not sure if this is consistent with what you have experienced.

Yes, that drop from 78 us/KB to 35 us /KB comes from switching from always dirty to 7+1

Attached is the modified BIOS in the event anyone else needs it. This is the 4/27/94 BIOS with the one small tweak from 0 to 1 on register 72 to properly set L2 dirty tag. Thanks @jakethompson1 for the idea!

It took me a little while to locate modbin, so here it is on the Internet Archive. I used 4.50.80 for this change.
https://web.archive.org/web/20090206020432/ht … om/download.php

sweet bump, how does it translate to benchmarks/doom scores? Im failing terribly finding benchmarks in that dirty bit thread 🙁

I'm not yet on to testing with apps.

On the CPU side, I have the POD83, two Am5x86 133s (including an ADZ chip that should be overclockable), and a Cyrix 5x86-100GP so I need to finish testing and figure out which one will be the best option.

I also have disk testing, as I have the Adaptec 2842A and the Buslogic BT-445S to try out with my ZuluScsi. And I just picked up a Promise EIDE2300 Plus (per the recommendation on this forum) to try with CF cards.

My video card is currently a Diamond Stealth64 Graphics 2000 (Vision 868 VLB) with 1MB. I do have an additional 1MB of memory but it didn't detect it, so I have another few memory chips on order.

Once I get it fully dialed in with hardware I will post some benchmarks for doom, etc.

OK, here goes the first post about disk access.

This has been via my Gigabyte GA-486VF / SiS 85C471 system with an AMD Am5x86-P75, with a comparison between a BusLogic BT-445S and an Adaptec AHA-2842A.

System/config used for both cards:

• Motherboard: Gigabyte GA-486VF
• Chipset: SiS 85C471
• CPU: AMD Am5x86-133 P75
• CPU speed: ~133 MHz, 4x multiplier, ~33.2 MHz bus
• RAM: 64 MB (it has 128 installed, DOS can only use 64)
• Video: Diamond Stealth64 Graphics 2000 / S3 Vision868 VLB, currently detected as 1 MB
• Storage device: ZuluSCSI Blaster, rev 2025f, recent firmware (I updated it sometime in April 2026 - I didn't note the specific version)
• SANDISK 128GB Extreme PRO SD UHS-I Card
• DOS: MS-DOS 6.22
• BIOS: Award Modular BIOS v4.50G, modified with MODBIN
• SiS register 72h changed in the Award chipset defaults from X0000010 to X0000110, so the L2 dirty/tag behavior is set during POST

BIOS/chipset settings:

• Turbo: ON
• Cache Burst Read: 0W
• Cache Write Cycle: 0W
• Latch Local Bus: T2
• External cache: Write Back
• Internal cache BIOS setting: Write Back
• System Shadow: Cached
• Video Shadow: Cached

Adaptec AHA-2842A setup:

• Adaptec AHA-2842A VLB, BIOS version 2.0 (unmodified - ie not patched for int13 support)
• Adaptec write-back jumper enabled on the card itself
• Everything else identical to the BusLogic test

Adaptec results:

• SpeedSys CPU score: 47.80
• SpeedSys memory bandwidth: 74.39 MB/s
• SpeedSys L1 data cache: 73.34 MB/s
• SpeedSys L2 data cache: 42.10 MB/s
• SpeedSys memory throughput: 24.25 MB/s
• SpeedSys VESA/video throughput: about 13420 KB/s
• SpeedSys hard drive score: 193.38
• SpeedSys buffered read: about 5189-5190 KB/s
• SpeedSys linear verify: about 3146 KB/s
• SpeedSys linear read: about 2423-2429 KB/s

DiskTest 2.3, Adaptec:

• Write speed: 3385.12 KB/s
• Read speed: 4137.37 KB/s
• 8K random, 70% read: 145.5 IOPS
• Sector random read: 180.3 IOPS
• Average access time: 6 ms

BusLogic BT-445S setup:

• BusLogic BT-445S VLB, BIOS version 4.72
• Everything else identical to the Adaptec test

BusLogic SpeedSys results:

• SpeedSys CPU score: 47.80
• SpeedSys memory bandwidth: 74.39 MB/s
• SpeedSys L1 data cache: 73.34 MB/s
• SpeedSys L2 data cache: 42.10-42.19 MB/s
• SpeedSys memory throughput: 24.25 MB/s
• SpeedSys VESA/video throughput: about 13419-13421 KB/s
• SpeedSys hard drive score: 215.38-218.82

BusLogic SpeedSys HDD details:

• Average / max seek: about 4.02 / 4.04-4.08 ms
• Random seek: 4.11 ms
• Track-to-track seek: 3.81 ms
• Random access time: about 5.26-5.32 ms
• Buffered read: about 4924-5065 KB/s
• Linear verify: about 3270-3305 KB/s
• Linear read: about 1976-2140 KB/s

DiskTest 2.3, BusLogic:

• Write speed: 3250.79 KB/s
• Read speed: 2748.99-2864.34 KB/s
• 8K random, 70% read: 141.4 IOPS
• Sector random read: 186.9 IOPS
• Average access time: 5 ms

Quick comparison:

• CPU/cache/memory results are effectively identical between the two cards, which is good since the only intended variable was the SCSI card.
• The BusLogic has the higher SpeedSys composite hard-drive score: about 218.82 vs 193.38 for the Adaptec.
• The Adaptec does better in DiskTest sequential read: about 4137 KB/s vs 2750-2864 KB/s for the BusLogic.
• The Adaptec is also slightly ahead in DiskTest write: 3385 KB/s vs 3251 KB/s.
• The BusLogic is slightly better in DiskTest sector random read: 186.9 IOPS vs 180.3 IOPS.
• The BusLogic also shows a slightly better average access time in DiskTest: 5 ms vs 6 ms.

I’m not sure I’d call either card the absolute winner yet. The Adaptec looks better in DiskTest sequential throughput, especially reads, while the BusLogic scores better in SpeedSys’s overall HDD score and a couple of smaller/random metrics.

Next step will be to test with a Promise EIDE 2300 Plus with a 4GB industrial CF card.

So I spent a ton of time dealing with what seemed like random memory corruption. I suspected the external cache chips after much testing, and spent hours researching every 1990s-era tool to check and test cache. Cachechk, ctcm, cct386, speedsys, etc. Windows 95 was intermittently failing to load or process the registry. So I pulled the 4 chips (512kb) of cache and went to 8 chips (256kb). Same results. Then I went to 4 chips (128kb) and it worked - no issues!

It was after this point - many hours into the process - where the software-first brain in my head was looking for more ways to test cache chips. Even thinking of writing a program to do it. When I finally realized, HMM I wonder if this very nice TL866 eeprom programmer sitting next to me might have the ability to test chips. In what many on this forum would recognize as a blinding glimpse of the obvious - why yes it can test chips! So I popped them in one at a time and found one chip in the 512kb arrangement was bad, and 2 chips in the 256kb arrangement were bad. I just lucked out that the 4 I selected for 128kb were all good chips or I'd still be here pulling what remains of my hair out.

Oh, and the bus jumper had come off so instead of 33MHz it was 40MHz. Also not super helpful.

Long story long, I'll retest and post actual results when the new cache chips arrive. In the meantime if someone is having problems with their SRAM cache chips in the future - don't overlook your eeprom programmer! My actual SRAM chips were not listed as options in MiniPro but a different vendor with the same package worked fine.

IE instead of selecting my chip:
IS61C1024-15N = 128K × 8 SRAM = 1 Mbit

I used:
W24010 = 128K × 8 SRAM = 1 Mbit

Under 5 minutes to test all of them.

Ah, we should have pointed that out. Especially with the IS61C1024 chips, if they're from ebay, they're about 10% defective, almost as if wherever they came from, they were pulled off the production line before going through the testing stage.

rjbrown99 wrote on 2026-06-08, 01:57:

So I spent a ton of time dealing with what seemed like random memory corruption. I suspected the external cache chips after much […]
Show full quote

So I spent a ton of time dealing with what seemed like random memory corruption. I suspected the external cache chips after much testing, and spent hours researching every 1990s-era tool to check and test cache. Cachechk, ctcm, cct386, speedsys, etc. Windows 95 was intermittently failing to load or process the registry. So I pulled the 4 chips (512kb) of cache and went to 8 chips (256kb). Same results. Then I went to 4 chips (128kb) and it worked - no issues!

It was after this point - many hours into the process - where the software-first brain in my head was looking for more ways to test cache chips. Even thinking of writing a program to do it. When I finally realized, HMM I wonder if this very nice TL866 eeprom programmer sitting next to me might have the ability to test chips. In what many on this forum would recognize as a blinding glimpse of the obvious - why yes it can test chips! So I popped them in one at a time and found one chip in the 512kb arrangement was bad, and 2 chips in the 256kb arrangement were bad. I just lucked out that the 4 I selected for 128kb were all good chips or I'd still be here pulling what remains of my hair out.

Oh, and the bus jumper had come off so instead of 33MHz it was 40MHz. Also not super helpful.

Long story long, I'll retest and post actual results when the new cache chips arrive. In the meantime if someone is having problems with their SRAM cache chips in the future - don't overlook your eeprom programmer! My actual SRAM chips were not listed as options in MiniPro but a different vendor with the same package worked fine.

IE instead of selecting my chip:
IS61C1024-15N = 128K × 8 SRAM = 1 Mbit

I used:
W24010 = 128K × 8 SRAM = 1 Mbit

Under 5 minutes to test all of them.

Sometimes it depends on BIOS cache settings - my original W24512AK-15 and non-original IC61C1024-15N both stable with some settings and randomly craches with other

OK I have some additional details to share around testing and an open question I'm aiming to answer, but first here's the end-to-end documentation of my hardware platform and some of what I have tried so far.

Hardware / Test Platform

Motherboard

• Gigabyte GA-486VF Rev. 6
• Chipset: SiS 85C471
• BIOS: Award Modular BIOS v4.50G, dated 04/27/94
• BIOS has been edited with MODBIN only to expose additional setup-menu options. No underlying register patches are currently being used, and the previous write-back register change is not active.
• 3x VESA Local Bus slots:
  • VESA1: Adaptec AHA-2842A
  • VESA2: Diamond Stealth64 VLB
  • VESA3: empty

Memory

• 64MB RAM, installed entirely in bank 0, using 60ns 30-pin SIMMs (I have an extra 64mb but removed it so the external cache covers it all.)

External Cache

• 512KB external L2 cache
• Data SRAM:
  • 4x ISSI IS61C1024-15N
  • 128Kx8, DIP-32, 15ns
• TAG SRAM:
  • W24257AK-12
  • 32Kx8, DIP-28, 12ns

Video

• Diamond Stealth64 VLB
• S3 Vision868 chipset
• 2MB video memory
• Installed in VESA2

Storage / I/O

• Adaptec AHA-2842A VLB SCSI controller
  • Installed in VESA1
  • Also provides the floppy controller
• ZuluSCSI Blaster Rev. 2025f

Additional Hardware Available

• BusLogic BT-445S VLB SCSI controller
• Promise EIDE2300 Plus VLB IDE controller

CPUs Tested

• AMD Am5x86-P75 / Am486 DX5-133V16BGC (with large heatsink + Noctua fan on top)
• AMD Am5x86-P75 / AMD-X5-133ADZ (with large heatsink + Noctua fan on top)
• Intel Pentium OverDrive POD83 / P24T

CPU Tests to Date

Three Socket 3 CPUs have been tested so far. Both AMD Am5x86-P75 parts, the Am486 DX5-133V16BGC and the AMD-X5-133ADZ, work correctly at the stock 33MHz bus / 4x multiplier configuration, for 133MHz operation.

When attempting 40MHz bus / 4x multiplier operation, the DX5-133V16BGC fails to run Windows reliably. The X5-133ADZ gets farther and will boot into Windows 95, but still shows instability under load and during file-copy testing.

The Intel Pentium OverDrive POD83 / P24T also POSTs in this board, but only boots with its internal cache disabled. With the POD83 internal cache enabled, the system fails to boot from the Adaptec-controlled hard disk or floppy path. It throws a disk error as if the hard drive wasn't there (even though the SCSI banner shows and detects the disk.)

Important BIOS / Cache Stability Finding

At 33MHz with external cache enabled, setting Cache Burst Read to 0W caused immediate Windows 95 registry/disk-corruption-type symptoms. Returning Cache Burst Read to 1W made the 512KB cache configuration stable.

This was true across testing and was critical to getting the system reliable even at the normal 33MHz bus / 133MHz CPU configuration.

Current Question: Can the ADZ Run Reliably at 40MHz FSB?

I have mostly given up on the POD83 for now. After hours of changing jumper and BIOS settings one at a time, I admit defeat there. At this point I am focused on trying to get a modest overclock of the ADZ working at 40MHz bus / 4x multiplier, for an effective 160MHz CPU clock.

The ADZ appears to be the better candidate of the two AMD 5x86 chips. It boots farther than the DX5-133V16BGC at 160MHz and has reached the Windows 95 desktop, but it is not yet stable. I have seen hangs, blue screens, and file-copy instability under Windows 95, although I did get one successful SpeedSys result.

The challenge is determining whether the instability is caused by the CPU itself at 160MHz, the GA-486VF / SiS 471 chipset at 40MHz bus, the 30-pin SIMM memory subsystem, the 512KB external cache path, or the VLB I/O path with the Adaptec AHA-2842A.

So far, disabling the external cache did not make the 40MHz configuration stable, which suggests the 512KB L2 cache is probably not the only limiting factor. That leaves the CPU core at stock voltage, the 40MHz VLB environment, DRAM/chipset timing, or the Adaptec VLB controller path as the remaining suspects.

I don't think it will help much, but I also have 10ns SRAM chips and a 10ns TAG SRAM chip on order. But right now my 15ns chips paired with a 12ns TAG should be more than OK.

Happy to take questions or input, otherwise I'm going to keep testing and will report back when I have more.

How where the memory speed scores with the original cache setup? I know it was a smaller cache, but it was spread in 2 banks. Isn't bank interleave a thing on this board?

H3nrik V! wrote on 2026-06-30, 07:58:

How where the memory speed scores with the original cache setup? I know it was a smaller cache, but it was spread in 2 banks. Isn't bank interleave a thing on this board?

Good question, I had to do a bit of reading on it - found this article which describes interleave in more detail.

This board supports the following two cache options that are most relevant:
256 KB of SRAM cache, with 32 KB x 8 data SRAM with 16 / 32 KB x 8 tag SRAM (using all 8 chips + TAG)
512 KB of SRAM cache, with 128 KB x 8 data SRAM with 32 KB x 8 tag SRAM (using 4 chips + TAG)

I don't have 8 working chips to try the 256kb 8 chip exercise, and when I had it slimmed down to 128kb it was with only 4 chips. It did seem marginally faster in speedsys.

My biggest current question/issue is how to get the AMD 5x86 stable at above 133MHz. Are you suggesting that moving to a 256kb SRAM cache setup across 8 chips (assuming that it uses interleaving) would help?

I found this thread which had a great idea - run the bus at 40MHz and the CPU at 120MHz to see if there are any issues with VLB at the higher bus rate. I tried this and the system was entirely stable at 3x40 / 120MHz with external cache enabled. I ran my test script that copies and checks integrity of the CAB files multiple times (to test IO/writes/CPU), rebooted to DOS, ran speedsys a few times, and it all works well. So as of now I suspect it may be less of an issue with VLB or the cards, moreso that this particular CPU is struggling with the 4x40 / 160MHz setting. I have another ADZ CPU on order that I will try when it arrives.

In the meantime I have also obtained:
SRAM: ISSI IS61C1024-10N (4 chips = 512kb)
TAG: ISSI IS61C256AH-10N

That's in the system now and working so this is about as fast as I think we can reasonably find for SRAM+TAG chips. It didn't change any benchmarks, but at least I think this mostly eliminates external cache speed from causing a problem. More tests to come to try to hit 4x40/160.

I suspect the Pentium OverDrive issues are related to pinout differences between the 486 P24D and the Pentium OverDrive. HITM and other pins are moved from the 486 area to the new outer row of pins on the OverDrive. If your board doesn't have these all wired correctly, it might be impossible to get working no matter what you do with jumpers, but fixable with a soldering iron and wire.

I've often had to boost the voltage slightly to get 160 MHz operation to work. The voltage regulator's target voltage is controlled by a few resistors (check the datasheet). By soldering another resistor in series with the existing one, you can reduce the resistance and boost the output voltage. Use a multimeter with no CPU installed to check. If you go to 3.6 V, it will probably work, and that is still in-spec at the high end of tolerance range for the Am5x86.

Yeah I'm more or less out on the POD at this point, not sure what else I can do. I tried damn near every combination of jumpers and relaxed BIOS settings I could come up with but alas no internal cache. There are later revisions of this board that might have solved for this issue.

Thanks for the suggestion re voltage, I'll go search around for more info on how to do that. I had previously found a bunch of data on interposers and I was going to investigate that path. But maybe it isn't such a big solder job to add a resistor and that could be a better solution.

I'm not particularly skilled at soldering, although I did manage to replace the battery on this board with a coin cell adapter and also added a new keyboard adapter (as the old one was almost hanging off when I started).

OK, so I attached a photo below with what I believe is the voltage regulator - a Linear Technology LT1085CT. The datasheet is here. Full disclosure - I asked ChatGPT for some help in figuring out which resistor might be the correct one. Here was its suggestion, so I could use a gut check if this is correct/accurate or not.

Planned LT1085CT Voltage-Regulator Investigation

The board appears to use an LT1085CT adjustable regulator near the CPU socket. Before modifying anything, I want to identify the existing feedback divider and measure the actual CPU core voltage.

According to the LT1085CT datasheet, looking at the regulator from the front with the text facing you and the pins pointing downward:

1Pin 1 = ADJ
2Pin 2 = VOUT
3Pin 3 = VIN
4Tab   = VOUT

So the metal tab of the regulator should be a convenient place to measure regulator output / CPU Vcore.

Step 1: Measure Current Vcore

With the board still configured for the normal 3.3V / 3.45V CPU setting:

1Black multimeter probe: motherboard / PSU ground
2Red multimeter probe: LT1085CT metal tab
3CPU installed
4System powered on

This should tell us what the CPU is actually receiving now. If it is around 3.3V, the first target might be closer to 3.45V. If it is already around 3.45V, then a small increase to roughly 3.55V-3.60V may be the next test.

I am not going to use the motherboard's 5V CPU setting for this.

Step 2: Identify the Feedback Resistors

With the system powered off and unplugged, I plan to use the multimeter in continuity / ohms mode to trace the resistors around the LT1085CT.

The LT1085 adjustable regulator normally uses a feedback divider like this:

1VOUT ---- R1 ---- ADJ ---- R2 ---- Ground

The approximate formula is:

1Vout = 1.25 * (1 + R2/R1)

Where:

1R1 = resistor from VOUT to ADJ
2R2 = resistor from ADJ to ground

So the goal is to identify which nearby SMD resistor connects between VOUT and ADJ, and which one connects between ADJ and ground.

Step 3: How I Plan to Find Them

With power off:

• Put one meter probe on LT1085 pin 1, the ADJ pin.
• Probe nearby SMD resistors around the regulator.
• Find the resistor that has continuity from one side to ADJ and the other side to VOUT / tab.
• Find the resistor that has continuity from one side to ADJ and the other side to ground.
• Record the resistor markings and measured resistance values.

Once those two resistors are identified, we can calculate the existing Vcore setting and determine the least invasive way to slightly raise it.

My understanding is that to raise Vout on this regulator, we would either increase the ADJ-to-ground resistance or decrease the VOUT-to-ADJ resistance. So I want to confirm the actual resistor network before soldering anything.

For clarity, I said in series earlier but mean in parallel. It could be as simple as soldering a plain (axial) resistor with trimmed leads between two pins of that LT1085.

Thanks, I found a guide to changing the voltage here, which is helpful. I'm currently thinking that I am more likely to damage my board than to get a replacement resistor in there. I'll read up about it some more and determine which is the correct resistor before coming to a final conclusion.

The other path I found was the 486socketblaster, which sounds like it would do exactly what I want - variable voltage regulation. But that's an even bigger pain to build and there are no premade options available.

feipoa is much better at that kind of soldering than me. I'm not saying to do any SMD resistor modification, rather, to add another resistor in parallel to lower the resistance. That can either be soldering one to two pins of the voltage regulator (you should put the longer leg of the resistor in heat-shrink), or even easier, you can solder a normal axial resistor on the underside of the motherboard once you identify the correct pins. That makes it easy to undo and try another value after checking the resulting voltage.

OK, below is my summary of what I worked out in terms of how to address this. Let me know if you see anything meaningfully wrong - but TL;DR I'm going to try soldering a 12k resistor to the bottom of the board across ADJ/VOUT. This may result in roughly ~3.55V.

Planned LT1085CT Vcore Mod

I measured the current CPU core voltage at the LT1085CT regulator tab. With the board set for its normal 3.3V / 3.45V CPU setting and the AMD-X5-133ADZ installed, Vcore measures:

1Idle:  ~3.437V
2Load:  ~3.438V during TESTCAB / SpeedSys

So the regulator appears stable under load, with essentially no voltage droop.

The LT1085CT pinout is:

1Pin 1 = ADJ
2Pin 2 = VOUT
3Pin 3 = VIN
4Tab   = VOUT

I traced/measured the feedback divider as follows:

1R1, VOUT -> ADJ:    ~617 ohms
2R2, ADJ  -> Ground: ~1.049k ohms

The 1.049k resistor is the blue SMD resistor marked 1051. One side connects directly to LT1085 pin 1 / ADJ, and the other side goes to ground.

The plan is to slightly reduce R1 by adding another resistor in parallel between VOUT and ADJ. Rather than trying to solder directly to the small SMD resistor on the top side, I plan to solder on the underside of the board across the LT1085 pins:

1Add resistor between LT1085 pin 1 and pin 2
2ADJ <-> VOUT
3Do not connect to pin 3 / VIN

Before soldering, I will confirm the underside pads with a multimeter:

• Find the underside pad with continuity to LT1085 pin 1 / ADJ.
• Find the underside pad with continuity to LT1085 pin 2 / VOUT or the LT1085 tab.
• Avoid the pad with continuity to LT1085 pin 3 / VIN.

I ordered 1% metal-film through-hole resistors and will start with a conservative value.

Planned test ladder:

1No mod: ~3.438V measured
215k across ADJ/VOUT: expected roughly ~3.52V-3.53V
312k across ADJ/VOUT: expected roughly ~3.55V
410k across ADJ/VOUT: expected roughly ~3.57V
58.2k across ADJ/VOUT: expected roughly ~3.60V

Initial plan is to start with 15k, measure Vcore, and only move lower if needed.

After adding the resistor:

• Power on and measure Vcore at the LT1085 tab before doing any stability testing.
• If the voltage is much above 3.60V, shut down and remove/change the resistor.
• If the voltage is sane, test 4x40 / 160MHz stability again with the AMD-X5-133ADZ.

The goal is not to use the motherboard's 5V CPU setting. The goal is only a small Vcore bump from the current ~3.44V range toward roughly 3.55V-3.60V to see whether the ADZ becomes stable at 160MHz.