Hi,
Just wanted to let you know I have flashed my P3B-F with your BIOS and everything went fine, thank you ! The final build will be a MS-6905 Slotket and a Tualatin, currently delayed because of coronavirus...
Will update after I installed it.

Thanks for this! Will use it on my P3B-F 😀

Ah, I love a happy necro post 😁

I found the thread by searching the board for information on the "Noa" bios and was surprised it went unnoticed at the time of posting! Happy it gets some late recognition.

Glad to hear it was useful to you. 😉

Oh cool, I somehow missed this thread. Might give it a try on my CUBX-E. Thanks for sharing!

DenizOezmen wrote on 2020-04-03, 17:54:

Glad to hear it was useful to you. 😉

Could you please find a way to use throttle.exe or fdapm.com for chipset throttling on the P3B-F? Both utils give 100% performance instead of 1/8, 2/8, 3/8 ... 7/8 slowdown.

vitalm wrote on 2020-04-04, 19:52:

Could you please find a way to use throttle.exe or fdapm.com for chipset throttling on the P3B-F? Both utils give 100% performance instead of 1/8, 2/8, 3/8 ... 7/8 slowdown.

I've not yet worked with slowdown tools. From a quick glance at the source code, the tools get their information on which controls to use for throttling from different sources (ACPI tables vs. PCI bus scan). The ACPI table of the P3B-F seems to be okay in this regard, and even if it wasn't, this shouldn't matter to throttle.exe.

Unfortunately, I don't have access to my P3B-F at the moment, so I can't do any live tests. No idea if this problem is solvable with a BIOS update.

DenizOezmen wrote on 2020-04-05, 09:19:

Unfortunately, I don't have access to my P3B-F at the moment, so I can't do any live tests. No idea if this problem is solvable with a BIOS update.

Thanks. I can run tests or provide a remote access to my P3B-F via Internet (if you find time and write what to do). All my other motherboards do not have any problems with chipset slowdown (boards with VIA chipset have 16 steps of throttling) both in Win98 and in DOS ("throttle.exe -c" to leave L1 cache enabled). I have to use my Acorp 6BX81 (its BIOS has no multiplier change option for unlocked Pentium II) instead of P3B-F.

vitalm wrote on 2020-04-05, 12:37:

Thanks. I can run tests or provide a remote access to my P3B-F via Internet (if you find time and write what to do). All my other motherboards do not have any problems with chipset slowdown (boards with VIA chipset have 16 steps of throttling) both in Win98 and in DOS ("throttle.exe -c" to leave L1 cache enabled). I have to use my Acorp 6BX81 (its BIOS has no multiplier change option for unlocked Pentium II) instead of P3B-F.

Thanks for the offer. The problem is just that I don't yet know what I should be searching for, so this would be quite time-consuming. You could do one test, however: Could you check whether the attached version of FDAPM behaves differently than the regular one?

Thank you very much! The patched util works!
Fdapm.com speed4 (4/8) gives 173 score in Speedsys ver.4.78 while the score with speed1 (1/8) is 43 and with speed8 (100%) is 346 on Pentium II 300 (66x4.5) in DOS 7.10.
Tested on "Noa" BIOS from www.rom.by, but it should work on any BIOS revision.
Is it possible to share your finding with the throttle util author, as the latest commit on github.com/FDOS/fdapm was made on 5 Jul 2007?

Thanks for the quick test! Quite interesting that this actually worked.

I'm not sure whether the correct solution to this problem should be implemented in the BIOS or in the throttling applications, however. I'll try and contact the author of throttle.exe, maybe he has some insights.

Background: The ACPI specification defines a 32 bit processor control register (P_CNT) for controlling clock throttle. To enable throttling, one of the register's bits (THT_EN, "throttle enable", offset 4) has to be set to 1, while a continuous block of other bits in the register is used to set the actual requested duty cycle. (Most of the time, these are three bits, giving eight speed settings.) The ACPI speficiation does not make an assumption regarding the function of the register's remaining bits.

Intel's specification update for the PIIX4(E) southbridge, however, states: "Manual throttling mode begins when CC_EN and THT_EN are set. Manual throttling mode is disabled when either CC_EN or THT_EN is disabled." So, there is yet another control bit (CC_EN, "clock control enable") to be set. According to the PIIX4 specification, this is bit 9 in the processor control register. (This bit is set by the patched fdapm.com from the above post. Which by the way also means: Don't use it on a machine with a different southbridge. Nobody knows what might happen.)

Neither the unmodified fdapm.com nor throttle.exe modify this bit, and it seems like on the P3B-F, it is not guaranteed to be set at boot. Now one could argue that the programs are ACPI compliant, while the additional control bit is a special quirk of the PIIX4 southbridge. On the other hand, I'm not sure whether an application can expect this bit to be set, since any application could also clear it. Maybe there is also some setting in the P3B-F's BIOS setup menu that has an effect on this bit?

Thanks for the very good explanation! It's not usual, even here on vogons. Earlier (two years ago) I had tested all official BIOS revisions for my P3B-F rev.1.04, changed varios BIOS options, but nothing helped.
Is it possible to mod BIOS to properly set and report unlocked Klamath as 2x with L2 enabled?
As no retail CPUs had 2x multi, all Slot1 boards I tested had 3 or 2.5 as the lowest ratio in BIOS. When you set 2x by jumpers, it shows by BIOS as 2x with L2 disabled.
And when you set 2x with L2 enabled by jumpers, both BIOS and utils like Speedsys report 5x with L2 enabled (60x5 instead of 150x2 for FSB actually set to 150).
gerwin has many posts about the "undocumented 2x with L2 enabled", starting from year 2009, e.g. Re: slot 1 Mobo
2x multi (with L2 enabled) is very useful for switching FSB "on the fly" in Win98, varying from 50 MHz on 440FX/LX to 150 on 440 BX.

