(last updated 02/27/97)
M13SPEED is a TSR which intercepts BIOS calls to the VGA_setmode command. M13speed examines all video BIOS calls (10h.) If the call is a request for VGA mode13h (320x200 256-color), M13speed replaces the call with a request for VESA SVGA 640x400x8 (mode 100h.) M13speed ignores all other video BIOS calls and passes them on to the original interrupt handler. The emulated SVGA 320x200x256 display looks like a normal MCGA 320x200 256-color display, but operates in the framebuffer in native SVGA. The resulting emulation allows the full bus-throughput of the Trident 9440/96xxboard. In other words, M13SPEED speeds up your Trident 9440/96xx's MCGA (320x200 256-color) performance.
The resident-TSR chains to the int10h (video) software-interface. It checks all BIOS int10h calls, responding to VGA setmode13h requests (320x200 MCGA) The TSR's response to setmode13h includes issuing a VESA setmode100h (640x400 SVGA) request, reprogramming the VGA CRTC and SR registers to setup a 320x200 display field, which looks, feels, smells like MCGA 320x200. Strangely enough, reprogramming these 100% standard VGA registers sends most chipsets into the world of screen gyrations, shattered displays, and disgruntled users. If you don't have a Trident 9440/96xx based SVGA, M13speed can't help you
M13speed was inspired by Dietmar's S3SPDUP utility, and adapted from a sample TSR program available on Borland's www-site.
M13speed works because of a performance differential within the Trident 9440/96xx boards. The 9440/96xx is one of the few video chipsets in which SVGA display modes run faster than legacy (stock) VGA display modes. In the case of a PCI 9680, host-write throughput to the 9680's framebuffer clocks in at about 40-50MB/second (TritonFX host motherboard.) In contrast, legacy VGA display modes clock at 14-15MB/second. So clearly, the Trident's PCI interface is capable of decent performance (40-50MB/sec), except that VGA modes are throttled by some kind of bottleneck. Had the 9440/96xx's SVGA speed and VGA speed been equal, m13speed would not exist.
With this little performance "quirk" in mind, I set out to write a TSR which could somehow exploit the Trident's superior SVGA throughput. The product of this 1-day programming effort (more like 3½ hours, heheh) is M13SPEED. To test M13speed, I tried benchmarking my 9680PCI with the DOS/SVGA benchmark program VIDSPEED 4.0. Without m13speed, the 9680 posted MCGA ("vidspeed L") write performance of 14mb/sec*. The 9680 posted higher score in SVGA 640x400 ("vidspeed R") -- 50mb/sec*. And of course, I loaded m13speed and re-tested my 9680's MCGA performance - 50mb/sec*. This performance level is competitive with the S3 Trio series. Thus, m13speed's emulated 320x200 display addresses the Trident's MCGA performance deficiency.
*Benchmarks were performed on a PC-Chips M-520 TritonVX motherboard and AMD K5-PR90 CPU. Motherboard and CPU were set to run at 75MHz, 1.0x clock (PCI-clock = 37.5MHz.) As a point of reference, the fastest DOS-cards (Matrox MGA Millenium, Tseng ET6000) post ~80-90 MB/sec.
MODE CO80,25
(Skip to the last paragraph if you aren't in the mood for a little PC video history.)
You must be puzzled by m13speed's primary limitation: incompatibility with VGA modeX. *Sigh* Back in 1987, IBM launched the IBM PS/2 series in an effort to take back the PC-market. The PS/2 series The original PS/2 models introduced two new display standards, MCGA and VGA. The lower-end PS/2's carried the MCGA display, while the higher-end PS/2's carried the then state-of-the-art VGA display. The VGA standard pushed forward the EGA standard by adding two remarkable modes: a high-resolution 640x480 16-color display mode (with square 1:1 aspect ratio) and low-resolution 320x200 256-color ("video" color) display mode. And of course, VGA adapters featured 256k of display memory and CGA and EGA software compatibility. The MCGA standard was less spectacular. MCGA was essentially "CGA + 320x200 256-color."-- hence the name MCGA ("multi color" CGA.) With a fixed-64k framebuffer and no-EGA compatibility, MCGA was quickly replaced by VGA in IBM's later PS/2's. What's important is that both VGA and MCGA supported the same 320x200 256-color display mode.
What does this have to do with "ModeX"? When IBM originally released the VGA/MCGA display specification to third-parties, IBM documented only one 256-color display-mode. It was officially known as mode13h, the 320x200 256-color display mode found on both MCGA and VGA adapters, which I have and will continue to call "MCGA 320x200." Later, programmers found that planar-addressing could be used in conjunction with the 256-color display. "ModeX", as it was called, allowed the use of the entire VGA 256k framebuffer (MCGA was limited to the first 64k.) This translated into double-buffered (page-flipped) animation, higher (but non-standard) resolutions like 320x240 & 360x200, and large virtual screens with smooth hardware panning.
MCGA and VGA ModeX are not the same thing! M13speed won't work with ModeX games (Doom, Doom2, Heretic, to name a few) because of ModeX's non-standard planar-addressing. Like 99% of the SVGA chipsets on the market, the Trident's SVGA displays are all linearly-mapped. This means that the a given SVGA display mode is internally represented by a contiguous, progressively scanned region of framebuffer RAM. ModeX uses a special planar-mapped mode which isn't quite like EGA planar-addressing nor the usual 256-CLUT (palette) packed-pixel addressing. Since m13speed sets up a 320x200 emulation by using a SVGA display-mode, planar-addressing cannot be used when m13speed is active. M13speed can't predict the future: whether or not a game uses ModeX, both MCGA and ModeX are setup with the same bios video mode : mode13h. (ModeX displays are setup by subsequent application VGA register programming.) Attempting to use M13speed with ModeX games will cause unpredictable results. Even if you can force a ModeX game to load and execute with M13speed, the ModeX application is programmed for and will access the framebuffer using the ModeX addressing paradigm, unaware of m13speed's linearly-mapped 320x200 emulation. The end-result is a garbled screen.
There's no reason why this program can't be a snug 80bytes long; the resident-code is very simple. Unfortunately, I lack the programming expertise to transform this thing into 80x86 assembly. So for now, m13speed is a clunky 6k TSR. Of course, TURBO C++ 3.0 SOURCE CODE IS INCLUDED. It ought to compile on any of Borland's C++ products (Turbo C++ 3.0 DOS or higher.)
It's a little glitch that I'm investigating. In the meantime, if your screen goes black, try to exit the program normally. While your screen may be pitch black, your PC isn't hanged, so try to exit (without rebooting) and re-run the game.
To load M13speed, type
C:\> m13speed.exe
>M13SPEED: TSR loaded! Using VESA 100h as MCGA 13h substitute!
To unload M13speed, type
C:\> m13speed.exe
>M13SPEED: TSR unloaded!
It's that simple! Note: If you regularly use other video TSRs (UNIVBE, etc.), make sure M13speed is the last TSR loaded. Other TSRs loaded on top of M13speed may interfere with m13speed's operation.
I have put M13speed benchmarks on the MCLK benchmark page . I also recommend visiting the "System Optimization" Home Page. You can find many different benchmarks with which to compare your PC's performance.
Let me repeat something I just said, "Your mileage may vary." Today's hottest 3D games are computationally intensive, so intensive that the bulk of your CPU's time is spent composing/rendering. If copying the composed image to your VGA's framebuffer was already an insignificant time slice, doubling or even tripling your MCGA thruput won't appreciably improve your game's frame-rate.
M13SPEED has been tested with Destruction Derby, Mechwarrior 2 (DOS), Screamer, and Screamer 2 . Once in a while, m13speed doesn't properly initialize the display-mode. If you load m13speed but your screen goes blank, quit the application, unload m13speed, and load m13speed again. This should fix intermittent glitches. If the program consistently blacks-out, then the program is probably incompatible with m13speed. (Note: the intro-screen of Destruction Derby is a ModeX display. Push ESC to bypass the intro-screen.)
Compared to the standard BIOS-supplied MCGA mode13h, M13SPEED's emulated 320x200 display is shifted left approximately one character period (roughly 8 pixels in terms of MCGA resolution.)
Unlike MCLK, M13SPEED's usage does not alter any timing or clocking registers of your video board's hardware. Therefore, in a normal situation M13SPEED should pose no danger to your SVGA card or monitor.
However, M13SPEED is incompatible with ModeX applications, meaning that M13SPEED has an unpredictable effect on ModeX display. The combination of M13SPEED and ModeX applications may produce an unsyncable CRT signal. If your monitor's CRT controller is of an older or marginal design, the illegal CRT signal may indeed damage your monitor. If you happen to run a program which causes your monitor to enter into screen gyrations or spasms, simply turn off your monitor and reboot your system.
Less than four hours. That's right, I spent less time writing MCLK than I do working on a typical engineering homework assignment! I want to make it clear I'm not a brilliant programmer, but 1) I like PC video cards, 2) Borland had publicly downloadable sample TSR source-code, and 3) I have some SVGA databooks which happen to cover the standard VGA register set. Combine these three ingredients and you have a good mixture for innovation. Oh, and finally, I hated my Trident 9680's slow MCGA mode.
(MCLK, on the other hand, took a full 3 days for the basic C++ objects and program main() structure. Adding support for an additional chipset required anywhere from 30 minutes to 3 hours, depending on whether or not I code reuse existing code. Most of the time I could not immediately test/verify the new functionality, so I waited for user-feedback on whch features worked and which didn't work. Total time from receipt of databook to functional code was sometimes 2-3 months.)
Download m13speed.zip for Trident 9440/96xx chipsets (~30k, updated 08/96)
< Return to Video Utilities Page > | < Return to Royce's HomePage >