Hi tauro,

I don't know what the hardware differences are, between the v1.2 and v1. 3 boards.

But looking at an archived copy of Soyo's website, I see they specified the rev EH-1DA1 BIOS for all 5EH v1. 0, v1. 1, v1. 2, and v1. 3 boards. The EH-1DA2 BIOS however is only indicated for the v1. 3 board.

https://web.archive.org/web/20020613235131/ht … d586=5EH&bios=1

I think the EH-1DA2 BIOS will work on the other board versions as well, but was simply never validated by Soyo. If you have an EEPROM programmer, you can try to validate this yourself. 😉

Cheers, Jan

Hey Jan!

Thanks for that link, it's very enlightening.

So 1DA1 should be the latest BIOS for v1.2 according to SOYO themselves.

I tried it and after some basic testing I noticed some instabilities (Write fault error reading C) that I hadn't noticed with the original 1CA2 BIOS. Also, that BIOS includes in its name "5EH V1.2", instead of "5EH Family", as the 1DA1 does.

So I decided to go back to the original 1CA2 BIOS, but now I notice that my dump has a different checksum from the archived rom.
Here are both, my original dump and the archived rom. Maybe mine got corrupted?

Chkcpu wrote on 2025-05-27, 15:08:

I think the EH-1DA2 BIOS will work on the other board versions as well, but was simply never validated by Soyo. If you have an EEPROM programmer, you can try to validate this yourself. 😉

I briefly tried the 1DA2 (the one advertised as being only for the v1.3) on the v1.2 and it apparently worked fine.

It would be very interesting to try all three BIOSes and see if there are performance differences, benefits/problems. Can you think of any tests to find out which one is better or rather to find the possible incompatibilities/bugs?

I have the suspicion, call it a hunch, that the 1CA2 is the better choice for this motherboard.

Also, how can I set my L2 cache to WT? I can't find the option and I'm using 128 MB on a 512KB L2 motherboard.

tauro wrote on 2025-05-27, 17:10:

Hey Jan! […]
Show full quote

Hey Jan!

Thanks for that link, it's very enlightening.

So 1DA1 should be the latest BIOS for v1.2 according to SOYO themselves.

I tried it and after some basic testing I noticed some instabilities (Write fault error reading C) that I hadn't noticed with the original 1CA2 BIOS. Also, that BIOS includes in its name "5EH V1.2", instead of "5EH Family", as the 1DA1 does.

So I decided to go back to the original 1CA2 BIOS, but now I notice that my dump has a different checksum from the archived rom.
Here are both, my original dump and the archived rom. Maybe mine got corrupted?

The attachment 5EHM.v1.2.BIOS.1CA2.original.dump.BIN.7z is no longer available

The attachment 5eh1ca2.bin.7z is no longer available

Chkcpu wrote on 2025-05-27, 15:08:

I think the EH-1DA2 BIOS will work on the other board versions as well, but was simply never validated by Soyo. If you have an EEPROM programmer, you can try to validate this yourself. 😉

I briefly tried the 1DA2 (the one advertised as being only for the v1.3) on the v1.2 and it apparently worked fine.

It would be very interesting to try all three BIOSes and see if there are performance differences, benefits/problems. Can you think of any tests to find out which one is better or rather to find the possible incompatibilities/bugs?

I have the suspicion, call it a hunch, that the 1CA2 is the better choice for this motherboard.

Also, how can I set my L2 cache to WT? I can't find the option and I'm using 128 MB on a 512KB L2 motherboard.

Hey tauro,

I’m away from home this week and only took my phone along. So I have no means to examine you BIOS dumps, but will do that next week when I’m back home.

However, a changed checksum on you own 1CA2 backup is not unusual because the BIOS uses a small section of the EEPROM to store it’s PnP data. This so called ESCD block is usually located at offset 1D000h on a 128KB BIOS.
When downloading an archived BIOS this 4KB ESCD block contains PnP data from another board, or is just empty and filled with FFh bytes.

