mockingbird wrote on 2024-10-22, 19:15:

IIRC, there does exist a KT133A board with a clockgen that supports 66Mhz... But I have no idea if the VIA southbridge would al […]
Show full quote

5a796d wrote on 2024-10-22, 18:30:

I understand, I've already lowered the fsb to 100mhz, unfortunately the k7 won't let me lower it less than that, I think it's the fault of the ddr which doesn't work at lower frequencies, but that's already fine, if I could also find some sort of cpukiller for dos or possibly win98 I could lower the frequency even further 😉

IIRC, there does exist a KT133A board with a clockgen that supports 66Mhz... But I have no idea if the VIA southbridge would allow it... Maybe I'll ask the author of VIAFSB to try to implement it.

5a796d wrote on 2024-10-22, 18:33:

however the question of L6 bridges is for those who want to increase the multiplier, which I consider useless because I'm not interested in overclocking

There is a use case for high multipliers --- if you want to run your KT133A Barton at 100mhz FSB. I have done this (20 x 100Mhz FSB = 2Ghz). You put less stress on the northbridge (less heat too) and there is only a nominal performance decrease.

i have A7V600-X ---> KT600 if I reach the goal I prefer to keep it also because it doesn't seem to give me problems with sblive pci and geforce fx 5200 agp with 64bit bus

anyway this weekend I'll try setmul + a cpu killer for win98 (or dos, I'll do some tests), if it works, according to my calculations I could get to 15mhz... and that's fine because I'm interested i which is close to 286 . I would be halfway between 286 and 386, it suits me perfectly

I noticed that with the AMD Geode NX 1750, which is nothing else than an AMD Athlon XP 1700+ Thoroughbred-B binned to run at 1.25V instead of 1.45V, SETMUL cannot deactivate the L2 cache, even though it correctly recognizes the CPU and can do this with a regular Thoroughbred-B.

Hi Gerwin, I spotted this unexpected behavior when using Setmul with MegaEm TSR running: it hangs on C3 Ezra and GUS PNP. Any type of settings whether is a multiplier or cache on/off will trigger the behavior. It just hangs with EMM386 and triggers an Exception 6 with QEMM. It doesn't make a difference if MegaEm is configured with NMI or not. Setmul is totally fine with IWSBOS and Ultramid. In couple runs where Setmul was still able to print something on screen before the hang, the CPU clock was reported off-scale to some random number (1512 instead of 933Mhz), so maybe the presence of MegaEm corrupts something in Setmul data. Are you able to reproduce this behavior on your side ? Anything you would like me to try ?

I have tested this and I cannot reproduce the problem. GUS PNP MegaEm TSR works on C3 Ezra-T 1000 MHz with Setmul.

Thanks for testing Gona!

I wonder if the chipset might play a factor, I'm using: PN133T chipset with VIA 8606T and 686B - which is the one you've been testing on ?

I also tried with minimal CONFIG.SYS (HIMEM, EMM386 and BURNMEM which I need to reduce detected RAM to 16MB) and MegaEM + Setmul still lock on this VIA chipset.

I found another scenario where launching a TSR causes the reported (and possibly actual) CPU speed to change, SoftMPU.

Can you please check if after loading SoftMPU, Setmul reports a different CPU clock ? Thanks

I also think the chipset is suspect.
I'm using VT82C693A and 596B (ASUS P3V133). OS: MS-DOS 6.22 but EMM386.EXE in the GUSPNP folder came from Win95. My config.sys is:

DEVICE=C:\GUSPNP\IWINIT.EXE ID=GRV00001 INTERWAVE=C:\GUSPNP\IW.INI
SWITCHES=/F
FILES=40
BUFFERS=23
LASTDRIVE=G
DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DEVICE=C:\GUSPNP\EMM386.EXE RAM
DEVICE=C:\DEV\MOUSE.SYS

Ram is 64MB. I have tried to load SoftMPU (I have never known/used before), but it writes "MPU-401 not detected at port 330" although IW.INI writes that MpuBase=330

OK, with SBPro2 I can start SoftMPU and Setmul reports a different CPU clock.

Thanks again for your testing, Gona!

