Classic Computer Magazine Archive COMPUTE! ISSUE 135 / NOVEMBER 1991 / PAGE 70

Increase your memory power. (using the memory manager in MS-DOS 5.0)
by Mark Minasi

One of the neatest things in the new MS-DOS 5.0 is the addition of a memory manager, a program that you once had to buy separately. A memory manager's most important job is to create and manage things Microsoft calls UMBs--Upper Memory Blocks. The whole idea with UMBs is that they give DOS more memory.

The trouble is that the DOS 5.0 installation program still doesn't do anything about setting up UMBs for you. This month, I'll get started telling you what UMBs are, why you want them, and how to set them up.

First of all--what is a UMB, really? Well, you no doubt are aware of the annoying 640K memory restriction that DOS lives under. The 640K restriction is actually caused by two things: the original PC's processor chip--the 8088--and the way IBM designed the first PC. The 8088 provided a restriction in that it's incapable of working with more than 1024K, one megabyte, of memory. DOS was (and still is) written for the 8088, so it shares the 8088's limitation. The hardware limitation of DOS, then, is really 1024K, not 640K.

The 640K limitation comes from IBM's design of the PC. IBM needed to set aside some of that 1024K for system use. Here's how it originally was divvied up: OK--639K (DOS and user programs), 640K-767K (special RAM allocated to video), 768K-959K (ROMs and RAM buffers used by expansion boards), and 960K-1023K (System BIOS).

I could discuss all of these memory areas in gruesome detail for pages and pages--in fact, I have, in my PC troubleshooting book published by COMPUTE--but let me briefly summarize what each of these areas does. The user memory areas is self-explanatory, it's the 640K you've been limited to all of these years and is sometimes called conventional memory. The video RAM area isn't that interesting, except to note that all video boards must have memory on them. Video memory doesn't count in the system memory count-up that you see when you turn your machine on. If you've got 640K of memory, that's 640K in addition to your video RAM.

The 64K above the video area, between 960K and 1023K, is the system BIOS, a chip on your system's motherboard that contains the Basic Input/Output System--a bunch of software on a chip that's vital to your system's operation. BIOS software isn't shipped on a disk like other software; it's contained in a special chip called a ROM (Read Only Memory).

I left the 768K-959K area for last because it's the place where we'll spend the rest of our time. IBM knew that some add-on boards would have ROM on them. For example, every VGA boards has ROM on it. What's in the ROM? It's an extension of the system BIOS that enables the system to use the board.

Not all boards have ROM. Looking at a small sample--the three computers on my desk--one of the three computers has a hard disk controller with ROM, all three have video boards with ROM, and one has a scanner interface card with ROM on it. The occasional board also has a small RAM buffer addressed somewhere in the 768K-959K range, so keep an eye out for them.

You probably noticed ROM addresses when you poked through an expansion board's documentation, but the hexadecimal addresses may have put you off. Stuff like "the VGA BIOS uses addresses C)))) hex through C7FFF hex" makes me want to forget this nonsense, go outside, and play Frisbee, too. But you've got to get comfy with hex, so I'll offer two easy ways to cope with hex a little later.

Anyway, IBM set aside 192K of memory addresses as places for potential ROMs. Most systems don't use the whole space. For example, on my main PC, there's only 48K of ROM in the area, leaving 144K of memory addresses unused. Unused and wasted--and that's where UMBs come in.

Remember that DOS's "hardware" limitation isn't 640K; it's 1024K. If we could stuff memory into unused memory addresses between 768K and 959K, we could put programs up there. Consider my main PC. Here's how addresses 768K through 959K are used: 768K-799K (used by video ROM), 800K-815K (unused memory address), 816K-831K (used by hard disk controller), and 832K-959K (unused memory address).

In the case of this particular PC, I could use the memory in the two unused areas, 800K-815K and 832K-959K. Those areas are the UMBs.

What Do I Need?