So chances are good your own backup is fine.
Can you do a binary file compare between these two BIOSes and tell us the outcome?

Greetings, Jan

Chkcpu wrote on 2025-05-28, 19:59:

So chances are good your own backup is fine.
Can you do a binary file compare between these two BIOSes and tell us the outcome?

Greetings, Jan

Nowadays I use a hexeditor with file compare function for that, but the file compare tool from DOS works equally well. Use the DOS comnand:

FC /B BIOS1.BIN BIOS2.BIN > DIFF. TXT

This command will cause a byte for byte compare between the two files and sends it’s output to a textfile.
If you post this DIFF.TXT here, I can tell you if these BIOSes are okay.

Cheers, Jan

Hi tauro,

I just got home and took a quick peek into your SY-5EHM BIOSes.
The two 1CA2 versions you put in your last reply are different BIOSes and can’t be compared with a File Compare tool. So disregard my previous message.

Your own 5EHM V1.2 original dump is a 10/21/1999-VP3-586B-8669-2A5LES2AC-00 BIOS with an 5EH V1.2-1CA2 sign-on message.
When comparing this BIOS with the download from https://theretroweb.com/motherboards/s/soyo-s … 5-1-2-mvp3#bios I find that they are identical. So your own 5EH BIOS backup has no corruption and is valid, and can safely be flashed back on your board.

The other 5EH1CA2.BIN from the archive is a slightly older 08/03/1999-VP3-586B-8669-2A5LES2AC-00 BIOS with an EH-1CA2 sign-on.
This BIOS appears to be for another board revision and I found an identical copy at https://theretroweb.com/motherboards/s/soyo-sy-5eh5-1-1#bios
So this 1CA2 BIOS is for the Rev 1.1 board.

It's very confusing that Soyo used the same 1CA2 BIOS version number for non-identical BIOSes for different board revisions.
When I have more time, I will look into these 5EHM BIOSes more closely, and I will look for a possible L2 cache WT mode setting as well.

Greetings, Jan

Hi there, thanks to this thread I found the way to flash through AWD816.exe flasher my motherboard.

I have a Soyo 5EHM v.1.3 and I successfully flashed the 5EH1DA1.bin bios (05-06-2000), updating from my old EH131AA1.bin file that was from 29-02-2000.

I had problem with a bad version of flasher and I bricked my card, but I remember how to make a blind flash and I re-saved my motherboard that I just repaired from a smoked 3,3v. regulator transistor.

Now I hope it will recognize my AMD K6-3+ processor!

What a difficults moments when you flash a bios and it gone wrong!

Thanks to you that I found the old FTP Soyo site where they told to use AWD816.exe flasher!

Unfortunately the bios from June 2000 doesnt' recognize correctly the AMD K6-3+ I have. I think I will have to update to the latest version from november 2000. the eh131da2.bin file is the last.

biessea wrote on 2025-07-07, 17:35:

Unfortunately the bios from June 2000 doesnt' recognize correctly the AMD K6-3+ I have. I think I will have to update to the latest version from november 2000. the eh131da2.bin file is the last.

Hi biessea,

The Soyo 5EHM BIOS version are very confusing. For your v1.3 board, Soyo indicates BIOS revision 1DA2 as latest and for earlier board versions the BIOS 1DA1 is the latest.

However, when I compare the 1DA1 and 1DA2 BIOSes, they are identical! Only the sign-on message in the 1DA2 BIOS is changed to indicate it is for the v1.3 board only!!??
Both BIOS versions also have the same 05/16/2000-VP3-586B-8669-2A5LES2AC-00 BIOS-ID.

I’ve also checked both 1DA1 and 1DA2 BIOS and they both have full K6-2+/III+ support.
So you can stay on the 1DA1 BIOS or flash the 1DA2 version, it makes no difference.

Note that a K6-III+ will be indicated as an AMD K6(tm)-III CPU. This is true for all Award BIOSes with native K6-2+/K6-III+ support and this is according a directive from AMD.
Only patched BIOSes indicate a K6-III+ as a K6-III+ 😉
So if you see AMD K6-III when running a K6-III+, you know that the BIOS fully supports your K6-III+!

