Thanks for the offer, I forgot to mention the program is for DOS/Win9x only. Probably won't be adding Isaiah at this moment as VIA is a completely unfamiliar territory to me and adding Samuel, Samuel 2, Erza, Erza-T is already quite difficult 🤣. The objective of the program is to slow down the CPU for DOS/Win9x gaming anyway. For Win2k and beyond perhaps there are better utilities like the Crystal utilities?

red-ray wrote on 2020-06-18, 10:01:

I also have a VIA C3-M (Nehemiah, C5P), the 25.5 looks to be wonky as do some of the freqincies, further for the a I m4 t4 I feel the before and after CPU frequency should always be reported.

I find it easy enough to deal with VIA CPUs once I get the NDA datasheets from VIA, do you not have them?

Thank you very much! So there is a bug either on multiplier setting or reading for Nehemiah. Which frequencies do you think is incorrect? I can't seem to spot them.

No, unfortunately I do not have any of the VIA NDA docs. All I have to work with are just the public datasheets and bits and pieces of info from the internet.

For Nehemiah, it seems mult 4.0 and 3.5 are invalid? From the datasheet it starts from 5.0 and goes all the way up to 16.

EBL_CR_POWERON (msr 2A):

The bug in the code is that I forgot to check for mult range before applying it. The reporting shows 255 because I used 255 to mark the "reserved" entries, but didn't check for it, as I would expect values returned from msr 2A will be valid. Anyway will also put in the checks now on.

Not sure about that, yeah maybe like you said it could be set. But then when reading back it will be a problem, as there is no corresponding entry in the BF table. When comparing Erza-T and Nehemiah, Erza-T's 3.0 entry is replaced by 16.0 in Nehemiah, so 3.0 is definitely out of the question... For 3.5, 4.0, and 4.5, they became "reserved" in Nehemiah datasheet (and that's why Cpuspd reports 25.5 because I use mult x 10 in my table, reserved is 255 so reported as 25.5). So perhaps 4.0 & 4.5 are still ok but not 3.5 (which caused Win98 to reboot), but I guess it would be risky to do since it might work for C3-M or this particular stepping but might not work for the rest. Think I'll stick with the datasheet.

Btw great find on these bugs, I handled the range checks for Samuel & Erza but forgot to do so for Nehemiah.

My BF table is like this (values are mult x10):

1// Nehemiah - convert from eblcr bus freq to mul
2static const uint8_t nehemiah_bf2mul[32] = {
3     50, 160, 255, 100,  55, 255, 255,  95,
4     90,  70,  80,  60, 120,  75,  85,  65,
5     90, 110, 120, 100, 135, 115, 125, 105,
6    130, 150, 160, 140, 120, 155, 255, 145
7};

Well if we can test all Nehemiah variations and steppings to ensure all would work then yeah. If not then there is a risk which could cause system hang. Perhaps can add a "force" option, so if the user choose to "force" it, he/she must know what he/she is doing so that would be ok.

I'm already using system timer0 as resync timer to HLT, which is 54.9ms, a lot longer than ">=1ms" stated in the datasheet. So it's either its not working under Win98 protected mode, or the CPU needs a lot longer to settle. Meanwhile I'll put in an additional 5ms delay time after the function call and see how it goes.

As for the min & max multiplier, after some thoughts, yes I concur with you to allow for 3.5 to 16.0 for Nehemiah. Ezra-T will have 3.0 to 16.0.

Regarding the title, it's not a bug but more like your personal preference, right? DOS programs during the 80s & 90s did it all the time, DOS4GW had it, all drivers had it, Setmul even did it in COLOR. As a programmer spending a lot of time developing the program and giving it out free, he at least deserves to be known, won't you agree? A typical user will run Cpuspd once to slow down the system, play some games, then run Cpuspd to reset speed back to normal. It's not like it happens all the time until becoming an annoyance. Also nobody looks at the title anyway.

Oh and thanks for spotting the frequency bug, appreciate it.

CPUSPD 1.3 beta2 with some bugs fixes for C3 is now ready. Also added max/min multiplier display. Please download for testing from this post. Hope can get more people to help out with the test.

red-ray wrote on 2020-06-18, 16:43:

[…]
Show full quote

1. It's supposed to be beta1, but reports as alpha1
2. q should be implemented and if not should give an error.
3. m4.3 should give an error, but does not
4. Speed should be 533MHz rather than 480MHz.
5. I was unable to find the "max/min multiplier display", where is it?
6. I feel i should generate one line of output rather than two.

1. Yes, I forgot to update the version.
2. No, sorry "q" won't happen.
3. This is done on purpose, so that any values in between will be rounded down to the next lower multiplier.
4. Thank you, this is still being look into.
5. Min max display is in beta2.
6. There are other non VIA CPUs with very long names.

Any other C3 owners who are willing to help out with the testing please?

Posting the same results I posted here

kalohimal wrote on 2020-06-18, 17:10:

@johnnycontrario […]
Show full quote

@johnnycontrario

Sorry to trouble you again. When you could find time, would you please help me try this in pure DOS and Win98 DOS box?
cpuspd i m4.0 i
cpuspd i

There seems to be a problem when "i" is issued right after multiplier is changed, in that it won't be able to obtain the cpu frequency correctly. I would like to find out whether this is limited to Nehemiah or Ezra also has this issue as well.

Thank you very much.

Under pure DOS, I got the following output:

1COMMAND: cpuspd i m4.0 i 
2
3CPUSPEED version 1.3 beta2. This program is freeware.
4Written by David Chee Y. Wong, Johor Bahru, Malaysia.
5VIA Ezra  ID(6,7,A)
6CPU frequency is 797MHz (TSC)
7Current multiplier: 4.0 (min 3.0, max 12.0)
8VIA Ezra  ID(6,7,A)
9CPU frequency is 531MHz (TSC)
10
11COMMAND: cpuspd i
12
13CPUSPEED version 1.3 beta2. This program is freeware.
14Written by David Chee Y. Wong, Johor Bahru, Malaysia.
15VIA Ezra  ID(6,7,A)
16CPU frequency is 531MHz (TSC)

Setmul reports 4.0x, 533MHz.

In Windows 98, CPUSPD reports 532MHz, and HWiNFO shows the same. However, CPUSPD intermittently reports 527MHz. I ran CPUSPD i in a new dosbox five more times after this screenshot and only got the 527MHz measurement one other time.

@johnnycontrario

Thanks!