Whew! This page is in for a major overhaul. First, thanks to all users who've given me feedback over the months. It's nice to know others on the 'net found a use for my little prog.
Second, some bad news for you MCLK fans. After much pondering, I have decided to cease any further MCLK development . There were a number of graphics chipsets I would have liked to support, but nowadays it's overly difficult for an amateur like myself to acquire chipset register information. Widespread dominance of PCI adapters has really left me in the dust… Turbo C++ 3.0 DOS cannot target the 32-bit DOS environment (DPMI.), which forces me to access PCI-adapters through the system (motherboard) BIOS. And guess what, lots of BIOS implementations (ASUS…) protect the PCI-configuration space of all PCI devices.
And finally, thanks to enterprising usenet posters, I've been able to compile some overclock info for the Cirrus Logic GD-546x, 3dLabs/TI Permedia2, and Rendition Verite V2x00. If your video card uses one of the aforementioned chips, you're in luck! Click here to jump to <Win95 video-overclocking.>
Back in April, Mr. Tom Mosher sent me his Tseng ET-6000 databook FREE OF CHARGE! His generosity enabled MCLK's support of the ET-6000 chipset. I hope his generosity will benefit all the ET-6000 users out there. Unforunately I must report some disturbing news about MCLK's flaky PCI-access method. Read on…
From a technical standpoint, MCLK's ET-6000 routine is functional. Unfortunately, MCLK's 16-bit DOS nature prevents it from directly reading/writing the PCI-configuration I/O space. Instead, MCLK uses the system BIOS's PCI routines, a compromise solution which works on some motherboards and not on others. ASUS's BIOS implementation blocks all writes to the PCI-configspace, meaning on these motherboards, MCLK can't change the ET-6000's clock-registers. I bet a lot of other motherboard BIOSs do the same.
As you know, the Mystique code never really worked. I hate to admit defeat, but it doesn't look like MCLK's Mystique clode will ever work. But not to worry, Liew Jye Khong took it upon himself to help me out, and to his credit, he has released MYCK. MYCK is a DOS-app (written in x86 assembly) which lets Mystique owners reprogram the Mystique's clock-registers. Click here to jump to my <MYCK link.>
Quick jump to:
What is MCLK? Why is it so cool?
Once upon a time, when VL-bus and 486s were king, people cherished every painstaking detail of their PC's configuration. The display adapters In naming MCLK.EXE, I borrow a term from video chip industry's jargon. The abbreviation MCLK (not to be confused with my software utility, MCLK.EXE) is short for "Memory CLocK." As it's name implies, MCLK.EXE is a software utility which lets the user reprogram his video-card's RAM clock-generator. Such a function would not be significant if video cards still retained the dumb-framebuffer architecture of yesterday's vanialla EGA & VGA boards, but today's video boards feature GUI acceleration, a hardware function which is highly dependent on the video-memory's thruput. If you've found the link to my homepage, I'll assume that you're familiar with the concept of overclocking.
To answer the second question, MCLK is one of those rare utilities in existence that offers selected users an opportunity to boost their system's video performance, without the purchase of a new video-card! If you're interested in squeezing the last few extra winmarks out of your aging video card, try MCLK.EXE. I can't guarantee your board will clock beyond its factory setting, but MCLK is free, so give it a shot before running out and buying a new $200 2D/3D graphics accelerator.
How can you possibly "overclock" a video-card?
<This section, as is the rest of the document, is under construction!>
In most contexts, "overclocking" implies the operation of a given part beyond its manufacturer rated spec. That being said, video-cards like your CPU, bus-speed, and automobile engine have manufacturer speed ratings. Exceed those speed-ratings (intentionally or unintentionally), and you're now in the land of overclocking.
*Many of the "just-past" generation graphics controllers (Cirrus GD-5436/46, Trident 9440/96xx) were designed, tested, and labelled as 80MHz parts. However, as these semiconductors were destined to the "low-end", they usually ended up in very cheap video card products with slow video DRAMs. So even though the graphics controller could officially handle up to 80MHz
< work in progress! >
PEAK BANDWIDTH = ( CLOCK SPEED) * ( WIDTH ) / ( PAGE CYCLE TIME < in # of clocks> )
DISCUSSION OF TOTAL FRAMEBUFFER BANDWIDTH
What's the fastest DRAM-clock frequency I should use with MCLK?
That depends on your video board. Most of the generic Trident and Cirrus boards won't clock much beyond 70MHz. Depending on the quality of the board's RAM, a Trio64/64V+ card may potentially clock as high as 90MHz (2-cycle EDO) or faster. Please use caution beyond 80MHz. As for 1-cycle EDO timing, I think the fastest clock-rate depends on your board's DRAM. Here are some ROUGH estimates: 40ns -> 70MHz. 45ns -> 65MHz. 50ns -> 60MHz. 60ns -> 55 MHz. Your mileage may vary.
Table of chipsets and their manufacturer specifications:
50MHz Cirrus Logic GD-542x, GD-5434 rev A
60MHz Cirrus Logic GD-5429, GD5430, GD5440, GD-5434E
60MHz Cirrus Logic GD 5436, GD-5446
60MHz S3 S3-86x, 96x, Trio32/64/64V+ (FPM/2 cycle EDO)
50MHz S3 S3 Trio64V+, Virge (1-cycle EDO)
??MHz S3 S3 Trio64V2, Virge/DX/GX/GX2/MX, Trio3D
80MHz Trident TGUI-9440, TGUI 966x, Providia9685
100MHz Trident 3Dimage
90MHz Tseng ET-6000
??MHz Tseng ET-6100
Typical manufacturer (minimum) speed ratings of commodity memory parts :
access cycle burst name
(max) (max) (min) generic part name
60ns 25ns 40MHz 60ns EDO DRAM
50ns 20ns 50MHz 50ns EDO DRAM
45ns ??ns ??MHz 45ns EDO DRAM
40ns ??ns ??MHz 40ns EDO DRAM
15ns 66MHz 15ns SDRAM or SGRAM
35ns 15ns 66MHz 35ns EDO DRAM (Silicon Magic)
12ns 83MHz 12ns SDRAM or SGRAM
28ns 12ns 83MHz 28ns EDO DRAM (Silicon Magic)
10ns 100MHz 10ns SDRAM or SGRAM
25ns 10ns 100MHz 25ns EDO DRAM (Silicon Magic)
8ns 125MHz 8ns SDRAM or SGRAM
"I've got a S3-Trio64V+ or S3/Virge chipset. What can 1-cycle EDO timing do for me?"
A lot of people didn't seem to understand this section of my document, and it's probably my fault. Here's the one line answer : Quite simply, compared to FPM/2-cycle EDO timing, 1-cycle EDO timing provides double the (burst) transfer-throughput between the graphics chip's memory-controller and video memory. If your video card's graphics-controller and video memory can both handle the 1-cycle EDO timing, you can boost your GUI (2D) performance by as much as +70%. Bandwidth hungry display modes (800x600 true-color, 1024x768 high-color, etc.) will benefit the most, while "modest" display modes (640x480 256-color, etc.) probably won't speed-up appreciably.
"I've noticed that overclocking my video-card's DRAM clock (MCLK) doesn't help DOS performance. Why?"
DOS/VGA applications write to the VGA's framebuffer memory directly. In this case, your graphics controller behaves as a bus-interface between video memory and host-bus (VLB/PCI.) Host to video-memory accesses are usually bottlenecked by the bus-transfer rate rather than the video-memory bandwidth. In other words, DOS video performance is a function of the video card's host interface unit (PCI/VLB/ISA), and your motherboard's peripheral bus interface.
PCI v2.x (33MHz) has a published burst-throughput of up to 132MB/s. This figure comes from a simple arithmetic calculation : the bus-rate (33MHz) X bus-wdith (32 bits ) = 132MB/s. Due to a variety of reasons, including PCI protocol overhead and control-logic implementation, real-world performance tops out at 80-90MB/s, which the Matrox Millenium and Tesng ET-6000 achieve.
"Why does video-card overclocking help Windows95 performance, but not DOS?"
Like I explained in the previous question, DOS/VGA operations tend to throttle the bus-interface, and are bus-bandwidth limited. As for GUI performance, Windows performance improves simply because Windows exploits your video card's graphics accelerator. And as you increases the clock-frequency of your graphics controller's datapath, you will increase your Win95-GDI redraw speed.
Statistical profiles of most GUI operations indicate a majority of graphics operations consisting of simple, repetitive tasks, like drawing a rectangular on the display, copying one part of the screen to another, etc. These tasks are highly dependent on video memory throughput. In most video-accelerator designs, the video memory and graphics controller operate synchronously (at the same clock rate.) Since most accelerators handle 70-80% of GUI redraw requests, the synchronous relationship allows the overall video system performance to scale with the video controller's clock-frequency. Note that bus-throughput does not scale with controller clock-frequency because the PCI-bus frequency is determined by the host (motherboard.)
"As I push my video-card's DRAM clock beyond it's operational frequency, glitching first appears in Windows/GUI applications. With further pushing, display-glitching hits DOS/VGA apps. Why does my VGA card first fail in Windows?"
My guess is the accelerator is less tolerant to timing violations inherent to overclocking than the host-interface. Whereas CPU-reads/writes never directly touch the framebuffer (the data passes through one or more levels of on-board write FIFOs), accelerator operations generally engage in "read/modify/write" access cycles. Execution of a read/modify/write cycle requires adherence to tighter timing than the relatively simpler host-interface accesses. Please be advised that this entire document is based on my own speculation, not legitimate (opps, is that the right word?!?) research.
When overclocking my video card's DRAM-clock, what anomalies/side effects should I look for?
Your display (the image on your monitor) is probably your only diagnostic tool. You can check for overclocking side-effects with DOS or Windows. A video card's native drivers exercise the accelerator engine to its fullest, which is likely to react to overclocking before other components of the video chipset.
CORRUPTION DURING BITBLT REDRAWS
A rock-stable image, and by that I mean an image which doesn't have shimmering video noise, or crawling pixel patterns, doesn't tell you a whole lot. So, you've got to get your video accelerator off its butt. If you're in Win95 with the Plus Pack!, activate the "full-window drag" feature. The full-window drag gives your accelerator's BITBLT engine a workout. Grab a window (preferably one with lots of colorful icons; don't just grab a blank-white window) and jiggle it around the screen. If the video card decorates your display with random dots, well looks like you'll have to reduce on the dram-freq. Likewise, your the dragged window might change color, like from white to yellow or red, 'course it's all dependent on the active color-depth (8bit, high-color, true-color.) I mean, display modes don't tax the video accelerator as much as others. It's easily possible for the video card to fail in one display mode before another.
If you're running your video card with 1-cycle EDO timing (S3-Trio64V+, Virge), carefully check the vertical borders of the dragged window. A thin vertical line of dots may corrode the edges before the background. My personal favorite is the "stained glass" effect, whereby a window-drag results in a FractalPainter-esque special-effect.
CORRUPTION DURING HOST-WRITES
Although most overclock failures manifest in Windows before DOS (due to the tight tolerances of the accelerator engine), you should still check DOS read/writes. Grab a copy of VIDSPEED or some other utility. VIDSPEED is my favorite, because it paints the screen with a progressively changing palette color (or color value, since palette doesn't apply to high/true color.) If you order test a SVGA display-mode from vidspeed, you'll notice that VIDSPEED only touches a fraction of the entire display area, generally the top of the display. I haven't verified my hunch with the author, but I'd guess vidspeed issues a VESA set_display_mode command (0x4F02), then throttles the bus with reads/writes to the VGA A0000-AFFFF address-space. What's that mean? It means VIDSPEED writes exclusively to the 1st 64k memory-bank of the active display-area. So, if you're running VIDSPEED in a SVGA mode, and random dots or lines of noise corrupt the obviously "black" areas of a VIDSPEED test screen, you know you've got trouble. The host-interface is probably the most overclocking tolerant part of your video card, and if you're seeing glitching during CPU-access, either the video chipset's host-interface can't handle the new speed, or the frame-buffer can't handle the host-interface's new speed (more likely the latter.)
SHIMMERING DISPLAY
MCLK is DOS command-line prompt utility, which means if you're running under Windows, you first shell to the DOS-prompt, execute your MCLK commands, then return to the Windows desktop. Well, as you overclock your display, you might see a "shimmering" effect. If you return to Windows, and without moving/touching anything on the desktop, your display seems to "swim" before your eyes, well that's a sign the CRTC circuit can't even properly read the display-memory. Of the cards I've pushed too hard, most cards show this phonemenon as an "advanced" symptom. That is, if you're looking at a shimmering display, you must have missed the more obvious display-ills.
Sidenote, once I was incrementally testing my video board's clocking tolerance. I entered the wrong mclk parameters, and mistakenly set the board's dram frequency to a very LOW (<30MHz) value. When I loaded an 800x600 true-color image with my dos JPEG viewer, the right half of my display swam. I can't exactly describe it, but it looked cool. (DON'T TRY THIS AT HOME)
LOCKUPS DURING WINDOWS
Some accelerator architectures rely on the host-CPU (your computer) to "wait" for the accelerator engine to return an 'ok' or 'I'm done' signal. Failure to receive these acknowledgement signals can cause system hangs; the CPU waits for a response that never comes. This is most definitely a logical failure of the accelerator engine, that is to say, you've pushed the accelerator core well beyond its maximum reliable speed.
Q: Other than overclocking my video card's memory/core speed, how else can MCLK enhance video-card performance?
MCLK allows "tweaking" of the performance/timing registers found inside many SVGA chipsets. Typical adjustments include trimming delays, cutting wait-states, and perhaps selectable DRAM timing-modes (EDO vs FPM). Such adjustments are technically not "overclocking"; after all, the graphics controller was designed and tested to support these features (otherwise why would they be there in the first place?) And that's why I call these settings "tweaks" and not overclocking!
"Can I call MCLK.EXE from my autoexec.bat file?"
Absolutely. Just insert an MCLK command-line (MCLK /0 xx yy zz etc.) into your autoexec file and you're set. Each and every time your systems boots and executes the autoexec, your command-line will be executed.
"If I change my video card's settings with MCLK, are those changes permanent?"
No. A cold-boot (RESET or power on/off cycle) will restore your video card's factory-default register settings.
"If I run MCLK from the Win95 full-screen DOS-box, will my tweaks get erased after I exit the DOS-box?"
No. Unlike OS/2, Win95 does not "preserve" the graphics controller's register values between DOS sessions. Running MCLK from a Win95 full-screen dosbox is just like running MCLK from plain MS-DOS. A cold-boot (RESET or power on/off cycle) will restore your video card's factory-default register settings.
"Why so many bugs in MCLK? And why so many revisions?"
Well, some of the bugs are my fault: sloppy coding and working late-nights. Other bugs are design limitations of MCLK. It was my first C++ program. The frequency of revisions reflects availability of new information, or response to feedback provided by end-users like yourself. I never intended this project of mine to be a commerical product, just a hobbyist's utility that might interest/benefit other end-users. After having worked with MCLK for over a year, I'll say this: I now have a much greater appreciation of companies who release bug-free software.
Will this work on any video card?
Unfortunately, no. Although most video chipsets include software-programmable performance registers, MCLK will only autodetect the following video chipsets:
Are you going to support other chipsets?
No. There will be no further development on MCLK. There are other ways to overclock your video card, just go to my main-page and click on Other overclocking information.
I know I have one of the supported video chipsets, but MCLK doesn't recognize it. What can I do?
Try the "/F" option, which forces manual-selection of the video chipset. The following examples should help you.
C:\> MCLK /F
(^^^Sorry about the long gaps. Don't blame me, blame Internet Assistant for Word.) MCLK will display a list of supported FAMILIES (S3, Cirrus.)
C:\> MCLK /F 1
MCLK will display a list of supported CHIPSETS in family #1 (Cirrus Logic GD542x, 543x, etc.)
C:\> MCLK /F 1 4
MCLK will SELECT chipset#4 of family #1 (Cirrus Logic GD54..)
Please note, all subsequent parameter selections ( 0=MCLK, 1=Function1, 2=Function2, etc.) must be preceded by a "/"
C:\> MCLK /F 1 4 /0 32
(In this example, MCLK runs FXN#0, with "32" as user-input for that function.)
How do I verify MCLK's claims of improving video performance?
Try the benchmark programs listed on my home-page. Also, take a look at the benchmarks I posted. They're pretty old now, but but they show the dramatic improvement from switching a Trio64V+ from 2-cycle EDO to 1-cycle EDO timing.
Will overclocking shorten the lifespan of my video card?
That is a very good question. From a semiconductor physics standpoint, yes. "Overclocking", or rather just running any component at a higher clock frequency increases the device's power dissipation. As current flows through the circuit, electromigration effects and whatnot cause irreversible internal "erosion", if you will. So in a sense, overclocking accelerates the chip's aging cycle.
But the real question, is whether overclocking will cause premature failure (i.e. early death not due to natural causes.) It is possible but highly unlikely. Safe and responsible use of MCLK should not damage your video card. Thus far, I have not received any emails regarding permanent damage due to MCLK. Overclocking your CPU is much more likely to result in permanent damage than overclocking your video card.
Are there any other programs that will speed-up my video-card?
UNIVBE will help certain (S3/ATI) video-cards in the SVGA video
modes. Visit Scitechsoft for
the a product description and test-drive. You can also try "S3SPDUP",
an S3 VGA/SVGA speed-up program on Dietmar's
home page (http://wwwmath.uni-muenster.de/~mesched.)
Matrox Mystique owners should check out MYCK (return to my main page for the link.)
Pentium-Pro owners should visit the FastVid homepage (return to my main page for the link.)
Riva128 owners should visit RivaExtreme (return to my main page for the link.)
Rendition V2x00, Permedia2, and Cirrus GD-546x users should visit my Win95 overclocking page.
Everyone should take a lot at Powerstrip, a new Win95/NT desktop utility from Entech.
< Go back a level > | < Return to Royce's HomePage >
© 1997 liaor@uci.edu (last updated 12/28/97)