Disclaimer/Warning:
This page is for reference information only. Performing modifications or other work inside your Mac will void your Apple warranty, may cause damage to your computer or result in personal injury. Any modifications to your CPU module may result in permanent damage requiring expensive parts replacement, data loss or personal injury. The resistors on these modules are very small surface mount devices, requiring very delicate soldering skills beyond the capability of most end users. The author and site publishers DO NOT recommend attempting any of the mods listed here.

Dual G4/500 CPU Module Speed Settings: Thanks to "Zack" for the photos of a Dual G4/500 module at this page which shows the Bus/CPU ratio resistor areas. (added 12/14/2000)

6/22/2000 Update: 133MHz Bus Speed Notes: Michiro Isobe wrote that he'd found a way to run the G4 at 133MHz bus speeds.

By using two 128MB PC133 CL2 DIMMs (http://www.crucial.com/store/partspecs.asp?imodule=CT16M64S4D7E), 133MHz bus can be running. The timebase problem in my previous report [this article-Mike] was solved by firmware tweaking.

The MacBench 5 results show only CopyBits operations are improved (by ~40%) with the bus overclocking.
Michiro Isobe"

"
Dear Mike,
Happy Holidays!. Today, I found that Mac OS X 10.1.2 has fixed the time-base
problem of bus-overclocked sawtooth. Although Apple System Profiler has
shown fixed 100MHz bus clock, the clock works normally and you can fix it by
Open Firmware tweaking.
Best Regards,
Michiro Isobe"

(Original info added 1/27/2001) Michiro Isobe wrote:

1. G4 (Gigabit Ethernet) and G4 Cube have no time-base problem.

2. The method of "firmware tweaking" for old sawtooth models.

Background:
Old G4 models (before G4 Gigabit and Cube) have some time-base problem, which the clock run faster (or slower) when the bus clock changed faster (or slower) than default of 100MHz. This is caused by timing routines of Mac OS, such as TickCount, Microseconds and UpTime, calculate time using actual bus clock and some ##fixed## values supposing 100MHz (99.6MHz exactly) bus. So, we must change these constants when change the bus clock.
I changed these constants using "NVRAMRC" OpenFirmware script. The NVRAMRC is stored in nvram and is performed at boot sequence.

If you fail to edit the NVRAMRC or need to return to the 100MHz bus, you can clear the changes by resetting the nvram, booting by holding down "Cmd" + "Opt" + "P" + "R".This TIL article explains how to reset the PRAM. (Another TIL has more details on NVRAM resets via open firmware, see commands down the page there.-Mike.)

In many cases, 133MHz bus does not work. If it seems to work, it is stable with very limited conditions.
Michiro ISOBE"

(NOTE: Michiro later noted that at 133MHz, only 2 dimm slots were usable (even with 133mhz RAM.) Also see below for comments on problems in OS X with overclocked bus speeds. [Solved by OS X 10.1.2 update he later said.] Remember that 133MHz bus speeds require PC133 RAM *and* a mod
to the CPU module to lower the bus/cpu ratio - otherwise the CPU will be
so overclocked it will not boot. (I.E. - a G4/450 module is set to 4.5x ratio
for the original 100MHz bus - at 133MHz the CPU will be trying to run 600MHz, which will not even boot. And for 450 and 500Mhz G4s - there is no setting that for those CPU speeds exactly, and the closest settings run 466MHz and 533MHz, which may not be reliable since it's overclocking the CPU beyond its rated speeds.-Mike)

OS X Issues with 133MHz Bus Speed Mod: (added 4/20/2001)

"[updated]
Mac OS 9.1 resolves the timebase problem of all sawtooth models without
Open Firmware tweaking. The only problem is Apple System Profiler still recognizes the bus clock to be 100MHz and displays incorrect machine speed.

(Mac OS X) Mac OS X has the same time-base problem with the original sawtooth system. Unfortunately, OS X detects Open Firmware tweaking to "timebase-frequency" and refuses to boot. Currently no solution is found.
[UPDATE: Michiro Isobe wrote that OS X 10.1.2 solved the time-base problem present with earlier OS X versions.]

VID signals are set by registers on the back side of the CPU daughter card.
(See Fig1.jpg and Fig3.jpg for photos identifying these)
Placing a 0 ohm register set each bit to "0"

VID4 R37

VID3 R38

VID2 R39

VID1 R44

VID0 R78

The VID code is the same with Yosemite based system. Please consult the
voltage identification table of this PDF document
http://www.cherrysemiconductor.com/product/PDF/CS-5165PDF.pdf
(UPDATE: CherrySemi was acquired by ON Semiconductor, so the URL above
is now invalid.Try www.onsemi.com/pub/Collateral/cs5165rev2.pdf) Default setting was 2.1V

(3) L2 Signal Level:

L2 signal level was specified to be 2.5V by the PPC7400 design docs. But it can be adjusted a little by changing a register at the back side of the CPU daughter card.
(See Fig1.jpg and Fig4.jpg for photos identifying these)

Bus and AGP/PCI clock can be changed by the registers at the back side of
the motherboard. ( Fig5.jpg and Fig6.jpg for photos identifying these)

But, I found that the bus overclocing also make the time base run fast. So
this modification is nonsense. If you try the bus overclocking, you must
find the source of time base and supply a clock independently.

FS0 R435

FS1 R434

FS2 R433

SSON R432

There is frequency table in this PDF document.
sg500.pdf [link revised 1/20/2001]