geoffrey

Thx buddy. It's indead used on the older Pentium boards, to be exact, on my ASUS P3B-F. It is the only hardware I can mess around with when visiting my father. I'm planning on taking it the extreme tour.


Voltage setting thrue BIOS doesn't work for example. I did a simple V-mod on the power regulator IC but it didn't really like it. Further research learned me that the CPU sends a 5 bit TTL signal to the power regulator. This digital code is internal converted to an analog signal, for each code the analog signal reads a differant voltage. This analog signal is then compared against the output voltage of the power regulator, 3 times.
1 -> to check over voltage (110%)
2 -> to check under voltage (90%)
3 -> over voltage protection (115%)
If the output voltage stays withing the marges, the power regulator will create a POWERGOOD signal, and if all goes well your system will boot.

The trick we used to do so much when voltmodding is fooling the feedback part of the power regulator. The output voltage is being send back to the PR through a series of resistors. If we change the resistance of that circuit, the voltage at the feedback pin will change also, causing the power regulator to regulate it's output to a higher/lower voltage. But the thing is, there is no resistor circuit used with this power regulator, so I don't really know how to fool the feedback circuit.

But I do know what digital code has to be set to the power regulator to set a certain output voltage. I have to losen those pins so that the CPU can no longer do what's suppose to do and then set the code myself with some dip switches or stuff like that.

I needed this datasheet to find a way to get above the 166MHz limit the BIOS allows me, and to add some hardlocks on the PCI bus/AGP bus.

geoffrey

Recently I scored almost 31.000 3D Marks with the 6600 I modified in the first post. This was enough to take the single card world record for 6600's with DDR1. Have a view: http://www.hwbot.org/result.do?resultId=565214

Though, I proved that the crystal has about zero impact when it comes down to highest overclock, people still are questioning my top spot score. They say that the framerate might be higher due to the timescale that changes when replacing the crystal. Wouldn't I have show that on my graph?

Feel free to share any knowledge about crystals/PLL, it's usefull and could maybe be used for further investigation.

jmke

yes that would have shown in your chart, + build in 3dmark anti cheat, think these people who accuse you of cheating a just jealous

__________________

geoffrey

I got the mobo voltmodded this morning. 5 jumpers allow me to set CPU voltage over 3V

2,6V volt got the P3 500 @ 667MHz at 45°C in bios, and still rising. Its big heatsink is aircooled though, what a power eating beast. (ambient is below 14°C)

To bad I didn't take my camera with me, but I promise they will be online anytime soon

Laagvliegerke

Cool This reminds me of the "old" days. Overclocking wasn't that easy as it is now and overclocking was very limited with only jumpers. To squeeze more performance out of their PC's, some replaced the crystal of their motherboard.
Never done it though so I'm not sure if it also influenced "time". Maybe in some cases it did but I think in most cases it didn't because "time" was calculated by a second crystal (32768 Hz) and a real time clock.

geoffrey

Today I came across an article about BIOS chips, and with some google searches I came across the following things about the Real Time Clock (RTC)...

In the older days the RTC was build with an IC, nowadays it should be added in the mainboards' southbridge. As Laagvliekerke mentiond above, the Real Time Clock is based on a 32.768kHz oscillating source (crystals for example). Reading the Intel ICH8 datasheet I came across this:

5.11 Real Time Clock (D31:F0)
The Real Time Clock (RTC) module provides a battery backed-up date and time keeping
device with two banks of static RAM with 128 bytes each, although the first bank has
114 bytes for general purpose usage. Three interrupt features are available: time of
day alarm with once a second to once a month range, periodic rates of 122 μs to 500
ms, and end of update cycle notification. Seconds, minutes, hours, days, day of week,
month, and year are counted. Daylight savings compensation is available. The hour is
represented in twelve or twenty-four hour format, and data can be represented in BCD
or binary format. The design is functionally compatible with the Motorola MS146818B.
The time keeping comes from a 32.768 kHz oscillating source, which is divided to
achieve an update every second. The lower 14 bytes on the lower RAM block has very
specific functions. The first ten are for time and date information. The next four (0Ah to
0Dh) are registers, which configure and report RTC functions.
The time and calendar data should match the data mode (BCD or binary) and hour
mode (12 or 24 hour) as selected in register B. It is up to the programmer to make
sure that data stored in these locations is within the reasonable values ranges and
represents a possible date and time. The exception to these ranges is to store a value
of C0–FFh in the Alarm bytes to indicate a don’t care situation. All Alarm conditions
must match to trigger an Alarm Flag, which could trigger an Alarm Interrupt if enabled.
The SET bit must be 1 while programming these locations to avoid clashes with an
update cycle. Access to time and date information is done through the RAM locations. If
a RAM read from the ten time and date bytes is attempted during an update cycle, the
value read do not necessarily represent the true contents of those locations. Any RAM
writes under the same conditions are ignored.
Note: The leap year determination for adding a 29th day to February does not take into
account the
end-of-the-century exceptions. The logic simply assumes that all years divisible by 4
are leap years. According to the Royal Observatory Greenwich, years that are divisible
by 100 are typically not leap years. In every fourth century (years divisible by 400, like
2000), the 100-year-exception is over-ridden and a leap-year occurs. Note that the
year 2100 will be the first time in which the current RTC implementation would
incorrectly calculate the leap-year.
The ICH8 does not implement month/year alarms.


This basicly means that my actions have no influince to the real time clock, and so I didn't do anything wrong with replacing the VGA's crystal, it's just another way to overclock your system. Thanks Laagvliegerke for your input here