|
You are here: The Oldskool PC/The Guides/Getting Old Software Running on Newer PCs/Tweaking |
Remember what I wrote earlier about how programmers in the early 80's didn't think ahead? Well, they had no reason to, of course, so we can't really chastize them for it--but that doesn't change the fact that, speed aside, early games did practically everything they could to wrestle more speed out of a 4.77 MHz 8088. This included taking the hardware hostage.
You're a programmer in 1982. If you knew that you could switch between graphics mode and text mode instantly by using a simple port write, wouldn't you use it? If you could copy data off of a floppy disk faster by using your own routines than the BIOS, wouldn't you? Of course you would. And they did, and it worked, and they had no reason to believe that their actions would cause anybody harm. (Well, okay, "harm" is maybe too strong a word to use--I guess I'm just bitter because I have to kick my PC left and right to get these old games working. :-) But what was good for the geese was not good for the gander, and as a result, those CGA tricks not only don't work, they corrupt most VGA cards to such a point that you can't see the screen at all. And don't even get me started on the "wonders" of copy-protection. I could write a book on that.
So, got a program that freaks out because its original environment has changed? Fool it. Modify your PC's environment to match what it's expecting. This is the concept we'll be exploring in this section.
No, we're not. To be specific, we're almost two decades since the original IBM PC rolled off the assembly line. What if you went to sleep in 1982 and woke up in 1998? You'd freak out, too. Programs are like people: They freak out. When presented with an unfamiliar environment, they either refuse to get out of bed or they walk right out the window, because hey, that's where they're used to seeing the door in 1982.
I know that's not terribly technical, but it's the truth. Older programs used or relied on some features of the operating system to gain some speed or shorten their size--features that were either undocumented, or in a specific location. If you try to run those programs in an "unfamiliar" operating system, it could lead to all kinds of things, like stomping on command.com (ever gotten "Memory allocation error, cannot load COMMAND.COM System halted"?), locking up the computer, triggering an exception #13 (a General Protection Fault) in your memory manager, and incorrect autodetection of your hardware.
Now, that doesn't mean that you have to dig up MSDOS 3.10 from 1986 or something, but you do have to observe a couple of rules:
Okay, so which version of DOS do you run? That completely depends on how old the game is. Here's a compatibility chart:
| DOS Version | Time Period Game Was Created | Advantages | Limitations |
|---|---|---|---|
| 2.11 | 1982-1986 | Takes the least memory of the versions listed here; most compatible with floppy-based games | Cannot access the hard drive |
| 3.30 | 1987-1990 | Most of the earlier "undocumented" DOS calls are included; good compatibility with odd proprietary hardware | Cannot access hard drive partitions over 32 megabytes |
| 5.0 | 1991-1992 | Includes SETVER.EXE, a utility to fake DOS version numbers for software with buggy version checking routines; takes less RAM than 6.22 | Hard to find (6.22 much more popular) |
| 6.22 | 1993-present | Common; includes SETVER.EXE and DOS Multi-Boot menu | Takes up more RAM than 5.0 |
Note that you don't actually need SETVER.EXE -- The author of BREMZE also wrote a program called DOSVER that does the same thing. The Resources section at the end of this Guide has pointers to his home page if you're interested in giving them a try.
Whichever version you choose, you can simply boot off of a floppy and go. But what if you're constantly running old games? Is having to boot off of a floppy all the time starting to get annoying? Beginning to wish that you could install that old version of DOS alongside of your new-fangled Windows partition? You can! Doing so involves a really cool and sophisticated utility called System Commander from V Communications that you can pick up from most software stores for about $60. It lets you install a boatload of operating systems on your hard drive and presents you with a neat menu you when boot up. You can even install multiple versions of DOS inside your existing Windows95 partition! (provided you're not using FAT32). Way cool utility. It's even great for UNIX. As I write this, I've got Windows 95, DOS, and Linux all on the same hard drive.
Here's another "gotcha" old programs love to spring on you: Too little free DOS RAM (or too much--yes, too much free RAM. I'll get to that in a minute.) You all know the drill, so I'll only describe it in passing: A program requires 585K of free DOS RAM, but you only have 520K free. You can run MEMMAKER.EXE to free up some RAM in DOS 6.x, load your DOS kernel high in 5.x or later, or simply unload your memory-resident programs in 4.x and lower. Or, you can purchase a real memory manager like QEMM and let it handle the dirty work. Voila: more of your precious DOS RAM below 640K is free. Program runs. Since the task of freeing up DOS RAM has been told a thousand times before, I won't go into it.
But did you know that you can actually have too much free RAM? Honest! As late as 1990, games assumed that the maximum free RAM possible was around 585K free. After DOS 5.0, however, free RAM of 615K or higher was not uncommon. As a result, some programs' internal "free RAM counter" wraps around and you get a bogus error message. Take, for example, California Game, written by Epyx in 1988; if you have a reasonable amount of free RAM, you get this message when the game starts:
560 kB free CALIFORNIA GAMES version 1.01 2/23/88
You've got 145K RAM more than you need, Dude.
That's gnarly!
However, if you have too much free RAM, you get this:
618 kB free YOU NEED MORE RAM TO RUN CALIFORNIA GAMES!
You are 183K RAM short of having enough memory.
You need to buy more memory or remove
any memory resident programs, Dude!
Later games (1990 and later) discovered EMS/XMS and decided to make use of it. That introduced a plethora of wacko problems:
This game does not work if you have too much memory (allocating memory does not help). It works with MS-DOS5 HIMEM.SYS and EMM386.EXE (they can only use 16 MB RAM - included as *.OLD). The beginning of your CONFIG.SYS should have something like this: DEVICE=C:\BIN\HIMEM.OLD DEVICE=C:\BIN\EMM386.OLD 8192 RAM
And here's another fun detail: This problem can extended to hard-disk installers for programs. If you have 600 MB or more free on your hard disk, but the program was written back in the days of 32 MB partition limits, you can get a bogus error message saying that you don't have enough free disk space. Fixing that involves creating some more files on your hard disk in 2 MB increments usually fools the program at the point "free disk space" modulo "32" = "space needed by the program".
Annoying, isn't it? Thankfully, Franck Uberto's freeware RAMdisk can kill two of these birds with one stone. It's a fantastic RAMdisk program that is installable from the DOS command-line, can be uninstalled at any time, can use both XMS and EMS, and can even be resized without unloading! Using this gem, you can get rid of the "too much EMS/XMS RAM" problem at the same time you create a RAMdisk small enough for installing and playing the game, eliminating the "too much free hard disk space" problem! Many thanks to my friend Lasse for bringing this up. You can get it in the Resources section at the end of this Guide.