have you tried the patched BIOS from here

http://www.steunebrink.info/k6plus.htm

Scroll down to the patched BIOS section and grab the bios from there, its been patched to support K6 3+ CPUs and K6 2+ CPUs.

The issue as you have discovered is that the K6 2/3+ CPUs are too new for the stock BIOS and it needed to be patched to fix it.

Hopefully this soles your problems !

Edit - Just noticed you have ... if your VRM is having issues then you may need to do a bit of component testing to see if the VRM capacitors and other components are still in spec.

Trashbytes wrote on 2025-04-30, 05:01:

have you tried the patched BIOS from here […]
Show full quote

have you tried the patched BIOS from here

http://www.steunebrink.info/k6plus.htm

Scroll down to the patched BIOS section and grab the bios from there, its been patched to support K6 3+ CPUs and K6 2+ CPUs.

The issue as you have discovered is that the K6 2/3+ CPUs are too new for the stock BIOS and it needed to be patched to fix it.

Hopefully this soles your problems !

Edit - Just noticed you have ... if your VRM is having issues then you may need to do a bit of component testing to see if the VRM capacitors and other components are still in spec.

Hey!
Thanks for the reply!

That is indeed the bios I flashed. The patched V30SL from that site.
It will indeed recognize the CPU, but whenever the "+" chips are installed... I can only use the CPU and system if I "continue" to boot rather than adjust any bios settings (fsb/multiplier/voltage) or restart the PC.

The system will boot into windows just fine with the "+" CPU with a default settings of 60fsb x 6 multi (360mhz).

But the moment I restart it, that one VRM gets hot and it doesn't boot.
That's when I have to pop the non-plus back in.

Computer works perfectly fine with a K6 2 500mhz otherwise.

Any ideas? 🤔

My guess is there is at least one out of spec component in that VRM, the thing that's odd is that the K6 2/3+ are low voltage CPUs so should be putting less stress on the VRM than the higher voltage K6 2 500.

I would still check the VRM components to rule out bad components.

Someone else here may have more insight on what's going on here, I cant say I have ever had this specific issue with any of my Super 7 boards or CPUs.

Trashbytes wrote on 2025-04-30, 05:17:

My guess is there is at least one out of spec component in that VRM, the thing that's odd is that the K6 2/3+ are low voltage CPUs so should be putting less stress on the VRM than the higher voltage K6 2 500.

I would still check the VRM components to rule out bad components.

Someone else here may have more insight on what's going on here, I cant say I have ever had this specific issue with any of my Super 7 boards or CPUs.

Yeah, those are my feelings as well...
I feel like if it works with a 2.2v K6 2 500, it would be fine with a 2v K6 2+.

And absolutely, if anyone wants to walk me through how to test the VRM with my multimeter, I'm happy to do so to check that off.

Hi magicmanred,

To start with an introduction, I’m the guy who did the patched BIOS you are using and I will try to help with testing the VRM circuit on your QDI P5MVP3/A3 board.

Looking at the photo of this board on TRW, I see the 3 main active components of this VRM right next to the lever of the CPU Socket.
The first is the RC5051M DC-DC Controller, which is the “brain” of the VRM. Right next to this IC are the 2 power FETs, that do the heavy work of this switching voltage regulator. On the TRW photo I see CEB603AL FETs, but your board revision may use another equivalent type for these transistors Q6 and Q7.
Then there are also 2 diodes D8 and D12. The silver ring on these cylindrical black components indicates the cathode, so the other side is the anode of the diode.
Other components nearby belong to the VRM as well, like 2 coil-shape inductors, 7 electrolytic capacitors, and numerous small surface-mounted resistors and capacitors.

Here are the datasheets of the Controller and the FETs:

Looking at the Block Diagram on the first page of the RC5051M datasheet, you get an idea of how this circuit works. Via pins 9 and 12, the controller drives the gates of the Low-side and the High-side Power FET directly. The controller alternates driving the High- and Low-side FETS to conduct, but never at the same time! 😉
The drain of the High-side FET is connected to +5V and the source of the Low-side FET is connected to GND. In the middle, the source of the High-side FET is connected to the drain of the Low-side FET and this point provides the Vcore for the CPU via an inductor-capacitor filter.

This Ouput voltage is controlled by the RC5051M via a feedback loop, and is regulated by changing the time the High- and Low-side FETs are opened/closed.
Because the FETs essentially work as current switches, they hardly have to dissipate any heat.
The required Vcore is set by the 5 VID input pins. The logic table is on page 4 of the datasheet. Usually these VID pins are driven by jumpers or dip-switches, but on this board the BIOS controls the VID lines via General Purpose Output lines of the VIA 586B Southbridge.
Note that the BIOS only controls VID0, 1, 2, and 3. VID4 is probably not connected on this board and is always high, resulting in possible Vcore settings from 2.0V to 3.5V.