First of all, you must have a 386-class computer: 386 or 486, SX or DX. Second, you must have at least 1MB of accessible memory. Third, you need a memory manager, which DOS 5.0 supplies as two programs: HIMEM.SYS and EMM386.EXE. Fourth, you need to know the addresses of any ROMs or RAM buffers on your circuit boards. Drag out that documentation or harass your dealer. But don't be lazy; this can be a bit tricky if you're working with inadequate information.

My examples so far have been in friendly old decimal--768K, 800K, and all that. But you've got to know hex, because that's the only thing that the documentation reports and because memory managers insist that you communicate with them in hex.

You can use the Calculator in Windows, a terrific hex-to-decimal converter. Or you can use the power of the QuickBASIC interpreter that comes with DOS 5.0. Just type in this four-line program with any ASCII text editor such as Notepad in Windows or DOS's EDIT or EDLIN. Call the file CONVHEX.BAS.

INPUT "Number to convert from hex"; A$ inval& = VAL("&h" + LTRIM$(a$) + "&") PRINT "Decimal equivalent="; inval&;" or ";inval$/1024;"K" SYSTEM

To run it, just put it in your DOS subdirectory and type qbasic /run convhex.bas. it will prompt you for a hex value; type one in, press the Enter key, and it will report the converted decimal value.

Creating UMBs

Look back at the PC with the video ROM and the hard disk controller ROM; I'll use that PC as my example machine. To get the DOS 5.0 memory manager to work, you first need to load the HIMEM.SYS and EMM386.EXE drivers and use the new DOW=HIGH,UMB command. Now, if you've got a 386-class machine, the DOS installation program has probably already set up your CONFIG.SYS so that it looks something like this:


I'm going to assume that your DOS programs are sitting in a subdirectory called C:\DOS. If that's not true, change the subdirectory references accordingly. We're next going to change the DOS= line and add another line:


That's the basic CONFIG.SYS, but we need to tweak the EMM386.EXE line. EMM386 attempts to figure out for itself which areas in memory are available, but it's not too bright. Itusually misses altogether the 64K from 896K-959K. So we'll help it out. The upper memory situation in my PC looks like this: hex A0000-C7FFF (decimal 640K-799K, video RAM and ROM), hex C8000-CBFFF (decimal 800K-815K, free), hex CC000-CFFFF (decimal 816K-831K, hard disk controller ROM), hex D0000-EFFFF (decimal 832K-959K, free).

Next, we tell EMM386.EXE to exclude the used areas and include the unused areas. You do that with the X= and I= parameters. You put these parameters on the same CONFIG.SYS line as EMM386.EXE. The ranges must be in hex, and you have to drop the rightmost digit: C0000 becomes C000, CFFFF becomes CFFF. Updated, the CONFIG.SYS statements look like this:


If you were having trouble figuring that out from the DOS manual, don't feel bad. The manual doesn't even offer a clue that multiple I= and X= parameters are legal; I just stumbled onto it. Remember that all you have to do is (1) find out where your ROMs and RAM buffers are by checking over your documentation, (2) use that information to build the I= and X= parameters, and (3) put the EMM386 and DOS=HIGH,UMB statement into your CONFIG.SYS.

Using UMBs

You can now load device drivers and TSR programs into your newly created UMBs. Instead of loading a device driver with DEVICE=, load the device driver into a UMB with DEVICEHIGH=. To load a TSR into a UMB, use the command LOADHIGH.

I use the SMARTDRV.SYS disk cache that comes with Windows and DOS. It's a device driver that I load with a line something like this:


The 512 configures the cache to be 512K in size. To load it into a UMB, substitute the following CONFIG.SYS line:


For a TSR example, let's use that nifty DOSKEY program that comes with DOS 5.0. It's a little 4K TSR that remembers the last 20 or so commands that you've typed to DOS and lets you recall them with the Up Arrow key. You'd generally load it by putting the line C:\DOS\DOSKEY in your AUTOEXEC.BAT. But to load it in a UMB, you'd put this line in AUTOEXEC.BAT:


To see the effects of the LOADHIGH and DEVICEHIGH statements, run the MEM command before you install LOADHIGH or DEVICEHIGH and note the amount of free memory you have. Install the new commands. Reboot, and run MEM again. I think you'll be pleased with the result.