Cheers, Jan

Chkcpu wrote on 2025-07-07, 20:04:

Hi biessea, […]
Show full quote

biessea wrote on 2025-07-07, 17:35:

Unfortunately the bios from June 2000 doesnt' recognize correctly the AMD K6-3+ I have. I think I will have to update to the latest version from november 2000. the eh131da2.bin file is the last.

Hi biessea,

The Soyo 5EHM BIOS version are very confusing. For your v1.3 board, Soyo indicates BIOS revision 1DA2 as latest and for earlier board versions the BIOS 1DA1 is the latest.

However, when I compare the 1DA1 and 1DA2 BIOSes, they are identical! Only the sign-on message in the 1DA2 BIOS is changed to indicate it is for the v1.3 board only!!??
Both BIOS versions also have the same 05/16/2000-VP3-586B-8669-2A5LES2AC-00 BIOS-ID.

I’ve also checked both 1DA1 and 1DA2 BIOS and they both have full K6-2+/III+ support.
So you can stay on the 1DA1 BIOS or flash the 1DA2 version, it makes no difference.

Note that a K6-III+ will be indicated as an AMD K6(tm)-III CPU. This is true for all Award BIOSes with native K6-2+/K6-III+ support and this is according a directive from AMD.
Only patched BIOSes indicate a K6-III+ as a K6-III+ 😉
So if you see AMD K6-III when running a K6-III+, you know that the BIOS fully supports your K6-III+!

Cheers, Jan

Thank you a lot!

Now it's more clear.

Probably I just wanted to boot my k6-iii+ 400 that I have directly at 600mhz and it doesn't work. It's strange cause on a Shuttle 591p it booted and worked at 600mhz with 2,0v.

O don't know what to say, so i Don't need the last bios of November 2000 that in FTP version of Soyo site is indicated?

biessea wrote on 2025-07-07, 20:23:

Chkcpu wrote on 2025-07-07, 20:04:

Hi biessea, […]
Show full quote

biessea wrote on 2025-07-07, 17:35:

Unfortunately the bios from June 2000 doesnt' recognize correctly the AMD K6-3+ I have. I think I will have to update to the latest version from november 2000. the eh131da2.bin file is the last.

Hi biessea,

The Soyo 5EHM BIOS version are very confusing. For your v1.3 board, Soyo indicates BIOS revision 1DA2 as latest and for earlier board versions the BIOS 1DA1 is the latest.

However, when I compare the 1DA1 and 1DA2 BIOSes, they are identical! Only the sign-on message in the 1DA2 BIOS is changed to indicate it is for the v1.3 board only!!??
Both BIOS versions also have the same 05/16/2000-VP3-586B-8669-2A5LES2AC-00 BIOS-ID.

I’ve also checked both 1DA1 and 1DA2 BIOS and they both have full K6-2+/III+ support.
So you can stay on the 1DA1 BIOS or flash the 1DA2 version, it makes no difference.

Note that a K6-III+ will be indicated as an AMD K6(tm)-III CPU. This is true for all Award BIOSes with native K6-2+/K6-III+ support and this is according a directive from AMD.
Only patched BIOSes indicate a K6-III+ as a K6-III+ 😉
So if you see AMD K6-III when running a K6-III+, you know that the BIOS fully supports your K6-III+!

Cheers, Jan

I don't know what to say, so i Don't need the last bios of November 2000 that in FTP version of Soyo site is indicated?

Okay, I see your confusion about these SY-5EH BIOS release dates.
On the archived Soyo website
https://web.archive.org/web/20020613235131/ht … d586=5EH&bios=1
they indicate the 1DA1 BIOS was released on 06/05/2000 and the 1DA2 on 11/16/2000. These are just publication dates.

The build date of these identical BIOSes however, is the same 05/16/2000. This date is also shown at the bottom line of the BIOS POST screen.
So there is no later 5EH BIOS than this May 2000 revision.