Now, for the measurements it’s best to start with the regular K6-2/500 and the patch J.1 BIOS.
Set the multimeter to Volts DC and connect the black lead to a GND point like the metal casing of the Keyboard or USB port. With the red lead measure the voltage on the drain of each FET. The drain is the metal lip at the top of the FET.
On one FET you should measure +5V and the other should indicate 2.2V. The Low-side FET is the one where you measure 2.2V and its drain is your Vcore measure point.
I’m interested in any deviating values and which FET is the one that gets hot with the K6-2+.

Now change the SpeedEasy Core voltage to Manual and lower it to 2.1V. You may need to downclock the K6-2 to 400 or 300MHz to keep it working on this undervolt.
Check if the voltage on the Vcore measure point follows the SpeedEasy Vcore setting, after "SAFE & EXIT". Also try 2.0V and 2.3V.

Hopefully you find a deviation here, so we have a lead to the problem.
But when all is well, repeating these measurements with the K6-2+ installed should get us further.

Cheers, Jan

Jan,

Absolute pleasure to meet you! 😁
I have finally allotted some time to go over your message in its entirety and pull this baby out on my bench to do some testing with the multimeter.

With the K6 2 500 @ 2.2v:
• The middle pin on the FET furthest from the CPU has a reading of 4.96v
• The middle pin on the FET closest to the CPU has a measurement of 2.21v 👌

With the K6 2 400 @ 2.1v:
• Furthest FET middle pin: 4.99v
• Closest FET middle pin: 2.09v 👌

With the K6 2 500 @ 2.3v:
• Furthest FET middle pin: 4.95v
• Closest FET middle pin: 2.31v 👌

With the K6 2 500 @ 2.4v:
• Furthest FET middle pin: 4.93v
• Closest FET middle pin: 2.42v 👌

With the K6 2 350 @ 2.0v:
• Furthest FET middle pin: 4.5v (FET HOT 🔥)
• Closest FET middle pin: 3.46v 🤯

Doesn't look like it jives with the 2v setting at all.
That's quite a lot of volts dumped into the CPU.

After that finding, I put the voltage in the bios back to 2.2 and the clock to 500.

Rebooted and all was well again.

Then I popped in the K6 2+ 570 2v CPU.

These are the measurements right upon boot:
Note: It first detects the CPU as K6 2+ 360mhz
• Furthest FET middle pin: 4.98v
• Closest FET middle pin: 2.20v

I then manually adjusted to 550mhz @ 2.1v to try to avoid the problematic 2v:
When booting, I heard one long beep then a few short (not sure how many). No display.
• Furthest FET middle pin: 4.40v (FET HOT 🔥)
• Closest FET middle pin: 3.00v 🤯

From this point, I have to put the non "+" back in to get the system to post 🥺

No matter what I set in the BIOS after the initial 2+ detection @ 360mhz, this is what happens.
Whether it's set to 300mhz @2v. 500mhz @2.1v. 550mhz @2.2v.

What are your thoughts and what other tests should I do?

Here are some photos:

https://drive.google.com/file/d/11sovb8lyAJ3U … ew?usp=drivesdk

https://drive.google.com/file/d/11uUCs-bEsSyI … ew?usp=drivesdk

https://drive.google.com/file/d/11n2_a8mykvte … ew?usp=drivesdk

https://drive.google.com/file/d/11vfBQ74icSKA … ew?usp=drivesdk

https://drive.google.com/file/d/121gvdkttKTvD … ew?usp=drivesdk

https://drive.google.com/file/d/122sM3_mn_Atr … ew?usp=drivesdk

magicmanred wrote on 2025-05-13, 01:15:

Jan, […]
Show full quote

Jan,

Absolute pleasure to meet you! 😁
I have finally allotted some time to go over your message in its entirety and pull this baby out on my bench to do some testing with the multimeter.

With the K6 2 500 @ 2.2v:
• The middle pin on the FET furthest from the CPU has a reading of 4.96v
• The middle pin on the FET closest to the CPU has a measurement of 2.21v 👌

With the K6 2 400 @ 2.1v:
• Furthest FET middle pin: 4.99v
• Closest FET middle pin: 2.09v 👌

With the K6 2 500 @ 2.3v:
• Furthest FET middle pin: 4.95v
• Closest FET middle pin: 2.31v 👌

With the K6 2 500 @ 2.4v:
• Furthest FET middle pin: 4.93v
• Closest FET middle pin: 2.42v 👌

With the K6 2 350 @ 2.0v:
• Furthest FET middle pin: 4.5v (FET HOT 🔥)
• Closest FET middle pin: 3.46v 🤯

Doesn't look like it jives with the 2v setting at all.
That's quite a lot of volts dumped into the CPU.

After that finding, I put the voltage in the bios back to 2.2 and the clock to 500.

Rebooted and all was well again.

Then I popped in the K6 2+ 570 2v CPU.

These are the measurements right upon boot:
Note: It first detects the CPU as K6 2+ 360mhz
• Furthest FET middle pin: 4.98v
• Closest FET middle pin: 2.20v

