I can see that easily turning into a disaster on the day I forget to change the multiplier before hitting the turbo button and end up frying the chip when it surges to 240mhz.

sliderider wrote:

I can see that easily turning into a disaster on the day I forget to change the multiplier before hitting the turbo button and end up frying the chip when it surges to 240mhz.

How can you forget to change the multiplier if it happens automatically at boot? You would need to be totally wasted and hit the turbo button before the system booted into DOS. If you really think this is a viable concern, then you should find yourself an IBM 5x86c -100HF to run at 2x60 by default.

feipoa wrote:

sliderider wrote:

I can see that easily turning into a disaster on the day I forget to change the multiplier before hitting the turbo button and end up frying the chip when it surges to 240mhz.

How can you forget to change the multiplier if it happens automatically at boot? You would need to be totally wasted and hit the turbo button before the system booted into DOS. If you really think this is a viable concern, then you should find yourself an IBM 5x86c -100HF to run at 2x60 by default.

How is it automatic? You said I'd have to change it manually before changing the frequency.

sliderider wrote:

How is it automatic? You said I'd have to change it manually before changing the frequency.

feipoa wrote:

...use the Evergreen Cyrix utility to change the multiplier from 3x to 2x (you can set the Evergreen utility to do this at boot automatically)...

"It is a matter of moving the turbo button lead onto the FSB jumper, JP3C (M919)"

So how do I do this? I have to have a jumper across that one to boot in 40mhz making the pins inaccessible.

What are the jumper settings for 60 and 66mhz?

sliderider wrote:

What are the jumper settings for 60 and 66mhz?

feipoa wrote:

40 MHz JP15, JP16, JP17 open, closed, closed […]
Show full quote

40 MHz
JP15, JP16, JP17
open, closed, closed

60 MHz
JP15, JP16, JP17
open, closed, open

JP15=JP3A, JP16=JP3B, JP17=JP3C

The jumper layout is the same. For the full table, please refer to the MB-8433UUD manual in the World's Fastest 486 link.

sliderider wrote:

"It is a matter of moving the turbo button lead onto the FSB jumper, JP3C (M919)" So how do I do this? I have to have a jumper across that one to boot in 40mhz making the pins inaccessible.

I'm not sure where the confusion is. The turbo button is a switch, so it "jumpers" and "unjumpers" two leads from the cable when you push the turbo button in and out. Most turbo buttons have 3 leads. You pick the two leads whereby the non-pressed, or up, button position has the leads closed (shorted together). Now when you press the turbo button, the button locks inward, and those same two leads will open up, thereby removing the "switch jumper" from JP3C.

Most turbo buttons are a single pole, double throw switch, so the middle lead will flip to shorting the left and middle pins, then when pressed again, it will short the right and middle pins (opening the left and middle pins). The switch is your jumper. Any middle and outer pin you pick on the cable will work, but either the turbo button will be in the up position for 60 MHz, or the down position for 60 MHz, depending on which two pin choices you make.

If your turbo button is a single pole, single throw switch, then there are only two leads, and most likely the down position will be closed (40 MHz), but it really depends on what the case maker put on there. For this application, just about any switch will work.

That was an interesting read!
I found another utility to set the control bits for the Cyrix 5x86 at
http://web.archive.org/web/19990221041609/htt … 86/cx86%21.html

lolo799 wrote:

That was an interesting read!
I found another utility to set the control bits for the Cyrix 5x86 at
http://web.archive.org/web/19990221041609/htt … 86/cx86%21.html

Thanks! I've had this Cx86! program in my folder of programs and benchmarks to test for some time now, but don't know when I'll get around to it. Thanks for reminding!

Small addendum to this work after performing some tests with GLQuake in W95c. Inasmuch as the GLQuake timedemo is concerned, the following Cyrix 5x86 register enhancements increase performance by,

FP_FAST: 9.5%
LSSER: 8%
BTB: 0 - 3.5%
RSTK: 0 - 2%
MEM_BYP: 2%
DTE_EN: 1%
BWRT: 0%
LOOP: 0%
LINBRST: Forgot to test.

caviats: Stepping 1, Revision 3 chips do not work with BWRT enabled. My Stepping 1, Revision 3 chip would not play mp3s in Winamp, while the Stepping 0, Revision 5 chips worked fine. For both revisions of chips, Quake II sometimes gets upset when FP_FAST is enabled (system freezes), while at other times, it doesn't have a problem. In particular, Quake II does not like to be sitting idle in the game with FP_FAST enabled. I enabled branch prediction (BTB) on both revisions of these chips and both played GLQuake to completion.

EDIT: GLQuake also sometimes gets upset with FP_FAST enabled when sound is enabled. This seems to be graphic card-dependent. The Rage 128 VR did not exhibit hanging with FP_FAST enabled, however the Matrox G200 (using the D3D wrapper) will hang mid-timedemo with FP_FAST enabled. I have not witnessed any other condition, aside from these two Quake games, which caused an issue with FP_FAST. GLQuake on the same hardware will sometimes complete the timedemo with FP_FAST and sound enabled.

As a reminder, LOOP and BTB should not be enabled simultaneously when using Windows. All other permutations seem fine, except keep in mind that S1R3 chips do not like BWRT and many motherboards, with the exception of late-UMC boards, do not function with LINBRST enabled.

Would you mind puttin gyour boot script that sets all this onto the forum for an easy copy/paste by the lazy like me ?

Synoptic wrote:

Would you mind puttin gyour boot script that sets all this onto the forum for an easy copy/paste by the lazy like me ?

It depends on which motherboard and which Cyrix CPU you are using. A fairly safe bet should be:

