Technical information from AMD’s tech document #23792 , pages 35-39:
Upon a boot, the Duron/Athlon, for several milliseconds, operates at the multiplier provided by the BP/FID pins of the processor, no matter what you’ve said otherwise through the motherboard.
So, for instance, if you have a 1Ghz TBird, and you are trying to run the processor at 133Mhz, the processor will try to run for a few milliseconds at 10X133. If it can, it then moves on to whatever settings you’ve used per motherboard BIOS/jumpers. If it can’t (which is probably most often the case), then it goes nowhere.
The reason why we haven’t noticed this in the past is because we never could run significantly higher bus speeds due to the limitations of the KT133 chipset. All we did was increase the multiplier.
In the case of a high-multiplier TBird/Duron with a KT133A, we are doing the opposite; we are decreasing the multiplier from the original to compensate for the increased bus speed.
Let’s say we have a 1Ghz TBird that can run at 1200Mhz. We set it to run at 12 X 100 with a KT133 board and 9 X 133 with a KT133A board.
At an FSB speed of 100Mhz, what the machine does is first run at 10 X 100Mhz FSB = 1000Mhz for a few milliseconds, then goes on to 12 X 100
At an FSB speed of 133Mhz, what the machine does is first run at 10 X 133Mhz FSB = 1333Mhz for a few milliseconds, then goes on to 9 X 133.
If we have a low-multiplier CPU, and we don’t go below that multiplier, there is no difference between the initial boot speed, and the later one. If you take a Duron 600 at try to run it at 6X150Mhz, the initial speed is 6X150, and going to your settings makes no difference.
However, let’s say you have a Duron 700 that runs fine at 7 X 140. Assume for argument’s sake it can handle a 160Mhz FSB. If you lower the multiplier to, say, 5.5, and try to run it at 5.5 X 160, unless the processor can handle 7 X 160 for a few milliseconds (and it might), it’s not going to work if it can’t.
What isn’t explained by this
The Athlon 1.2Ghz: This one should have the most problems. At 133Mhz FSB, this should try to boot starting at 12 X 133 = 1600Mhz. However, that doesn’t seem to be the case. I suspect the unlocked nature of these CPUs is no accident, and that the 1.2Ghz do something a bit different than the other chips.
Instability at Otherwise Reasonable Speeds: If you have a 1Ghz CPU that boots into Windows fine at, say, 7.5 X 133Mhz, but shows instability while running at that speed, this explanation doesn’t cover your problem at all (unless something really bizarre is going on).
Are You Sure You’re Right?
No, so don’t assume we are and do anything irreversable.
I’m Stuck! What Can I Do?
If we’re right (and we’re not sure), there’s three possibilities:
Initially boot at 100Mhz, then increase the FSB later on with a SoftFSB equivalent – Unfortunately, I noticed that SoftFSB is no longer available for download at H. Oda’s site, and I doubt a plug-in has been written for the KT133A chipset yet anyway. I suspect that state of affairs won’t last forever, though. 🙂
Wait to see if a BIOS revision can take care of it – If we’re correct, we have some doubts whether or not this is even possible, but since we’re not sure, maybe this is possible.
If this can’t be fixed any other way, and we find out we’re right, change the multiplier as reported by the CPU: The multiplier used for the first few milliseconds is determined by the L3, L4 amd L6 bridges. By making or breaking particular connections between these bridges, you change the initial boot multiplier.
In this case, you’d want to lower the multiplier, so it can get through that first short period.
Were this a matter of just connecting bridges with a pencil/conductive ink pen, we’d just tell you how to do it and be done with it.
However, the way AMD has arranged these connections, to lower the speed, you have to break at least one of those bridges (besides any additions).
These are tough but very thin bridges. While people have certainly succeeded in doing this, it’s not the easiest task in the world, and you do risk destroying the CPU if you botch the job.
We see no need for the average person to actually do it right now, just to know that there is a worst-case possibility fix. Don’t even think about doing this until we’re certain that this is the case, and there are no other less-invasive measures to be taken. If necessary, we’ll put up instructions on how to do it at a later date.
If you decide to do it right now anyway, that’s solely your responsibility.
Be the first to comment