Breaking the DOS 640k barrier on 8086 and 80286 systems

We’re all familiar with this quote: “640K ought to be enough for everybody”. This quote is usually attributed to Bill Gates, but the truth is, he never actually said it. It’s an often-repeated but completely unverified myth. Hey, you know what else is a myth? The DOS 640K barrier itself! Any 8086-class system with a CGA or monochrome display card can break through that barrier by adding off-the-shelf hardware and software. I’m not talking about EMS memory, or loading drivers into upper memory: I mean truly extending the DOS 640K limit to as high as 736K.

00:35 - Let’s explore two methods for doing this on 8086-class systems, and as an added bonus, we’ll do it without breaking compatibility with existing programs. Before we begin, you may be asking, what are the benefits of extending DOS low memory past 640K? One benefit is giving more breathing room to programs that don’t support EMS or XMS memory. For example: If a business like a factory or machine shop is still relying on such a program, and it’s starting to throw errors due to high memory usage, this technique can extend the life of those programs. For vintage computing hobbyists using 8086-class systems, extending lower DOS memory allows for loading more device drivers, memory-resident programs, and network stacks. No more unloading Microsoft LAN Manager just to run a program: You can have your cake and eat it too.

01:27 - My favorite benefit, by far, is how this aids program development. Most DOS real-mode programming IDEs have little or no support for EMS. If you’re developing new DOS programs on bare metal, extending the DOS memory limit lets you develop and debug larger programs without leaving the IDE. To understand how this all works, let’s familiarize ourselves with the 8086 architecture as it pertains to memory. The 8086 can address up to 1MB of memory. For purposes of illustration, it helps to visualize this memory space divided into 64K segment boundaries.

01:58 - Certain segments were reserved by Intel and IBM for: The location of the interrupt table; addressing hardware; and the location of the ROM code necessary to start the system. The DOS 640K limit exists because 640K is the maximum range software is supposed to be loaded in. Segments A000 and B000 were suggested to be reserved for video display hardware. However, if you have no video card in those areas, it’s totally possible to map RAM there, allowing the extension of the DOS lower memory space. Now, if you require EGA or VGA graphics on your 8086-class system, this isn’t going to work for you.

02:36 - Extending DOS past 640K moves it into the video memory area for those display standards, and disables them. However, there is a partial workaround that I’ll cover later in this video, so stick around even if you think this isn’t for you. So, how do we map RAM into segment A000 and beyond, and how do we tell DOS to use the extra space? To start, we’ll need an EMS board capable of mapping memory pages anywhere. This means any EEMS 3.2 board, and most EMS 4.0 boards from AST, Boca, and possibly others. Unfortunately, we cannot use the popular homebrew Lo-Tech EMS board design because it isn’t capable of mapping memory pages where we need them. We also can’t use Intel EMS boards, because their drivers adhere to their video location recommendations to the letter, and simply refuse to map memory into A000 where we need it.

03:25 - We also need software that can do several things: Tell the EMS board to put memory in segment A000 and higher Reconfigure DOS to use the extra memory. This involves some work, such as relocating data and rewriting the DOS memory chain to reflect the expansion, so we need special software for this. There are several old freeware and shareware packages that claimed to do all this, with names like DOSMEM, 704k, EEMRAM, The Last Byte, etc. but the only software that has ever worked 100% reliably for me is the old Quarterdeck commercial product QRAM. QRAM does all of the above on 8086 and 286 systems, and can even continue mapping EMS memory pages into all of the unused areas above DOS, turning those areas into useful Upper Memory Blocks.

04:13 - What are upper memory blocks? Upper memory blocks are small memory areas outside of lower DOS RAM that can be used to load smaller code, like memory-resident programs or drivers. DOS can also directly use UMBs to load portions of itself, such as FILEs, BUFFERs, or COMMAND.COM outside of the lower memory area. Most DOS versions 5.0 or higher can do this, but if you’re limited to a lower version, a shareware package from the 1990s called DOSMAX can provide the same function. So, while upper memory blocks aren’t required to extend DOS past 640K, they can help you free up even more RAM once you do, so it’s worth configuring and using them. And now, back to our regularly-scheduled broadcast.

04:53 - So, how is this all supposed to work? How do we configure everything? As I explain the steps, let’s follow along on my 8086 clone. This system uses only CGA graphics, allowing for the highest possible extension. First, physically install a compatible EMS board, load its driver, and run its diagnostic software to ensure the board is working. It’s important to verify it can map memory into segment A000, so run the EMSINFO.EXE program, from the EEMRAM package, to check this.

05:21 - BTW, before you panic, all software mentioned in this video is provided via a link in the video’s description. Next, install QRAM, which is straightforward. After installation, it tries to run an optimization program; disregard this for now. At this stage, reboot. When DOS loads, QRAM should display that it has mapped Conventional RAM into the A000 segment. At the DOS prompt, check the memory for a pleasant surprise.