I you like to have the correct sign-on message for your v1.3 board, you can flash the 1DA2 BIOS. But the functionality is the same as with the 1DA1 revision.

Ciao, Jan

Hello Jan,

Thank you for taking the time to go through these bioses and compare them.
I'm sorry that I wasn't able to answer earlier. Serious issues came up.

Finally, I've been doing some tests with these motherboards.

Chkcpu wrote on 2025-07-07, 20:04:

The Soyo 5EHM BIOS version are very confusing. For your v1.3 board, Soyo indicates BIOS revision 1DA2 as latest and for earlier board versions the BIOS 1DA1 is the latest.

SOYO is indeed very confusing.
It might be me, but I think theretroweb is confusing too.
According to it, there are two 5EH5 v1.2, one with the VP3 chipset, and another one with the MVP3 chipset. The VP3 chipset isn't supposed to support a 100MHz bus, or is it?

Maybe the BIOS with the EH-1CA2 message is suitable for the v1.2 with the VP3 chipset and the EH5-1CA2 is for the one with the MVP3 chipset?

Could you find any significant differences between 1CA2 (for v1.2), 1DA1 (for ALL apparently) and 1DA2 ("for v1.3 only")? any low-level stuff?

By chance I discovered that XP doesn't boot with the 1CA2 BIOS (7B error). It only boots with the 1DA1/1DA2 bioses. So there must be some difference.

Chkcpu wrote on 2025-07-08, 08:42:

I you like to have the correct sign-on message for your v1.3 board, you can flash the 1DA2 BIOS. But the functionality is the same as with the 1DA1 revision.

Is the sign-on message the only difference between 1DA1 and 1DA2? Apparently they both work fine on the v1.2 revision.

About the cache, it appears that it always runs in Write Through mode, though I don't know how to confirm this, or to change its mode.

With 128MB SDRAM (cache is 512KB):
CTCM v1.6n detects L2 as Write Back, with no noncacheable areas
CTCM v1.7a detects L2 as Write Through, with no noncacheable areas

Since there are no non-cacheable areas, I suppose CTCM v1.7a is correct and it's working in WT mode.
I thought, maybe the BIOS sets it in WT or WB mode according to the amount of RAM installed?
Both versions of CTCM give the same conflicting reports with 64MB installed, so I think it's always working in WT mode.
Is there any way to find the answer?

biessea wrote on 2025-07-07, 17:35:

Unfortunately the bios from June 2000 doesnt' recognize correctly the AMD K6-3+ I have.

I can confirm that the K6-2+ posts and boots DOS on v1.2 with the 1CA2, 1DA1, 1DA2 BIOSes.
But will a K6-III/+ work with 1DA1/1DA2?

tauro wrote on 2025-07-08, 09:21:

With 128MB SDRAM (cache is 512KB): CTCM v1.6n detects L2 as Write Back, with no noncacheable areas CTCM v1.7a detects L2 as Writ […]
Show full quote

With 128MB SDRAM (cache is 512KB):
CTCM v1.6n detects L2 as Write Back, with no noncacheable areas
CTCM v1.7a detects L2 as Write Through, with no noncacheable areas

Since there are no non-cacheable areas, I suppose CTCM v1.7a is correct and it's working in WT mode.

The CTCM guess for WB/WT mode is wrong all too often, as is the "dirty tag" indication. On the other hand, you the standard memory timing table has a quite good indication for cache mode. The last three lines (IIRC miss+clean, miss+dirty and just misses or something like that) usually show exactly the same bandwith in WT mainbaords, two different bandwidths in WB/always dirty and three different bandwiths in proper WB mode.

tauro wrote on 2025-07-08, 09:21:

SOYO is indeed very confusing. It might be me, but I think theretroweb is confusing too. According to it, there are two 5EH5 v1. […]
Show full quote

SOYO is indeed very confusing.
It might be me, but I think theretroweb is confusing too.
According to it, there are two 5EH5 v1.2, one with the VP3 chipset, and another one with the MVP3 chipset. The VP3 chipset isn't supposed to support a 100MHz bus, or is it?