I then manually adjusted to 550mhz @ 2.1v to try to avoid the problematic 2v:
When booting, I heard one long beep then a few short (not sure how many). No display.
• Furthest FET middle pin: 4.40v (FET HOT 🔥)
• Closest FET middle pin: 3.00v 🤯

From this point, I have to put the non "+" back in to get the system to post 🥺

No matter what I set in the BIOS after the initial 2+ detection @ 360mhz, this is what happens.
Whether it's set to 300mhz @2v. 500mhz @2.1v. 550mhz @2.2v.

What are your thoughts and what other tests should I do?

Hi magicmanred,

Thanks for your detailed measurements and the clear pictures.
I see that your board sports two STB3020L Power Mosfets. These Fets can handle currents up to 40 Amps, much more than any Socket 7 CPU will ever need!
Here is the datasheet:

First your readings with the K6-2/500.
Except for the 2.0V Vcore setting, all works exactly as it should and I don’t see anything wrong with the VRM functions. You tried 2.1V, 2.2V, 2.3V, and 2.4V so all four VID0/1/2/3 signals come through correctly as well.

I know that the BIOS sets all four VID signal high when 2.0V is selected in the SpeedEasy Setup. The RC5051 datasheet indicates “No CPU” for this input pattern. Most VRM controllers default to 2.0V anyway with this setting, or lower the Vcore to their 1.25V reference voltage.
But in your case it looks like the High-side Fet Q7 is driven open continuously, resulting in a very high Vcore and a high current through the Fet and the CPU!
This should never happen and looks like a design flaw of the RC5051 controller. But I can’t completely rule-out a bad component in the VRM circuit that causes this instability.

Now looking at your findings with the K6-2+/570, it gets more complicated. At least it runs correctly at the initial 2.2V. But 3.0V, Ouch!!!
My experience with the K6-2+/III+ is that they can get unstable when overvolting them above their maximum rated 2.2V Vcore. So my hypothesis is that after the Vcore or speed setting is adjusted in the BIOS and the system reboots, a (short) Vcore spike could stall the K6-2+ and hang the boot process. If this happens early in the boot process, the BIOS signals to the RC5051’s VID inputs can be in an undefined state, triggering the same problem as with the 2.0V setting.

This all may seem far fetched, but I’ve seen these Vcore fluctuations occur during VRM re-programming in other BIOSes for jumperless boards.
Anyway, I will analyze the SpeedEasy coding in your BIOS in greater detail. In the mean time it is best not to use the K6-2+ on this board, until I have found a way to patch the BIOS for better Vcore protection.
I’m amazed your K6-2+ survived this far! 😊

Greetings, Jan

Chkcpu wrote on 2025-05-14, 18:04:

Hi magicmanred, […]
Show full quote

Hi magicmanred,

Thanks for your detailed measurements and the clear pictures.
I see that your board sports two STB3020L Power Mosfets. These Fets can handle currents up to 40 Amps, much more than any Socket 7 CPU will ever need!
Here is the datasheet:

The attachment STB3020L.pdf is no longer available

First your readings with the K6-2/500.
Except for the 2.0V Vcore setting, all works exactly as it should and I don’t see anything wrong with the VRM functions. You tried 2.1V, 2.2V, 2.3V, and 2.4V so all four VID0/1/2/3 signals come through correctly as well.

I know that the BIOS sets all four VID signal high when 2.0V is selected in the SpeedEasy Setup. The RC5051 datasheet indicates “No CPU” for this input pattern. Most VRM controllers default to 2.0V anyway with this setting, or lower the Vcore to their 1.25V reference voltage.
But in your case it looks like the High-side Fet Q7 is driven open continuously, resulting in a very high Vcore and a high current through the Fet and the CPU!
This should never happen and looks like a design flaw of the RC5051 controller. But I can’t completely rule-out a bad component in the VRM circuit that causes this instability.

Now looking at your findings with the K6-2+/570, it gets more complicated. At least it runs correctly at the initial 2.2V. But 3.0V, Ouch!!!
My experience with the K6-2+/III+ is that they can get unstable when overvolting them above their maximum rated 2.2V Vcore. So my hypothesis is that after the Vcore or speed setting is adjusted in the BIOS and the system reboots, a (short) Vcore spike could stall the K6-2+ and hang the boot process. If this happens early in the boot process, the BIOS signals to the RC5051’s VID inputs can be in an undefined state, triggering the same problem as with the 2.0V setting.

This all may seem far fetched, but I’ve seen these Vcore fluctuations occur during VRM re-programming in other BIOSes for jumperless boards.
Anyway, I will analyze the SpeedEasy coding in your BIOS in greater detail. In the mean time it is best not to use the K6-2+ on this board, until I have found a way to patch the BIOS for better Vcore protection.
I’m amazed your K6-2+ survived this far! 😊