05:45 - Holy mackerel! Not only do we have more than 640K available, we have more than 640K free! This is the majority of the improvement. If you stop here, you can be proud of yourself for sticking it to Microsoft. But if you’re willing to do a few additional things, you can get even more low DOS RAM free on your 8086. Let’s cover those steps now. To maximize the use of this new larger space, we can reconfigure DOS itself with the help of some options and some software. First, if you have DOS 6 or later, add the line DOS=HIGH,UMB to CONFIG.

SYS so that DOS 06:17 - can load part of its code into an upper memory block, also called “UMB” for short. Then, load DOSMAX to move additional DOS memory structures out of the way, also into UMBs. This should free up a little bit more space. Finally, use either DOS LOADHIGH or QRAM LOADHI commands to load device drivers and memory-resident programs into UMBs. The QRAM program OPTIMIZE can automate this procedure, but it didn’t work for me in all situations, so make backups of your config.sys and autoexec.bat files before starting.

06:47 - So, this works great for a supported EMS board, but what if you don’t have one of those? I found myself in this position when I learned my Intel Aboveboard refused to map memory into segment A000. I got so angry that I spent a few nights hacking up a second method for extending the DOS limit. Here’s what I did: First, I purchased a Lo-Tech homebrew 1MB RAM board from texelec. (Note that this is not the same board as the Lo-Tech EMS board I mentioned earlier.) This board is meant to bring a lower-RAM PC up to 640K, but because it has a full 1MB, you can enable any 64K segment you want starting at segment A000.

07:25 - I configured the board to enable only A000 and installed it. Now, with actual RAM at A000, I had hoped that QRAM would take a command-line option or something to include the extra RAM, but that failed. QRAM also comes with a program called VIDRAM to extend the DOS memory limit into a VGA card’s memory space – again, more on that later – but this also failed because VIDRAM won’t work unless it can detect a real VGA card. My next idea was to patch the BIOS Data area to reflect the new size. The BIOS data area is an area of memory updated by the ROM BIOS power-on self-test, and contains system information such as the size of RAM and how many serial and parallel ports there are.

08:04 - This is what DOS looks at when determining memory size when DOS boots. Patching that value and doing a warm reboot should have worked, but for some reason it just locked up my system. I realized that the only way this was going to work is if that memory size value in the BIOS Data area was set to the new size before DOS even loaded. One way I could have done this is rewrite the ROM BIOS to check for more memory past 640k during the power-on self-test, but then I’d have to swap chips every time I changed the configuration. So instead, I chose to do this in software, by patching the boot sector.

08:37 - The boot sector is a tiny part of DOS that loads the first portion of DOS into memory and then executes it. By patching the boot sector to update that memory size variable and then load DOS, DOS will see the larger size every time it loads. So how do we do this? Here’s the basic idea for patching the code: The boot sector starts with a jump to code. We record that jump location for later. Then, we rewrite the jump to go to our patch code instead. Our patch updates the memory size variable, then jumps to the original location we recorded earlier.

09:09 - That’s a lot of work to do manually, so I wrote a program to do all that for me. For a place to hold the patch, the program finds the longest error message string in the boot sector, terminates the string early, and puts the patch right after it. This worked perfectly, and I didn’t even have to load any software for DOS to see the extra RAM. If I ever need to reverse this process, all I need to do is run SYS C: from a bootable disk to write a stock boot sector back to the hard drive. After getting this far, you probably have some questions, so let’s tackle them.

09:39 - Is there any way to get more than 736K free? Only 386+ and software that doesn’t write directly to video ram Yes, but it requires a 386 or higher and special software called Memory Commander. Because video memory would get in the way of doing this, Memory Commander uses the virtualization features of the 386 and higher to relocate it, and then tries to deal with programs that write directly to the old video memory location. While it’s technically possible, it’s not very practical. But, if you want to brag that your 386 has 920K free, Memory Commander is the only way to do it. The only situation I can think of that might benefit from this is software that doesn’t write directly to video memory, such as running a BBS.

10:18 - Is there any way I can expand low DOS memory if I have an EGA or VGA card? Well, QRAM comes with a program called VIDRAM that can extend lower DOS memory into EGA and VGA memory space, but this limits you to text-mode and CGA graphics only. That’s bad, but the good news is that you can enable and disable this behavior at any time from the command-line. You can also do this without needing an EMS board, so if you have EGA or higher, you might want to install the software and check it out. Is it possible to extend low DOS memory on Tandy or PCjr systems? Tandy and PCjr systems have less lower DOS memory available because their video systems steal that memory to work. The methods in this video are not directly compatible with those systems, however you have other options.

11:03 - For some Tandy systems such as the Tandy 1000 TX, you can add 128K of DRAM chips to the motherboard, to allow video memory to reside outside of lower DOS RAM. For a PCjr, installing a jrIDE sidecar will effectively do the same thing. Final thoughts and Resources And there you have it: 640K is a flimsy barrier just waiting to be broken on your oldest DOS hardware. I hope this video was interesting and informative, and helps you break past memory troubles on your 8086-class DOS hardware. Speaking of which, this video was a part of DOScember, a collaborative effort between youtube creators to make DOS-related videos in the month of December.

11:41 - If you’d like more DOS-related videos, see the playlist in the description to check out many other DOScember participants. .