Why optimize memory? ItÕs all down to the old problem of scarce resources. When IBM designed the original PC, the idea that you could ever run out of memory was unthinkable. In those days, 64Kb was a lot of RAM Ð the Sinclair ZX80 shipped with 1Kb of RAM, the Commodore 64 had, yes, 64Kb and the IBM PC originally shipped with 16Kb. In fact, the Intel 8088 processor, which powered the IBM PC, could address a massive 1,024Kb of RAM so you can forgive the PCÕs designers for being optimistic. But this optimism proved to be short-lived when Lotus 1-2-3 arrived in 1983. It needed a huge 256Kb of RAM; more if it could get it. OK, users could add more memory but they soon came across an inherent limitation in the basic PCÕs architecture: the 640Kb boundary. As 1-2-3 became a runaway success, memory shortage became a real problem. Why is memory in such short supply? While, in theory, the 8088 can handle a full megabyte of RAM, in practice only about two-thirds of this is available for use (about 640Kb). This is because IBM erred on the side of caution and allocated a large chunk of that memory address space (384Kb) for system ROMs, such as the system BIOS, the display BIOS and the hard disk BIOS. IBM over-anticipated ROM usage of this space and on a typical modern PC only half (192Kb or less) is actually used. The problem is, as IBM specified the address of the first ROM at 640Kb, the 192Kb of available memory space above this is wasted, and canÕt be seen by MS-DOS. These chunks of memory are called upper memory blocks. With hindsight, if IBM had been a little more daring, we could all be moaning about the 832Kb DOS barrier instead of the 640Kb barrier. So, with an 8088 processor, once your PC had 640Kb fitted, that was it as far as memory expansion was concerned. Stretching the boundaries A way round the barrier was devised by Lotus, Intel and Microsoft. It was called expanded or LIM memory, and worked by swapping 16Kb, later 64Kb, chunks of memory in and out of the 640Kb of conventional memory. If it was done fast enough, it looked as though you had access to oodles of memory. The problem was that it couldnÕt be done fast enough and so expanded memory was slow. The 640Kb barrier became even more of a problem as users wanted to use things like caches and network drivers. Today, the main culprit is games software. Modern games expect to be able to access more than 600Kb of conventional memory. Curiously, few games can make use of extended memory Ð that is, memory above 1,024Kb Ð but many use the rather old-fashioned expanded memory instead. So, you can see that memory management is an issue that just wonÕt go away. What can be done? With a modern PC you can access all this lost memory above 640Kb, to load device drivers and other memory-resident programs there and as a result reduce the hit on conventional memory. You can also load parts of DOS into the 64Kb high memory area, freeing up more conventional memory. With all these tweaks you can get as much as 627Kb of free conventional memory, which should be enough to satisfy even the most awkward game. But how do you achieve this RAM nirvana? Read onÉ Stretching your memory to the limit If you want to maximize your free memory it definitely pays to be modern. The more up to date your version of DOS is, the easier it is to manage memory. Prior to MS-DOS 5, very little attention was devoted to this subject; apart from CHKDSK, there was no way of checking your memory usage. Happily, that sorry situation changed with the release of MS-DOS 5, which included the MEM command. This told you exactly what was in RAM and how much was free. Microsoft also shipped emm386.exe with MS-DOS 5, an expanded memory manager which also supported the use of upper memory blocks. Now, thanks to MS-DOS 5, you could remove programs from conventional memory and stuff them into upper memory. Although it was now possible to maximize your free memory with MS-DOS 5, it wasnÕt a particularly easy job and so MS-DOS 6.0 shipped with MemMaker, a utility which did all the memory management donkey work automatically. ItÕs not the best but itÕs still pretty good. Also, the MS-DOS 6.2 version of emm386.exe has been improved and can access a wider range of upper memory blocks than its predecessor. So, the conclusion is clear Ð if youÕve got a low memory problem, one of the first things to do is upgrade your version of DOS. It doesnÕt have to be MS-DOS 6.21, either. Novell DOS 7 is, if anything, even better when it comes to the vexed subject of memory management. The same is also true of your PC Ð the more up to date it is, the greater the amount of free conventional memory youÕll be able to squeeze from it. It all depends on what sort of processor itÕs got: What if you have an 8088? If you have an XT, that is a PC powered by an Intel 8086 processor or something similar (such as the dear old Amstrad PC1640), then your memory management options are severely limited. If this is the case, youÕll be confined to being just plain miserly with RAM. The 286 Things get a little better if you have a 286-powered PC because then you have extended memory. YouÕll be able to use the high memory area but you wonÕt be able to access the upper memory (although some memory managers, such as QEMM, can give you this feature). The 386SX and above Those with 386SXs or better can have their cake and eat it. This class of processor gives you the greatest flexibility when it comes to memory management. Armed with a 386 or something more powerful, youÕll be on your way to RAM heaven. Memory management tips l Audit your startup files It doesnÕt really matter what version of DOS or what type of PC you have; itÕs good practice for everyone to take a look at these files to see what fat can be trimmed. Not even MemMaker can guess whether or not you need a particular driver. tsr files or buffers are candidates for the chop, as they can waste a fair amount of space in the high memory area (HMA) Ð a 64Kb chunk of RAM that sits at 1,024Kb. l Load himem.sys If you have a 286 or better you need to load himem.sys in your config.sys file, as follows: DEVICE=C:\DOS\HIMEM.SYS himem.sys is an extended memory manager and, if you have more than 1Mb of RAM fitted, itÕll let you use the high memory area. You can then load part of DOS into this part of memory. To do this add the following line to config.sys: DOS=HIGH DOS will now load part of its kernel, part of command.com and buffers in this portion of the memory. Third party programs can shift even more of DOS into HMA Ð as much as a further 10Kb. l Use a memory manager If you have a 386SX PC or better, youÕll need to load a memory manager. MS-DOS 6.21 comes with emm386.exe which is a reasonable choice, especially considering itÕs free. But if your needs are greater youÕll have to buy a third party memory manager (see the box on the left). emm386.exe is loaded after himem.sys like this: DEVICE=C:\DOS\EMM386.EXE Once this has been loaded, youÕre free to access upper memory blocks. To do this, UMB support has to be turned on, in config.sys, with the following line: DOS=UMB You can now load device drivers and TSR programs into UMBs using devicehigh= statements (rather than plain device=) in your config.sys file and loadhigh (or LH) in autoexec.bat. So, using edit, amend each line of your startup files. You probably wonÕt be able to load everything up there but if it doesnÕt fit, itÕll be loaded into conventional RAM. l Tweak emm386 There are a number of tweaks you can use on emm386 (and other memory managers in principle) to save memory. These take the form of parameter switches on the emm386 command line. For instance, the nohi switch stops emm386 from loading part of itself into upper memory, saving 5Kb of UMBs. This might be handy if you need more UMBs to load a big device driver, such as dblspace.bin, for example. Another useful switch is noems. This tells emm386 that you donÕt want any expanded memory support. This will free up 64Kb of upper memory that was being used as an EMS page frame. Some modern DOS programs can access expanded memory without resort to a page frame at all, in which case you can add: Frame=none to the Emm386 command line instead. l Use MemMaker While it was possible to manually use UMBs to save memory it wasnÕt very easy. It involved tricky things like having to edit your system.ini files as well as figuring out the loading order of files to make best use of the UMBs. Armed with something like MSD (the Microsoft Diagnostics program), a pencil and paper, the IQ of Einstein and the rest of eternity, you could manually optimize it but life is too short. MS-DOS 6.2 made life a whole lot easier by including MemMaker, which automated the whole process, making it as near painless as possible. MemMaker has two modes: Express, which asks no questions; and Custom, which gives you some control over the process. Without doubt, if you have MS-DOS 6.21, you need to rearrange your memory and want an easy life, then all you need do is run MemMaker. Most users will find MemMaker sophisticated enough. It can search high and low for potential UMBs. For example, MemMaker will use the 32Kb of address space used by mono VGA displays Ð B000-B7FF Ð if you have colour VGA, which leaves that space up for grabs. However, Windows often takes exception to this, in which case you need to add the following line to the [386Enh] section of system.ini: device=monoumb.386 MemMaker will also try and use the bottom half of the system ROM space Ð F000-F7FF. This area of ROM is normally only used during booting up and isnÕt accessed while DOS is running, so it too is a prime candidate for inclusion. Not all PCs like this cheeky stunt but MemMaker will detect if it canÕt use the required area and will let you try again with more conservative settings. MemMaker wonÕt find every last bit of UMB (it ignores the range C000-C5FF, for instance) but you can probe further using MSD to examine the contents of RAM and then manually adjust emm386.exeÕs settings. You can check your progress in detail with the MEM utility. l Reduce your STACKS You can save 2 to 4Kb of conventional RAM by adding this line to your config.sys file. By default, DOS sets aside 2Kb of RAM for STACKS so you can turn it off, by typing the following line: STACKS=0,0 You might get an error message if you do, either: Exception Error 12 which comes from emm386, or: Internal Stack Overflow in which case play safe and put things back the way they were. For your information, Windows 3.1 inserts the line: STACKS=9,256 during Setup, but doesnÕt need it for its own operation. l Check your environment size Look at the SHELL statement in your config.sys file. It might look like this: SHELL=COMMAND.COM C:\DOS ç /E:1024 /P The /E:1024 bit sets aside 1Kb for environment space and this might be a bit high. You can tell how much you actually need by typing set and counting the characters it then displays. An easier way is to redirect the environment contents to a file, like this: SET > ENV Then a simple dir command will reveal the exact size of the file, and hence the size of your environment. If the file size is less than 1,024Kb, use EDIT to amend the value in the SHELL statement. l Reduce your file control blocks OK, so itÕs scraping the barrel but when youÕre struggling for vital last bytes of space every little helps! Put the following line into your config.sys file Ð itÕll save you a vital few bytes: FCBS=1 l Check your Lastdrive statement DOS allocates 88 bytes for each logical drive you specify Ð so if you have a lastdrive=z statement, youÕll be using up 2.3Kb of memory. Amend the statement to the last logical drive youÕve got. So if youÕve got a hard disk, drive C, make lastdrive= D. l Tweak DoubleSpace If you have MS-DOS 6.0 or 6.2 youÕll know that dblspace.bin, the DoubleSpace driver, is a large file, swallowing 43Kb (6.0) or 52Kb (6.2) of precious memory. It can load into the HMA but only if space and other HMA users, such as BUFFERS, permit. So keep your BUFFERS statement low, especially if youÕre using a disk cache, such as SmartDrive. You can save a further 5Kb by disabling the AutoMount feature. Finally, if you use disk compressors, such as Stacker and DoubleSpace, to increase the apparent size of RAM disks, this will result in more savings of real memory space. l #