Greetings, Jan

I know right? Seriously amazing that the CPU took that beating.

When you taught me how to measure the realtime voltage and I saw what it was pumping to it... My head exploded.

The way I discovered that something was wrong was after flashing the bios, putting in a "+" CPU, adjusting the settings in the bios and restarting.... I smelled the dreaded "help I'm burning" electrical smell.

I immediately pulled the power and touched my finger on every component near the CPU socket. I then noticed not only which one was blazing hot... But the discoloration on the solder of the chip (almost like it's happened before). So I referred to the original pics from the seller and it indeed already had that yellowing/orange burned solder/flux color.

Figured that information would be useful since it may lend some credibility to the theory that it's possibly the controller and/or the FET(s).

Looking forward to your findings!
-M

magicmanred wrote on 2025-05-14, 18:21:

I know right? Seriously amazing that the CPU took that beating. […]
Show full quote

Chkcpu wrote on 2025-05-14, 18:04:

Hi magicmanred, […]
Show full quote

Hi magicmanred,

Thanks for your detailed measurements and the clear pictures.
I see that your board sports two STB3020L Power Mosfets. These Fets can handle currents up to 40 Amps, much more than any Socket 7 CPU will ever need!
Here is the datasheet:

The attachment STB3020L.pdf is no longer available

First your readings with the K6-2/500.
Except for the 2.0V Vcore setting, all works exactly as it should and I don’t see anything wrong with the VRM functions. You tried 2.1V, 2.2V, 2.3V, and 2.4V so all four VID0/1/2/3 signals come through correctly as well.

I know that the BIOS sets all four VID signal high when 2.0V is selected in the SpeedEasy Setup. The RC5051 datasheet indicates “No CPU” for this input pattern. Most VRM controllers default to 2.0V anyway with this setting, or lower the Vcore to their 1.25V reference voltage.
But in your case it looks like the High-side Fet Q7 is driven open continuously, resulting in a very high Vcore and a high current through the Fet and the CPU!
This should never happen and looks like a design flaw of the RC5051 controller. But I can’t completely rule-out a bad component in the VRM circuit that causes this instability.

Now looking at your findings with the K6-2+/570, it gets more complicated. At least it runs correctly at the initial 2.2V. But 3.0V, Ouch!!!
My experience with the K6-2+/III+ is that they can get unstable when overvolting them above their maximum rated 2.2V Vcore. So my hypothesis is that after the Vcore or speed setting is adjusted in the BIOS and the system reboots, a (short) Vcore spike could stall the K6-2+ and hang the boot process. If this happens early in the boot process, the BIOS signals to the RC5051’s VID inputs can be in an undefined state, triggering the same problem as with the 2.0V setting.

This all may seem far fetched, but I’ve seen these Vcore fluctuations occur during VRM re-programming in other BIOSes for jumperless boards.
Anyway, I will analyze the SpeedEasy coding in your BIOS in greater detail. In the mean time it is best not to use the K6-2+ on this board, until I have found a way to patch the BIOS for better Vcore protection.
I’m amazed your K6-2+ survived this far! 😊

Greetings, Jan

I know right? Seriously amazing that the CPU took that beating.

When you taught me how to measure the realtime voltage and I saw what it was pumping to it... My head exploded.

The way I discovered that something was wrong was after flashing the bios, putting in a "+" CPU, adjusting the settings in the bios and restarting.... I smelled the dreaded "help I'm burning" electrical smell.

I immediately pulled the power and touched my finger on every component near the CPU socket. I then noticed not only which one was blazing hot... But the discoloration on the solder of the chip (almost like it's happened before). So I referred to the original pics from the seller and it indeed already had that yellowing/orange burned solder/flux color.

Figured that information would be useful since it may lend some credibility to the theory that it's possibly the controller and/or the FET(s).

Looking forward to your findings!
-M

Hi M,

Good that you smelled something was cooking and removed the power immediately!

That discoloration around FET Q7, even on the sellers pics, looks indeed like this has happened before and points to a hardware, rather than a software problem.
Reviewing the reports from the guy who tested the patch J.1 BIOS on his P5MVP3/A3 back in 2018, confirms a normal operation of a K6-2+/500 and K6-III+/550 at both 2.0V and 2.1V Vcore. He even got the K6-III+ up to 600MHz!
So, another indication that the VRM on your board is not healthy.

Note that your original K6-2/500 is also at risk of being fryed when the problem reoccurs. To further test the VRM through its full spectrum of voltage settings, we need another CPU.
Do you have a Pentium MMX? This 2.8V Vcore CPU would be ideal for further experiments. This is one of the most overengineered CPUs I know and doesn’t break a sweat when overvolted at 3.4V. It even keeps running at 2.0V when seriously underclocked.

I’ve been analysing the Vcore control in the BIOS and found which chipset register holds the control bits for the VRM controller’s VID inputs, and via which port address this register can be changed. So with the help of a specific command in DOS’s Debug tool, we can now directly control Vcore settings from 2.0V to 3.5V, circumventing the SpeedEasy BIOS settings and its limitations.

Let me know if you’re up for this experiment and if you have a Pentium MMX CPU available for these tests.

Jan

Chkcpu wrote on 2025-05-16, 19:04:

Hi M, […]
Show full quote

magicmanred wrote on 2025-05-14, 18:21:

I know right? Seriously amazing that the CPU took that beating. […]
Show full quote

Chkcpu wrote on 2025-05-14, 18:04:

Hi magicmanred, […]
Show full quote

Hi magicmanred,

Thanks for your detailed measurements and the clear pictures.
I see that your board sports two STB3020L Power Mosfets. These Fets can handle currents up to 40 Amps, much more than any Socket 7 CPU will ever need!
Here is the datasheet:

The attachment STB3020L.pdf is no longer available

First your readings with the K6-2/500.
Except for the 2.0V Vcore setting, all works exactly as it should and I don’t see anything wrong with the VRM functions. You tried 2.1V, 2.2V, 2.3V, and 2.4V so all four VID0/1/2/3 signals come through correctly as well.

I know that the BIOS sets all four VID signal high when 2.0V is selected in the SpeedEasy Setup. The RC5051 datasheet indicates “No CPU” for this input pattern. Most VRM controllers default to 2.0V anyway with this setting, or lower the Vcore to their 1.25V reference voltage.
But in your case it looks like the High-side Fet Q7 is driven open continuously, resulting in a very high Vcore and a high current through the Fet and the CPU!
This should never happen and looks like a design flaw of the RC5051 controller. But I can’t completely rule-out a bad component in the VRM circuit that causes this instability.

Now looking at your findings with the K6-2+/570, it gets more complicated. At least it runs correctly at the initial 2.2V. But 3.0V, Ouch!!!
My experience with the K6-2+/III+ is that they can get unstable when overvolting them above their maximum rated 2.2V Vcore. So my hypothesis is that after the Vcore or speed setting is adjusted in the BIOS and the system reboots, a (short) Vcore spike could stall the K6-2+ and hang the boot process. If this happens early in the boot process, the BIOS signals to the RC5051’s VID inputs can be in an undefined state, triggering the same problem as with the 2.0V setting.

This all may seem far fetched, but I’ve seen these Vcore fluctuations occur during VRM re-programming in other BIOSes for jumperless boards.
Anyway, I will analyze the SpeedEasy coding in your BIOS in greater detail. In the mean time it is best not to use the K6-2+ on this board, until I have found a way to patch the BIOS for better Vcore protection.
I’m amazed your K6-2+ survived this far! 😊

Greetings, Jan

I know right? Seriously amazing that the CPU took that beating.

When you taught me how to measure the realtime voltage and I saw what it was pumping to it... My head exploded.

The way I discovered that something was wrong was after flashing the bios, putting in a "+" CPU, adjusting the settings in the bios and restarting.... I smelled the dreaded "help I'm burning" electrical smell.

I immediately pulled the power and touched my finger on every component near the CPU socket. I then noticed not only which one was blazing hot... But the discoloration on the solder of the chip (almost like it's happened before). So I referred to the original pics from the seller and it indeed already had that yellowing/orange burned solder/flux color.

Figured that information would be useful since it may lend some credibility to the theory that it's possibly the controller and/or the FET(s).

Looking forward to your findings!
-M

Hi M,

Good that you smelled something was cooking and removed the power immediately!

That discoloration around FET Q7, even on the sellers pics, looks indeed like this has happened before and points to a hardware, rather than a software problem.
Reviewing the reports from the guy who tested the patch J.1 BIOS on his P5MVP3/A3 back in 2018, confirms a normal operation of a K6-2+/500 and K6-III+/550 at both 2.0V and 2.1V Vcore. He even got the K6-III+ up to 600MHz!
So, another indication that the VRM on your board is not healthy.

The attachment k62plus_500_post.jpg is no longer available

Note that your original K6-2/500 is also at risk of being fryed when the problem reoccurs. To further test the VRM through its full spectrum of voltage settings, we need another CPU.
Do you have a Pentium MMX? This 2.8V Vcore CPU would be ideal for further experiments. This is one of the most overengineered CPUs I know and doesn’t break a sweat when overvolted at 3.4V. It even keeps running at 2.0V when seriously underclocked.

I’ve been analysing the Vcore control in the BIOS and found which chipset register holds the control bits for the VRM controller’s VID inputs, and via which port address this register can be changed. So with the help of a specific command in DOS’s Debug tool, we can now directly control Vcore settings from 2.0V to 3.5V, circumventing the SpeedEasy BIOS settings and its limitations.

Let me know if you’re up for this experiment and if you have a Pentium MMX CPU available for these tests.

Jan

Jan,

I have ordered a Pentium 200Mhz MMX 2.8v CPU.
Once that baby comes in, I'll be ready for some more testing! Curious to see how this Dos Debug tool works 😀

Cheers,
-M

Hi -M,

Okay, you have a Pentium MMX coming. 😀

I will start working on a procedure to test the Advance III VRM. I have another SS7 system with the VIA MVP3 chipset to test it on.

Some background:
The VT82C586B Southbridge of this chipset provides 16 General Purpose Output lines, that the board designer can use for various functions.
On your P5MVP3/A3, QDI uses 11 of these lines for the SpeedEasy Jumperless control of Vcore, FSB, and multiplier. The status of these GPO lines is software controlled by reading from, or writing to, a specific I/O port.
These I/O port addresses are programmable as well, and the P5MVP3/A3 BIOS usus port 5046h for the first 8 lines (GPO7-0) and port 5047h for the second 8 lines (GPO15-8).

I’m not sure if the BIOS puts a read or write protect on these ports after POST, or leaves them open. You could help by trying a read on these ports with your K6-2 installed, so I know what to expect for the test later on.

From a clean boot DOS-prompt, run Debug.exe
At the “-“ Debug prompt, type:
i 5046
and hit the Enter key.
This should produce a 2 character hex nummer (= 8-bits), representing the status of GPO7-0.
Repeat this for GPO15-8 with the
i 5047
command.
Exit debug with the q command.

Please sent me the two results from Debug, and if my BIOS analyses is correct, I should be able to tell you which SpeedEasy Vcore/FSB/Multi settings you used for this test. 😉

Jan

Chkcpu wrote on 2025-05-14, 18:04:

Hi magicmanred, […]
Show full quote

magicmanred wrote on 2025-05-13, 01:15:

Jan, […]
Show full quote

Jan,

Absolute pleasure to meet you! 😁
I have finally allotted some time to go over your message in its entirety and pull this baby out on my bench to do some testing with the multimeter.

With the K6 2 500 @ 2.2v:
• The middle pin on the FET furthest from the CPU has a reading of 4.96v
• The middle pin on the FET closest to the CPU has a measurement of 2.21v 👌

With the K6 2 400 @ 2.1v:
• Furthest FET middle pin: 4.99v
• Closest FET middle pin: 2.09v 👌

With the K6 2 500 @ 2.3v:
• Furthest FET middle pin: 4.95v
• Closest FET middle pin: 2.31v 👌

With the K6 2 500 @ 2.4v:
• Furthest FET middle pin: 4.93v
• Closest FET middle pin: 2.42v 👌

With the K6 2 350 @ 2.0v:
• Furthest FET middle pin: 4.5v (FET HOT 🔥)
• Closest FET middle pin: 3.46v 🤯

Doesn't look like it jives with the 2v setting at all.
That's quite a lot of volts dumped into the CPU.

After that finding, I put the voltage in the bios back to 2.2 and the clock to 500.

Rebooted and all was well again.

Then I popped in the K6 2+ 570 2v CPU.

These are the measurements right upon boot:
Note: It first detects the CPU as K6 2+ 360mhz
• Furthest FET middle pin: 4.98v
• Closest FET middle pin: 2.20v

I then manually adjusted to 550mhz @ 2.1v to try to avoid the problematic 2v:
When booting, I heard one long beep then a few short (not sure how many). No display.
• Furthest FET middle pin: 4.40v (FET HOT 🔥)
• Closest FET middle pin: 3.00v 🤯

From this point, I have to put the non "+" back in to get the system to post 🥺

No matter what I set in the BIOS after the initial 2+ detection @ 360mhz, this is what happens.
Whether it's set to 300mhz @2v. 500mhz @2.1v. 550mhz @2.2v.

What are your thoughts and what other tests should I do?

Hi magicmanred,

Thanks for your detailed measurements and the clear pictures.
I see that your board sports two STB3020L Power Mosfets. These Fets can handle currents up to 40 Amps, much more than any Socket 7 CPU will ever need!
Here is the datasheet:

The attachment STB3020L.pdf is no longer available

First your readings with the K6-2/500.
Except for the 2.0V Vcore setting, all works exactly as it should and I don’t see anything wrong with the VRM functions. You tried 2.1V, 2.2V, 2.3V, and 2.4V so all four VID0/1/2/3 signals come through correctly as well.

I know that the BIOS sets all four VID signal high when 2.0V is selected in the SpeedEasy Setup. The RC5051 datasheet indicates “No CPU” for this input pattern. Most VRM controllers default to 2.0V anyway with this setting, or lower the Vcore to their 1.25V reference voltage.
But in your case it looks like the High-side Fet Q7 is driven open continuously, resulting in a very high Vcore and a high current through the Fet and the CPU!
This should never happen and looks like a design flaw of the RC5051 controller. But I can’t completely rule-out a bad component in the VRM circuit that causes this instability.

Now looking at your findings with the K6-2+/570, it gets more complicated. At least it runs correctly at the initial 2.2V. But 3.0V, Ouch!!!
My experience with the K6-2+/III+ is that they can get unstable when overvolting them above their maximum rated 2.2V Vcore. So my hypothesis is that after the Vcore or speed setting is adjusted in the BIOS and the system reboots, a (short) Vcore spike could stall the K6-2+ and hang the boot process. If this happens early in the boot process, the BIOS signals to the RC5051’s VID inputs can be in an undefined state, triggering the same problem as with the 2.0V setting.

This all may seem far fetched, but I’ve seen these Vcore fluctuations occur during VRM re-programming in other BIOSes for jumperless boards.
Anyway, I will analyze the SpeedEasy coding in your BIOS in greater detail. In the mean time it is best not to use the K6-2+ on this board, until I have found a way to patch the BIOS for better Vcore protection.
I’m amazed your K6-2+ survived this far! 😊

Greetings, Jan

I've seen behavior like this before also. indeed sometimes the VRM can get confused and just dump high voltages into the circuit.

OP could try new caps, but it kinda does seem like there may be a software solution to this, as you say if the VRM controller is getting reconfigured after post, it might get confused. sometimes it doesn't even take that. scary stuff.

There are some other options in the meantime,
-OP could gut their VRM and power it externally from a off the shelf buck converter,
-or use one of the many projects for VRMs on vogons.
-or could try replacing the parts of their VRM, perhaps it is indeed a hardware failure? caps, VRM controller, mosfets,
-or another option is a socket 5-7 interposer.

as for the heat, the heat is a function of load. a higher cpu voltage will cause more load and a larger heat dissipation. so a misconfigured but sound VRM would also make more heat on the wrong CPU voltage.

Chkcpu wrote on 2025-06-04, 16:47:

Hi -M, […]
Show full quote

Hi -M,

Okay, you have a Pentium MMX coming. 😀

I will start working on a procedure to test the Advance III VRM. I have another SS7 system with the VIA MVP3 chipset to test it on.

Some background:
The VT82C586B Southbridge of this chipset provides 16 General Purpose Output lines, that the board designer can use for various functions.
On your P5MVP3/A3, QDI uses 11 of these lines for the SpeedEasy Jumperless control of Vcore, FSB, and multiplier. The status of these GPO lines is software controlled by reading from, or writing to, a specific I/O port.
These I/O port addresses are programmable as well, and the P5MVP3/A3 BIOS usus port 5046h for the first 8 lines (GPO7-0) and port 5047h for the second 8 lines (GPO15-8).

I’m not sure if the BIOS puts a read or write protect on these ports after POST, or leaves them open. You could help by trying a read on these ports with your K6-2 installed, so I know what to expect for the test later on.

From a clean boot DOS-prompt, run Debug.exe
At the “-“ Debug prompt, type:
i 5046
and hit the Enter key.
This should produce a 2 character hex nummer (= 8-bits), representing the status of GPO7-0.
Repeat this for GPO15-8 with the
i 5047
command.
Exit debug with the q command.

Please sent me the two results from Debug, and if my BIOS analyses is correct, I should be able to tell you which SpeedEasy Vcore/FSB/Multi settings you used for this test. 😉

Jan

Jan!

Intel Pentium MMX is here.
I got a 2.8v 200mhz chip handy.

I went ahead and booted with my K6 2 500mhz chip in a known working config.

Here are the debug results:
-i 5046
00
-i 5047
00

Let me know what to try!
Looking forward to seeing how far gone this board is, or if it's salvageable 🥰

Cheers,
-M

Another thing I suppose worth noting...

When this PC is powered off, the power LED doesn't fully turn off. It dimms slightly. So some current is going through to the power LED.

I've triple checked all my I/O wires (power, reset, power led, hdd led, pc speaker) all are correct with the correct polarity for the LED's.

Figure I mention that in case there is something linked to that when it comes to current issues.

-M

magicmanred wrote on 2025-06-10, 00:04:

Jan! […]
Show full quote

Chkcpu wrote on 2025-06-04, 16:47:

Hi -M, […]
Show full quote

Hi -M,

Okay, you have a Pentium MMX coming. 😀

I will start working on a procedure to test the Advance III VRM. I have another SS7 system with the VIA MVP3 chipset to test it on.

Some background:
The VT82C586B Southbridge of this chipset provides 16 General Purpose Output lines, that the board designer can use for various functions.
On your P5MVP3/A3, QDI uses 11 of these lines for the SpeedEasy Jumperless control of Vcore, FSB, and multiplier. The status of these GPO lines is software controlled by reading from, or writing to, a specific I/O port.
These I/O port addresses are programmable as well, and the P5MVP3/A3 BIOS usus port 5046h for the first 8 lines (GPO7-0) and port 5047h for the second 8 lines (GPO15-8).

I’m not sure if the BIOS puts a read or write protect on these ports after POST, or leaves them open. You could help by trying a read on these ports with your K6-2 installed, so I know what to expect for the test later on.

From a clean boot DOS-prompt, run Debug.exe
At the “-“ Debug prompt, type:
i 5046
and hit the Enter key.
This should produce a 2 character hex nummer (= 8-bits), representing the status of GPO7-0.
Repeat this for GPO15-8 with the
i 5047
command.
Exit debug with the q command.

Please sent me the two results from Debug, and if my BIOS analyses is correct, I should be able to tell you which SpeedEasy Vcore/FSB/Multi settings you used for this test. 😉

Jan

Jan!

Intel Pentium MMX is here.
I got a 2.8v 200mhz chip handy.

I went ahead and booted with my K6 2 500mhz chip in a known working config.

Here are the debug results:
-i 5046
00
-i 5047
00

Let me know what to try!
Looking forward to seeing how far gone this board is, or if it's salvageable 🥰

Cheers,
-M

Hi -M,

Thanks fort he first Debug test results, alas you only got zero’s. 🙁

So there is indeed a lock on these ports. I’m now looking into the VT82C586B Southbridge datasheet and the BIOS code, to find how I can enable access to those GPO registers.
When found, I will write a Config file for the CTCHIPZ tool, so you can change the appropriate chipset register with a simple command from the DOS prompt.

Hope to have more soon,
Jan

PS Curious that the power LED stays dimly lit. I don’t think it is connected to the VRM issue, but I will keep it in mind.

Hi -M,

I believe I found out how to enable access to the I/O ports that SpeedEasy uses to control the GPO lines, so we can get some meaningful data when querying these port from Debug. 😉

The MVP3 chipset contains multiple independent PCI devices, each with their own address on the PCI bus and a set of configuration registers for each device. As the Power Management device in the Southbridge also houses the control of the GPO lines, I looked at the Power Management PCI Configuration registers and found several bits in these registers at offsets 40h and 41h that control access to the PM I/O space.

For the PM Device, I’ve written a Config file called “VT572.CFG” for the CTCHIP tool, so we can view and change all PM configuration registers. In the “CTCHIP for VIA MVP3” zip-file below, I’ve also 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 a VT598MVP.CFG to control the Northbridge registers, and a VT571.CFG file for IDE Device control that I wrote some time ago. We don’t need these CFG’s now, but I added them just in case.

In the VT572.CFG file, I’ve added an “IOenable” MACRO to conveniently Enable access to the PM I/O ports with one command.
Boot to DOS, and in the directory where you unzipped the files, type this command:

CTCHIPZ VT572 /IOenable

After the execution of this command, you can use the command
CTCHIPZ VT572 /40
to check if the configuration register 40h bits 7-6 are 0,1 now and after hitting the Enter key, the next register 41h should show bit 7 = 1.

Now run Debug and use the i 5046 and i 5047 commands again. Hopefully you will get some figures other than zero now. 😉

Jan

Hi -M,

I’ve got news!
I believe I’ve stumbled upon a serious bug in QDI’s SpeedEasy logic in the V3.0SL BIOS for this P5MVP3/A3 board!!

Looking further into how to test the VRM on your jumperless board by sending bit-patterns to GPO port 5046h to directly control the RC5051 Vcore controller, I wanted to know which bit-patterns the BIOS itself is using to control the required Vcore.
As I don’t have an Advance III board to play with, I put the V3.0SL patch J.1 BIOS in the great 86Box retro x86 machines emulator. I used the Emulated AOpen AX59 Pro machine, the closest match with QDI P5MVP3/A3 I could find and I set it up to emulate an original K6-2/500 CPU.

This works well, and when I checked the data from ports 5046h and 5047h, the bits for the FSB and Multiplier settings matched with my BIOS analysis. However the bits for the Vcore controller didn’t!!??? What is going on here??

After going through various Vcore settings, I found that the bit-patterns for the VID3:0 inputs of the RC5051 controller were those of a 0.1V lower programming code than I set in the SpeedEasy menu. So when I set 2.2V, I got the code for 2.1V, and when I selected 2.1V, the code for 2.0V was found.
But the big surprise came when I selected 2.0V in SpeedEasy, because the code then jumped to the value for 3.5V!!! 🔥
I repeated this test with the original v3.0SL BIOS, and found exactly the same.
I don’t know why QDI’s BIOS engineers thought it was a good idea to lower the Vcore control by 0.1V. Perhaps they needed to correct a to high VRM output a bit, thereby introducing this bug. Because there were no 2.0V CPUs at the time, this bug went unnoticed (until now).

This behavior matches what you found when testing with your K6-2/500, and fully explains the problematic 2.0V Vcore setting. So your troubles with this board may be software based afterall, and the VRM itself is not to blame. 😀

I’m now hunting for this bug and will continue testing the BIOS with 86Box set to emulate a K6-2+ CPU. When I’ve found the bug, I will also look into the V2.0SL BIOS to see if it is buggy as well.

I will be back when I have more!
Cheers, Jan