It's good that we are both able to reproduce the C3 CPU clock change with another MPU utility (SoftMPU). In this case the CPU clock is just slightly reduced, so the system doesn't crash.

For some reason, on the PN133, I also experience the opposite effect: with a MPU utility running (MegaEM), when I start Setmul even with no parameters, I get a (non requested) overclock from 933 to 1500+ Mhz that causes the system to hang.

So the empirical data we have so far, is that these MPU TSRs are doing something to system/CMOS data, which causes Setmul to trigger a downclock or an overclock.

Would be interesting to get Gerwin ideas, maybe we can build a debug version of Setmul to see which system data is modified from various MPU TSR, and whether we can work this around, so CPU clock is not changed unintentionally starting Setmul.

>> "MPU-401 not detected at port 330" although IW.INI writes that MpuBase=330

IWSBOS reads IW.INI (and allows MPU port to be at any range, e.g. 0x320), MegaEM reads MegaEM.cfg (created with MeSetup), and can be set to only 0x300 and 0x330. Maybe it's set to 0x300 ?

sunmax wrote on 2024-11-06, 17:50:

Would be interesting to get Gerwin ideas, maybe we can build a debug version of Setmul to see which system data is modified from various MPU TSR, and whether we can work this around, so CPU clock is not changed unintentionally starting Setmul.

Yes, I am reading this. But still pondering it, between other things.
SetMul uses RDTSC (ReaD Time Stamp Counter) CPU instruction to get the MHz reading (or XOR-chaining on older CPUs). On the Pentium III, I don't see how another TSR can disturb the reading to such a degree. So yeah, the question is, is the MHz reading wrong, or is the setting of the CPU somehow skewed?

SetMul's core functionality is about sending a few bytes to a CPU MSR. These few bytes contain a value (from an internal table) which were determined to represent the intended multiplier. For multiplier read-back it is the same, but then it is a MSR read operation instead. That part is pretty simple.

SoftMPU requires EMM386, so I suppose it uses the EMM386 port-trapping functionality. I never worked with that myself. Also I never tested it together with SetMul.

Hi Gerwin, thanks for your input!

I've been testing CPU speed with different tools. These are the readings with EMM386, before starting SoftMPU:

- AIDA 2.14 : C3 933 Mhz
- NSSI 0.60: C3 837 Mhz (?)
- CKCPU 1.26: C3 825 Mhz (?)
- SetMUL 1.24: C3 933 Mhz

With SoftMPU running they become:

- AIDA 2.14 : C3 933 Mhz
- NSSI 0.60: C3 837 Mhz (?)
- CKCPU 1.26: C3 825 Mhz (?)
- SetMUL 1.24: C3 732 Mhz <--- change

I'm not familiar on how each of them detect the speed. It seems whatever SoftMPU (and on come chipset MegaEM too) does in background, skews SetMUL reading.

The other readings seem not affected (although 2 of them read it wrong, about 100Mhz short, with or without SoftMPU).

>> The question is, is the MHz reading wrong, or is the setting of the CPU somehow skewed?

Good point. To verify if just the reading, or the actual performance is skewed, I ran NSSI bench before and after SoftMPU running:

Without SoftMPU (NSSI reports CPU as C3 837 Mhz)

431125 Dhry/s [EMM386]
406048 dhry/s [QEMM]

With SoftMPU (NSSI still reports CPU as C3 837 Mhz)

431125 Dhry/s [EMM386]
410738 Dhry/s [QEMM] (some change, yet probably a fluctuation)

So it would seem only the reading (not the actual performance) of the CPU get a different reading, and only with SetMUL when SoftMPU is running in bg.

It's also interesting to notice that once the CPU frequency reading is skewed, it will survive warm reboot (QEMM) and need a full reboot or power cycle.

The wrong reading poses no issue, but with MegaEM for some reason we lock on some chipset when launching SetMUL.

Would it be possible to add additional output to SetMUL so it reports what is about to do, and we can identity at which stage we lock ?

Happy to volunteer for tests 😀

Thanks!

sunmax wrote on 2024-11-07, 01:09:

Hi Gerwin, thanks for your input! […]
Show full quote

Hi Gerwin, thanks for your input!