Maybe the BIOS with the EH-1CA2 message is suitable for the v1.2 with the VP3 chipset and the EH5-1CA2 is for the one with the MVP3 chipset?

Oh boy, more confusion. 😉
You are right about TRW indicating the MVP3 chipset only for the 5EH v1.3 board and the VP3 for the other 5EH board versions. I hadn’t noticed that and this is incorrect of course! I will send them a message to correct this.
The SY-5EH is a Super Socket 7 board with 100MHz FSB support, as clearly indicated in the boards manual, and all variations of this board have the VIA MVP3, or the renamed ETEQ equivalent, chipset fitted!
This means also that there is only one v1.2 board. Not one with the VP3 and another with MVP3 chipset…

Also the VP3 indication in the BIOS-ID string of this MVP3 board doesn’t help. I see this in the Award BIOS of a lot of MVP3 boards. Because the VP3 and MVP3 are very similar, it looks like Award used the VP3 chipset module for their MVP3 BIOSes and only adjusted this for the added 95/100MHz support of the MVP3. But I’m just speculating here. 😉

This misunderstanding is further aggravated by VIA itself, by allowing the MVP3 northbridge to report itself as a VP3 northbridge, while still maintaining all its MVP3 functions. I found this on my Tyan S1590 board where a system information tool and Win98 device manager reported a VP3 chipset while this board definitely has the MVP3 fitted.
When I disassembled its BIOS, I found that the BIOS programmed an undocumented MVP3 chipset register that handles this spoofing. I don’t know why this was done, maybe to improved compatibility with older Oses like Win95.
More details about this Device-ID override function can be found below.

So even when a system information tool reports a VP3, it still can be an MVP3 board!!

mkarcher wrote on 2025-07-08, 19:32:

tauro wrote on 2025-07-08, 09:21:

With 128MB SDRAM (cache is 512KB): CTCM v1.6n detects L2 as Write Back, with no noncacheable areas CTCM v1.7a detects L2 as Writ […]
Show full quote

With 128MB SDRAM (cache is 512KB):
CTCM v1.6n detects L2 as Write Back, with no noncacheable areas
CTCM v1.7a detects L2 as Write Through, with no noncacheable areas

Since there are no non-cacheable areas, I suppose CTCM v1.7a is correct and it's working in WT mode.

The CTCM guess for WB/WT mode is wrong all too often, as is the "dirty tag" indication. On the other hand, you the standard memory timing table has a quite good indication for cache mode. The last three lines (IIRC miss+clean, miss+dirty and just misses or something like that) usually show exactly the same bandwith in WT mainbaords, two different bandwidths in WB/always dirty and three different bandwiths in proper WB mode.

mkarcher, thanks for educating us about the limitations of the CTCM tool.
Perhaps another fine tool from c’t Magazine can help us detect the true L2 cache chipset programming: CTCHIP.
Some time ago I wrote a VT598MVP.CFG file for CTCHIP. Here is a copy:

In the zip-file, I’ve included the CTCHIPZ.EXE program and the Ctchipz.doc documentation.
The CTCHIPZ.EXE is the later v3.7 of this program, that has a fix for the infamous Runtime error 200 bug on faster CPUs.
Note that I’ve also included two CFG files to control the Southbridge registers, a VT571.CFG file for IDE Device control and a VT572.CFG to control the PM device. We don’t need these CFG’s here, but I added them just in case.

@tauro,
Boot to DOS, and in the directory where you unzipped the files, type this command:
CTCHIPZ VT598MVP /50
to check what the configuration register 50h bits show about the L2 cache settings.

With the command:
CTCHIPZ VT598MVP /51
you can also check if the detected L2 cache size is correct. The SY-5EH5 board has 512KB and the 5EHM sports 1MB of L2 cache.