Well ... the processor itself does not really report its speed per se. Even the BIOS does a speed test to determine the internal clock frequency. If the FSB clock equals one of the standard values (i.e. 66, 100, 133 MHz), the BIOS compares the measured value against pre-defined tables and chooses the best match for display purposes (during POST).

The multiplier is actually read from a model specific register (MSR 2Ah) of the processor. However, the appropriate (read-only!) part of the register only contains a more or less arbitrary bit pattern, which has to be translated to a sensible value for display in the BIOS setup screen. (Once again, a table of fixed strings is used here.)

So, my guess would be that a Klamath core processor running with a multiplier of 2.0x (and L2 cache enabled) reports the same bit pattern in MSR 2Ah that later got redefined for the 5.0x multiplier of newer cores. If so, the BIOS should report the correct core frequency (at POST), the correct FSB frequency in the setup screen, but the wrong multiplier in the setup screen, is that correct?

In that case it should theoretically be possible to implement an exception into the BIOS. However, it would really only correct the displayed value within the setup screen, which seems like quite a bit of work for a very small gain. Any software that reads the multiplier from the MSR the same way (and possibly uses it for FSB calculation) would have to implement a similar hack, since the information returned by the processor is simply ambiguous in this regard.

By the way: Is the speed selection in the P3B-F's BIOS setup fully unlocked when using a Klamath core, i.e. can you choose the multiplier yourself in jumperfree mode?

Thanks for the quick answer.

DenizOezmen wrote on 2020-04-05, 22:52:

... the BIOS should report the correct core frequency (at POST), the correct FSB frequency in the setup screen, but the wrong multiplier in the setup screen, is that correct?

Yes. Re: Pentium 2 @ 133 mhz project ,help

DenizOezmen wrote on 2020-04-05, 22:52:

In that case it should theoretically be possible to implement an exception into the BIOS. However, it would really only correct the displayed value within the setup screen, which seems like quite a bit of work for a very small gain. Any software that reads the multiplier from the MSR the same way (and possibly uses it for FSB calculation) would have to implement a similar hack, since the information returned by the processor is simply ambiguous in this regard.

I agree that the gain is very small. My thought was like "If CPU=Klamath then show 2x instead of 5x".

DenizOezmen wrote on 2020-04-05, 22:52:

By the way: Is the speed selection in the P3B-F's BIOS setup fully unlocked when using a Klamath core, i.e. can you choose the multiplier yourself in jumperfree mode?

Yes, exactly like on Abit BX6 (unfortunately, the BX6 has no FSB/4 divider for PCI). If Klamath was manufactured before August 1998.

Can this be ported for the cuv4x as well since the p3v4x are damn near identical just slot1 vs s370 difference?.

greasemonkey90s wrote on 2020-04-06, 01:55:

Can this be ported for the cuv4x as well since the p3v4x are damn near identical just slot1 vs s370 difference?.

I did look at other some BIOSes from the same time, including the CUV4X, and found only those listed in the first post to be similar enough for a straight port. (And the CUBX "non-E/L", for which I did not post the modified BIOS because I have no board to test it on.)

The CUV4X BIOS seems to be based on a slightly newer codebase and shares more similarities with the TUV4X: For example, it already supports multipliers greater than 12.0x. So, this would be a different mod. Fixing the brand names would probably be similar, and updating the microcode should be straight forward as usual (if needed). Unfortunately, I didn't find the hardware monitor code, since that seems to have been rewritten, so I currently wouldn't know how to add a new voltage monitoring range if necessary. (Does the CUV4X even complain about the CPU voltage when fitted with a Tualatin core processor?)

Hey DenizOezmen, as it seems you know your BIOS stuff really well, I've been using this faq with great information about the P3B-F and there is this entry:

"Q: What is the biggest harddisk that can be used on the P2B / P3B boards?A: The biggest harddisk that can be used on any of the boards of the P2B or P3B family is 128GB (technically, this is not a board/chipset limitation, but a bios limitiation, however those boards won't get further bios updates). To get this to work, you likely need the newest beta bios (for most of these boards, the last released final bios is really ancient, for all boards of the P2B family the newest version is 1014 beta 3), download it at asus. (As a side note, the 128GB mentioned above are binary Gigabytes (2^28*512 Bytes = 2^37 Bytes), whereas harddisk manufacturers use decimal Gigybytes (128 binary GB = 137 decimal GB), so if you see a harddisk advertised as "135GB" it should work.)"

In your opinion would it be possible to create a custom BIOS to lift that size limit on the P3B-F or would it be too complex?

Boohyaka wrote on 2020-04-06, 08:23:

In your opinion would it be possible to create a custom BIOS to lift that size limit on the P3B-F or would it be too complex?

Ah, the infamous 48 bit LBA support problem. I'm by no means a BIOS expert, but from my limited understanding, this should be possible. I don't know enough about this topic to try it, though.

Noooo, you were the chosen one! 😁

Yep, that famous LBA problem. If you (someone that managed to understand and dislike the implementation of some changes in the Noa BIOS and provide an updated version of his own) do not know how to do it, that's probably not trivial 😀