I've been testing CPU speed with different tools. These are the readings with EMM386, before starting SoftMPU:
...
Would it be possible to add additional output to SetMUL so it reports what is about to do, and we can identity at which stage we lock ?

Happy to volunteer for tests 😀

Thanks for the tests. So the speed measurement can be improved, as to mimic AIDA 2.14.

Fortunately, SetMul already has a debug output parameter. It is "DBG". The program then writes extra status information in green colored text.
There is also this parameter "CMD" for Clock Measure Disable.
(Both are not case sensitive)

Edit:
SetMul speed measurement compares CPU RDTSC with delay(). Maybe the latter function gets thrown off.

Thanks for the tips about CMD & DBG!

I couldn't help but try them 😀

Here is the outcome, sorry for the poor quality of the pictures.

1) This is "SetMul DBG" with "no MegaEM running". All good.

2) This is "SetMul DBG" with "MegaEM running". Hangs.

3) This is "SetMul DBG CMD" with "MegaEM running". It tells us something more before hanging: "Divide Overflow Error".

4) This is "SetMul DBG CMD" with "MegaEM running, with QEMM". It shows some additional info (regs, addr, instruction). Exception 6 should be invalid opcode.

Hope this help!
-max

sunmax wrote on 2024-11-08, 05:07:

Hope this help!
-max

Thanks for the clear. it is interesting.
The debug output needs some additional logging indeed. I will have to add that.
Seems though, I have to postpone that 2 weeks because of travel plans..
I do have a VIA Apollo pro mainboard here plus an interwave based, GUS-like card. But I would need to assemble it.

Where is last version of SetMul to download? Because in the 1st post i file with date 2019, it means 5 years old.

ruthan wrote on 2024-11-11, 00:11:

Where is last version of SetMul to download? Because in the 1st post i file with date 2019, it means 5 years old.

That is the latest release. Time flies...

Danger Manfred wrote on 2024-10-26, 06:02:

I noticed that with the AMD Geode NX 1750, which is nothing else than an AMD Athlon XP 1700+ Thoroughbred-B binned to run at 1.25V instead of 1.45V, SETMUL cannot deactivate the L2 cache, even though it correctly recognizes the CPU and can do this with a regular Thoroughbred-B.

Any idea why that is? On a normal T-Bred B 1700+ it works, and the CPU is identical except the Geode is binned to run at 1.25V.

Unless there's something weird because it's a downbinned barton or something, because there's some other bridges burned that cut the cache in half, and thus the control line doesn't pass through or something. A clue to that is if the core is more 16:9 shape than 5:4

BitWrangler wrote on 2024-11-13, 23:27:

Unless there's something weird because it's a downbinned barton or something, because there's some other bridges burned that cut the cache in half, and thus the control line doesn't pass through or something. A clue to that is if the core is more 16:9 shape than 5:4

Nope, definitely a T-Bred B.

I have tested this with the Geode NX 1750 and NX 1500 (that one runs at 7.5x133) now, on different motherboards (Nforce 2 Ultra, VIA KT133A, SiS 741GX) and a thin client (Fujitsu Futro S400).

Changing multiplier works (from 3 up to its default multi), toggling l1 cache works, but toggling l2 cache doesn't.

Can this be fixed?

I can supply all kinds of information or even send a Geode NX 1750. It works on many socket 462 boards, despite its reputation. Many boards cannot supply such a low voltage like 1 or 1.25V, but the core can run on much higher voltages without any problems, as long as a regular cooler is on top of it. It's a binned Athlon XP after all, it will run even 1.65V without taking damage.

Danger Manfred wrote on 2025-04-14, 13:52:

Changing multiplier works (from 3 up to its default multi), toggling l1 cache works, but toggling l2 cache doesn't.
Can this be fixed?

Would be nice to fix it, but I would need a datasheet that shows how the L2 enable/disable registers are different from a normal Athlon XP. Otherwise I will just be guessing.

Edit: Looking at the SetMul source, the K7+ (Athlon) K8+ (Athlon 64) have no L2 cache options in SetMul. That option was never there. Because it was not documented AFAIK. I suppose we need to know what a BIOS does to toggle it..