About the Device-ID override function, the VT598MVP.CFG also has these registers defined. When you type the command:
CTCHIPZ VT598MVP /0FC
CTCHIP will show you if this function is enabled (bit 0 of registers FCh-FDh).
If so, hitting the Enter key will display the next registers FEh-FFh where the Device-ID word of this replace function is stored. When the override is Enabled, this word will be reported by the Device-ID register 02h-03h, instead of the default 0598h of the MVP3 northbridge.

Here is an example of an MVP3 system where this override is Enabled, and the 0597h Device-ID of the VP3 is reported instead.

I can confirm that the K6-2+ posts and boots DOS on v1.2 with the 1CA2, 1DA1, 1DA2 BIOSes.
But will a K6-III/+ work with 1DA1/1DA2?

Yes, a K6-III+ is fully supported by the 1DA1/1DA2 BIOS as well. The K6-2+ and K6-III+ are both Model 13, as reported by CPUID, and are, apart from their different L2 cache size, completely similar. The only (cosmetic) issue is that the K6-III+ is displayed as a K6-III.

Cheers, Jan

mkarcher wrote on 2025-07-08, 19:32:

The CTCM guess for WB/WT mode is wrong all too often, as is the "dirty tag" indication. On the other hand, you the standard memory timing table has a quite good indication for cache mode. The last three lines (IIRC miss+clean, miss+dirty and just misses or something like that) usually show exactly the same bandwith in WT mainbaords, two different bandwidths in WB/always dirty and three different bandwiths in proper WB mode.

With CTCM v1.7a (reports L2 as WT) there's definitely three similar values in the lines L2 clean, L2 dirty and misses (~314µs).
With CTCM v1.6n, as far as can I see all the values are quite similar. Maybe the fact that it doesn't measure MMX and blocktransfer speeds somehow confuses the program?

Chkcpu wrote on 2025-07-09, 09:51:

Oh boy, more confusion. 😉 You are right about TRW indicating the MVP3 chipset only for the 5EH v1.3 board and the VP3 for the ot […]
Show full quote

Oh boy, more confusion. 😉
You are right about TRW indicating the MVP3 chipset only for the 5EH v1.3 board and the VP3 for the other 5EH board versions. I hadn’t noticed that and this is incorrect of course! I will send them a message to correct this.
The SY-5EH is a Super Socket 7 board with 100MHz FSB support, as clearly indicated in the boards manual, and all variations of this board have the VIA MVP3, or the renamed ETEQ equivalent, chipset fitted!
This means also that there is only one v1.2 board. Not one with the VP3 and another with MVP3 chipset…

Also the VP3 indication in the BIOS-ID string of this MVP3 board doesn’t help. I see this in the Award BIOS of a lot of MVP3 boards. Because the VP3 and MVP3 are very similar, it looks like Award used the VP3 chipset module for their MVP3 BIOSes and only adjusted this for the added 95/100MHz support of the MVP3. But I’m just speculating here. 😉

This misunderstanding is further aggravated by VIA itself, by allowing the MVP3 northbridge to report itself as a VP3 northbridge, while still maintaining all its MVP3 functions. I found this on my Tyan S1590 board where a system information tool and Win98 device manager reported a VP3 chipset while this board definitely has the MVP3 fitted.
When I disassembled its BIOS, I found that the BIOS programmed an undocumented MVP3 chipset register that handles this spoofing. I don’t know why this was done, maybe to improved compatibility with older Oses like Win95.
More details about this Device-ID override function can be found below.

So even when a system information tool reports a VP3, it still can be an MVP3 board!!

Amazing! After all, VIA was the one that started the confusion.
UMBPCI also reports the chipset as being VP3. I suppose MPV3 and VP3 mean the same for UMBPCI's internal operation, but still...

Chkcpu wrote on 2025-07-09, 09:51:

In the zip-file, I’ve included the CTCHIPZ.EXE program and the Ctchipz.doc documentation.
The CTCHIPZ.EXE is the later v3.7 of this program, that has a fix for the infamous Runtime error 200 bug on faster CPUs.
Note that I’ve also included two CFG files to control the Southbridge registers, a VT571.CFG file for IDE Device control and a VT572.CFG to control the PM device. We don’t need these CFG’s here, but I added them just in case.