5x86 /lsser=off /fp_fast=on /rstk=on /loop=on

If you want to experiment with branch prediction, then you should not enable loop, so,

5x86 /lsser=off /fp_fast=on /rstk=on /btb=on

These are the exact commands you would use if you are employing the Peter Moss utility.

Hi,
being a mere beginner with this CPU (only found out recently, tidying up, what I´ve got here), a few puzzled questions after some easy-going tests.

Having used only the "CyrixGo" utility till now, it seems to change the values permanently. Had changed some values yesterday, separated PC from power, switched on today, started "free5x86", and it still shows me the values I set yesterday. Known feature, or does it just read back the stored values from "5x86.cfg" ?

If it just reads back the values, is there any tool setting the changes permanently or do I have to load a tool/driver every boot time?

In the "Cyrix5x86 Register Enhancements Revealed" documentation, at "My Default Settings", the first line with the "register bits" (PCR0=5h.......) - do they correspond with the following tabella or are they something extra?
If corresponding, related to which tool?

As stated, just beginning with all that, being no programmer, no solderer aso, just hardware curious - sorry if my remarks/questions sound stupid to "professional madmen" 😉

greetings, duncan
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
update: skipped the "free5x86" part for missing this fp_fast - option. Used all afternoon P.Moss´s program and was surprised about the big jump in FPU performance. At the moment running stable with

BTB, FP_FAST, MEM_BYP, DTE_EN all on, LSSER and IORT off. Still searching a possible combination to get RSTK running in win95. LINBRST and BWRT freeze the system while booting into windows. Might be my board not supporting those features.

I will report further,
greetings duncan

Glad you got it figured out. LINBRST and BWRT cause hang ups on most motherboards.

As far as I am aware, there is no means via software to permanently set the register values. I do not have enough experience with CyrixGo or free5x86 to comment on what they are reporting.

Hi feipoa,
being completely new to all this, as a first step I used the most simple program for a start. It does en/disable quite a few features (and already gave quite a boost in the "quick and dirty" wintune97-benchmark), but lacked the FP_FAST. This alone did rise FPU performance in wintune from 36/37 to 41/42 - what a jump! Once more, a big thank you for your enormous work and step-for-step guide to get this CPU running as it can. Still not satisfied with what I arrived at today, I will continue testing all the possibilities of Peter Moss´s program and keep reporting.

Cheers, duncan

Hi,

@feipoa:

Did you ever fizzle around with those more "exotic" settings in P.Moss´s prog like "/AISP" or "/BTBT" ? And if, which results did you get?

curious greetings, duncan

I have not. What do they do?

Hi,
...as far as I can understand this stuff at all, my conclusion:
- AISP would work together with LSSER=1/on to serialize all commands in the pipeline
- BTBT is the test register for BTB, in my imagination it could speed up BTB, making branch prediction more correct
- "RLML=on = reorder locked misaligned loads" is another interesting feature - could, together with LSSER=0/off speed up instructions some more reordering them

At the moment, I try to find out a way to enable all reserved instruction bits to test those settings. P.M.´s tool seems not capable doing that, so I might change to evergreen or IBM to experiment.
With P.M., the former mentioned settings still are the only stable/win95b bootable ones. Freezes when installing drivers or so, but hard reset once boots normal then.
Working applications like StarOffice4, MSPublisher97 and various graphic progs work stable. Benchmarking stresstest still on "todo"-list (want to run 3dmax99, had to change graphic card for it).

greetings duncan

Duncan, were you ever able to test AISP, BTBT, and RLML?

[PM sent]

There have been some reports that Stepping 1, Revision 3 CPUs may not function well with LSSER=0, which is the optimal state. Further investigation is required. If S1R3 CPUs are indeed unstable with LSSER, that would certainly limit their benefit, even with the Windows-safe use of BTB. I would also like to look into the frequency dependency of the branch prediction feature. I recall some tests work with it at 100 MHz, but not at 133 MHz.

I would also like to document the possibilities made by duncan. BTBT, RLML, and AISP are part of the performance control register, bits 6, 4, and 3, respectively, and would require use of the Evergreen utility to enable. I vaguely recall doing a quick test of them in the past with no beneficial effect, but possibly with negative effects.

I have done some testing with BTBT, RLML, and AISP (pits 6, 4, and 3, respectively) of the performance control register using a Cyrix MediaGXm-266.

AISP: This is 0 by default. "All instructions stalled to serialise pipeline"
AISP: When enabled (1), decreased Quake frame rate from 36.2 fps to 20.9 fps
AISP: When enabled (1), decreased DOOM frame rate from 103.6 fps to 62.4 fps
This feature, when enabled, will slow the CPU by 40%. However, if L1 is disabled, it reduces the DOOM score by only 6%

RLML = 0 by default. "Reoder of locked misaligned loads"
RLML: no change in Quake score
RLML: no change in DOOM score

BTBT: Doom score did not increase when setting BTBT enabled.
BTBT: DOOM score did not increase when setting BTBT enabled when BTB also enabled.

BTB: increased DOOM frame rate from 103.6 fps to 107.8 fps.
BTB: not stable in Quake, which is curious because BTB works with DOS Quake with Cyrix 5x86 CPUs. BTB maybe is not DOS stable at 266 MHz, but perhaps is OK at 133 MHz (speculation).

FP_FAST: increased Quake frame rate from 33.1 fps to 36.2 fps.
FP_FAST: did not increase DOOM frame rate (DOOM is ALU-only).

LSSER: increased Quake frame rate from 34.0 fps to 36.2 fps
LSSER: increased DOOM frame rate from 101.1 to 103.6 fps