Excellent program. The veil is finally removed...

As you said, 0FC shows "Override enabled", so that confirms that its reporting itself as a VP3.

50h shows that L2 is operating in Write-Through mode, as we suspected.

51h reports the correct L2 cache size (512KB)

Is there a possibility to change L2 operation to WriteBack? I wonder if it is possible to do it once the machine has been powered on, otherwise, how could it be done?
I'm considering using a K6-2+ on this build, does L2 WB make more sense than L2 WT?

Finally Jan, I need your advice to set the rules in stone: Should v1.2 boards use the 1DA1 or 1DA2 BIOS version? Could you find any difference or is it only the sign-on message?

You really know your stuff. Thanks for taking the time to answer and share your knowledge in such a didactic way, I really appreciate it.

tauro wrote on 2025-07-14, 03:48:

With CTCM v1.7a (reports L2 as WT) there's definitely three similar values in the lines L2 clean, L2 dirty and misses (~314µs).
With CTCM v1.6n, as far as can I see all the values are quite similar. Maybe the fact that it doesn't measure MMX and blocktransfer speeds somehow confuses the program?

The 16K MOVSD performance with the value around 310μs repeated three times is a sure indicator for WT. That's a very reliable measurement if CTCM got the L1 cache size correct. In this case, 16K L1 data cache is correct, so that table is trustworthy.

The output of CTCM above that table is likely generated from specific microbenchmarks for every aspect. My impression is that these microbenchmarks include some assumptions that do not hold on all systems. Given the wide variety of 386..Pentium IV systems that you might run CTCM on, it's not surprising that the author couldn't verify whether all assumptions for performing those microbenchmarks and evaluating the results are true on every system in every configuration.

The "for your info, here are additional timings using FPU or MMX" is a new feature of CTCM 1.7. Every measurement type has a list of "associated types" that get measured as well. I don't think these measurements (as they only replicate the "misses" line) are related to the displayed system architecture in any way. Furthermore, the "associated measurements" code is buggy. Each measurement type has a minimum CPU requirement listed. For MOVSD, it's 386, for FPU it's 386+387, for MMX it's Pentium MMX. Before performing the associated measurememt, CTCM checks that the system is compliant with the requirements ... of the original measurement type. So in default MOVSD mode, CTCM always measured MOVSD, and then, if the system is capable of running the MOVSD benchmark, it will run the FPU benchmark, and finally, if the system is capable of running the MOVSD benchmark, it will run the MMX benchmark. This will break on MMX-less systems for obvious reasons, but you can skip the associated measurements using the /NOP command line switch, which I generally use, especially on 486 computers.

mkarcher wrote on 2025-07-14, 06:34:

The 16K MOVSD performance with the value around 310μs repeated three times is a sure indicator for WT. That's a very reliable measurement if CTCM got the L1 cache size correct. In this case, 16K L1 data cache is correct, so that table is trustworthy.

The output of CTCM above that table is likely generated from specific microbenchmarks for every aspect. My impression is that these microbenchmarks include some assumptions that do not hold on all systems. Given the wide variety of 386..Pentium IV systems that you might run CTCM on, it's not surprising that the author couldn't verify whether all assumptions for performing those microbenchmarks and evaluating the results are true on every system in every configuration.

The "for your info, here are additional timings using FPU or MMX" is a new feature of CTCM 1.7. Every measurement type has a list of "associated types" that get measured as well. I don't think these measurements (as they only replicate the "misses" line) are related to the displayed system architecture in any way. Furthermore, the "associated measurements" code is buggy. Each measurement type has a minimum CPU requirement listed. For MOVSD, it's 386, for FPU it's 386+387, for MMX it's Pentium MMX. Before performing the associated measurememt, CTCM checks that the system is compliant with the requirements ... of the original measurement type. So in default MOVSD mode, CTCM always measured MOVSD, and then, if the system is capable of running the MOVSD benchmark, it will run the FPU benchmark, and finally, if the system is capable of running the MOVSD benchmark, it will run the MMX benchmark. This will break on MMX-less systems for obvious reasons, but you can skip the associated measurements using the /NOP command line switch, which I generally use, especially on 486 computers.

That's quite interesting, and I tend to agree with you about CTCM not considering every use case, and all the processors out there.
It's probably mainly centered on ATs through early Pentiums.
I remember having these kinds of problems in the past with CTCM giving false reports, and that's why I keep two versions. I don't remember the motherboard or the circumstances though... 👴

mkarcher wrote on 2025-07-14, 06:34:

This will break on MMX-less systems for obvious reasons, but you can skip the associated measurements using the /NOP command line switch, which I generally use, especially on 486 computers.

I didn't know about the /NOP switch, I'll give it a try in the future. Thanks!

tauro wrote on 2025-07-14, 04:06:

As you said, 0FC shows "Override enabled", so that confirms that its reporting itself as a VP3.

To get a definitive confirmation of a true MVP3 board, you can disabled this Device ID override with the command:

CTCHIPZ VT598MVP /0FC:=0

And then check the real Device ID with:

CTCHIPZ VT598MVP /2

A value of 0598h will confirm that the MVP3 Northbridge is present.

50h shows that L2 is operating in Write-Through mode, as we suspected.

Is there a possibility to change L2 operation to WriteBack? I wonder if it is possible to do it once the machine has been powered on, otherwise, how could it be done?
I'm considering using a K6-2+ on this build, does L2 WB make more sense than L2 WT?

My Tyan S1590 board with 1MB L2 cache shows L2 Write-Through as well.

Using CTCHIPZ.EXE it is possible to change L2 to Write-Back. This would involve writing a Macro with a several commands (Disable cache, Flush cache, Change Tag to 7+1, Enable WB, Enable cache), so the change can be executed by letting CTCHIPZ run the Macro.

But running L2 in WB will half the cacheable range. In your case with 512KB L2 cache, it will reduce from 128MB to 64MB. This would actually reduce performance with 128MB RAM, which I consider the sweet-spot for Win98 on SS7 systems.
However, this is irrelevant with the K6-2+/III(+) with on-die L2 cache. The now L3 motherboard cache will add very little to the performance and any performance difference between the external cache in WT or WB will not be noticeable.

If you still want to experiment with this, I can help with writing a “L2WB” Macro for CTCHIPZ. This will take some time though as I need to experiment to find what works, without crashing the system. 😉

Finally Jan, I need your advice to set the rules in stone: Should v1.2 boards use the 1DA1 or 1DA2 BIOS version? Could you find any difference or is it only the sign-on message?

I’ve checked the 1DA1 and 1DA2 BIOSes by decompressing all modules from each BIOS and performing a binary compare with my hexeditor on each module.
They really are identical, apart from the sign-on message in the main system module (original.tmp).
So it doesn’t make any difference which of these BIOSes you use. Just pick the one with the sign-on message you like for your board revision. 😀

Jan

Chkcpu wrote on 2025-07-16, 10:06:

If you still want to experiment with this, I can help with writing a “L2WB” Macro for CTCHIPZ. This will take some time though as I need to experiment to find what works, without crashing the system. 😉

The CTCHIPZ version I used some time ago had a bug in its "load memory block" routine, affecting large cache sizes. The standard method to initialize an "always valid" cache is to read a memory block of twice the L2 size (+L1 size, if you don't disable L1 during that time), and CTCHIPZ has a macro-callable function to run REP LODSD (or something like that) for this purpose. In cache the load amount doesn't fit the conventional memory (it doesn't for 1MB or 2MB blocks), it uses a different method that loads extended memory, but there is an arithmetic error: CTCHIPZ will load 1KB or 2KB instead of 1MB or 2MB in that case. Somewhere I likely still have a patched CTCHIPZ around that fixes this bug. I'm gonna hunt for it if you are interested.