This document combines several mails that wandered around in fd-dev (@topica.com) during October 2002. Editing done by Eric. *** Part one: FreeDOS memory management FAQ by Eric *** Hi everybody, as requested by Lyn@...: The phantastic FreeDOS memory management FAQ ! So you want to use > 640k of RAM with your DOS? Then read on... If you want to load drivers and programs high, you need UMB. If you want to load the kernel high as well (partially), you need HMA. If your programs want XMS memory (common way to use > 1 MB of RAM for DOS programS), you need XMS (gosh :-)). If your programs want EMS memory, you need EMS. EMS is a "classic" way for this: There were EMS memory boards for very old PCs, but now- adays, you use an EMS emulator, an "emm386". Or XMS, of course. However, some programs cannot use both (EMS and XMS) but only one of them, so you need to offer the needed type of memory to them. If you are running an "emm386", your DOS will run in a "task" under some protected mode kernel implemented by emm386. This means that DOS no longer has full control over the PC. However, it is needed to offer EMS in an elegant way, and sometimes for UMB, too. Read below. If you are running a program that uses protected mode, normal drivers do not cause problems. HOWEVER, emm386 type drivers need to offer a back- door called VCPI to allow protected mode access while emm386 is running. If you run an emm386 without the backdoor, you cannot use protected mode. If your program mentions something about "DOS extender" and/or "DPMI", it is usually a program that needs protected mode. A DOS extender is some- thing that allows protected mode programs to have easy access to normal DOS functions (DOS does not run in protected mode, as you remember: The "task" where DOS runs if emm386 is active is a simulation of "real mode" (unprotected mode, so to say), kind of a virtual 8086 CPU, but with the 32bit stuff still available. However, in the "DOS task", 32bit addressing is NOT available, and this is why our "extended friends" need to use the VCPI backdoor to get into full protected mode. Without emm386 running, the 32bit addressing is available "enough" for those programs to get into protected mode without further help. By the way, DPMI is kind of a protected mode toolkit that makes life easy for "DOS extenders". Some of them come with a builtin DPMI program, some do not. > Arkady adds that you CAN do 32bit addressing in v86 mode. > This is true but it only means that you can do 32bit address calculations, > data structures still have the 64k size limit issue without protected mode. > Of course you can have several 64k chunks in DOS, but in protected mode, > you can simply have one big chunk of several megabytes for your table or > other data structure... > Arkady also mentions "unreal" or "flat real mode". However, you cannot > reach this from v86 mode. The idea is that you activate protected mode for > a moment, allocate all your RAM in a single memory chunk, and leave the > chunk size intact when jumping back to real mode. That way, your program > runs in real mode but can access all RAM. However, this is an evil hack > that exploits the status caching behaviour of the processors memory > management. Most "flat real mode" programs do not even work when VCPI > or DPMI are present. They just need plain real mode to start from. Okay, enough confusion about terms, now about the software: *** XMS *** fdxms286: offers XMS and HMA on 286 PCs, at most 16 MB there. fdxms: offer XMS and HMA on 386 PCs, up to 64 MB. fdxxms, himem: offers XMS and HMA, up to 2 GB RAM can be used. DR DOS himem: like himem, some versions are limited to 64 MB. MS DOS himem: like himem, some versions are limited to 64 MB. *** EMS *** FreeDOS emm386: offers EMS and UMB. Older versions offer no VCPI, though. This requires himem to be installed before. Incompatible to fdxxms, but may work with fdxms, fdxms286, DR himem or MS himem. Feedback wanted. DR DOS emm386: offers EMS and UMB, can optionally offer XMS and even DPMI. Useful if you have a program with a DOS extender that has a broken built- in DPMI. XMS is useful because XMS offered by DR DOS emm386 is sure to be compatible to DR DOS emm386 :-). If you use it with FDXXMS, you MAY be able to convince DR DOS emm386 to use > 64 MB RAM. MS DOS emm386: Some versions run with FreeDOS, others do not. Needs some XMS driver present, so load the XMS driver first (some are more, some are less MS DOS emm386 compatible, your mileage may vary). Limited to 64 or 256 MB of RAM, depending on the version and the used XMS driver. Offers EMS and UMB and VCPI. (DR DOS emm386 also offers VCPI, of course) Some versions of MS DOS himem may allow to use > 64 MB of RAM. Older versions of FreeDOS emm386 had problems if > 64 MB RAM exist. You may only run ONE driver per memory type (if you run DR DOS emm386, however, you may also use another XMS driver - the DR DOS emm386 will then not provide XMS but use the existing driver). *** UMB *** If you only need UMB and no EMS, you can avoid the "locked in the task" and "VCPI" problem (some old protected mode programs do not even accept VCPI but want the CPU to be theirs without needing a backdoor) by using an UMB-only driver. Those drivers reprogram your motherboard to make the RAM in the UMB area (640k ... 1 MB, excluding ROM and video RAM) accessible. So you can only use this method when your motherboard is supported by one of the UMB-only drivers. You can find a list in technote 177. The drivers are: UMBPCI: common for 586 (Pentium) and newer chipsets. Some AMD Athlon chipsets are - alas - not supported. HIRAM: Classic choice for 486 and 386 systems. RDOSUMB, URAM: Alternative choices, mainly for 486 and 386 systems. One of them allows you to use UMB if you managed to make that RAM accessible using some external means, too. For example with the 386 NeAT chipset, you can enable that RAM in your BIOS CMOS setup. The driver would then be able to detect it and allow UMB to use the area. *** TERMS *** Some acronyms: > With several corrections provided by other list members :-) XMS - extended memory specification EMS - expanded memory specification DPMI - dos protected mode interface VCPI - virtual control programm interface UMB - upper memory block (memory chunk in 640k ... 1 MB area) HMA - high memory area (1 MB ... 1 MB + 64k area) CMOS - "Complementary Metal-Oxide Semiconductor" An energy-saving chip technology, some 20 years ago, the CMOS RAM for the setup used only small amounts of energy compared to the rest of the PC. The same chip usually contains the battery powered internal clock (RTC). RTC - Real Time Clock, what else? BIOS - Basic Input Output system (kind of an elementary operating system, or better, a collection of drivers for keyboard, disks, and so on). RAM - random access memory ROM - read only memory MB - megabyte (1024*1024 byte, or 1000*1000 byte, depends ;-)) Computer people normally prefer units of 1024. GB - gigabyte (1000 or 1024 MB) TB - terabyte (1000 or 1024 GB). Be warned, LBAcache maxes out at 2 TB disk size ;-). > RTC versus CMOS part is by Alain Feel free to make a technote of this, and feel free to correct errors. But please do not cite the whole FAQ when doing so! This FAQ is meant to help with "which driver should I use" questions. Most drivers can be finetuned with command line options, but usually run fine without. Read the documentation of the respective drivers for more information (Hey, having some URLs here would be nice ;-)). Cheers, Eric *** BARTs PRACTICAL FAQ *** Some practical decision guidelines by Bart Oldeman: if you have only an XT (8088) there is nothing you can do, except for removing drivers, reducing BUFFERS etc. ~500000 bytes free, not more. if you have an AT (286) with a fair amount of memory (at least more than 640k) then you can use for CONFIG.SYS a) DOS=HIGH DEVICE=FDXMS286.SYS and use the XMS-swapping command.com. That way you have ~620000 bytes free, but all drivers you load (ctmouse, nansi, ...) are going to be in conventional RAM, thus eating from those 620000 bytes. if you have a 386SX or better _and_ you want to run DOS32 programs and none of your programs need EMS then you can use b) DOS=HIGH DEVICE=FDXMS.SYS (<64M) or DEVICE=FDXXMS.SYS (>64M memory) or DEVICE=HIMEM.EXE (is FreeDOS EMM386 compatible, while FD[X]XMS is not) and use the XMS-swapping command.com. The situation for DOS memory is the same as for a) > Tom adds a comparison of the amount of free memory: > DEVICE=HIMEM available memory 631904 byte > DEVICE=FDXMS286 available memory 631712 byte (but mem /f crashed!) > DEVICE=FDXMS available memory 631488 byte > DEVICE=FDXXMS available memory 631072 byte Now if you don't want those drivers eating away from conventional RAM then you can use c) DOS=HIGH,UMB DEVICE=HIMEM.EXE DEVICE=EMM386.EXE DEVICEHIGH=C:\BIN\NANSI.SYS ... SHELLHIGH=COMMAND.COM BUT then you cannot use DOS32 program (unless you use some other non-free EMM386-like program instead). > Eric adds: For example you can use DR-DOS EMM386. May be limited > to 64 MB in some cases. Just run it like DEVICE=DREMM386.EXE > and it should be fine. Adding a DREMM386 PIC=ON to your autoexec.bat > will increase compatibility. Free for non-commercial use. Does not > need HIMEM (most other *emm386*.exe do need himem or fdxms or...). > In any case, all c) variants give you EMS -and- UMB. You can tell > your favourite emm386 program not to provide EMS, this will give > you some more UMB (64k more). This "64k more hint" is by Tom: > use "DEVICE=EMM386.EXE NOEMS". Useful as only few programs need EMS. > For eaxmple this is useful with network drivers. The technique with UMBPCI is a variation between b) and c) and looks like this d) DOS=HIGH,UMB DEVICE=FDXMS.SYS (<64M) or DEVICE=FDXXMS.SYS (>64M memory, for 386 or newer) or DEVICE=HIMEM.EXE (versatile, but only for 386 or newer) DEVICE=UMBPCI.SYS DEVICEHIGH=C:\BIN\NANSI.SYS ... SHELLHIGH=COMMAND.COM > Eric adds: With UMBPCI (on 486 or older: try RDOSUMB, HIRAM or URAM > instead of UMBPCI) you have a way to have UMB but no EMS. This only works if UMBPCI supports your motherboard chipset. In this case you have no EMS (unless you get the EMS simulator from Simtel), but you can run DOS32 programs. > Eric adds: But remember that the EMS simulator is very slow. > Another caveat is that DMA (direct memory access) drivers may > crash when using UMBPCI memory: Only occurs with certain chipsets > and UMBPCI comes with a special driver to work around this problem > at least for disk drivers. In general, using the XMS-swapping FreeCOM, situation b) isn't nearly as bad as it used to be. Only if you need a few large device drivers you will get into trouble. *** Matthias Paul and yet another technical mail *** From: Matthias Paul Date: Sat, 26 Oct 2002 22:45:12 +0200 Message-ID: <0.1300007563.967563791-1463792638-1035665240@topica.com> Subject: Re: [fd-dev] Memory management FAQ > This is only a small summary from his mail (by Eric). Matthias explains some technical details on the workings of XMSUMB memory (through the XMS interface, not to be confused with UMB memory which DOS can use more or less directly. "Self-LOADHIGHing" programs like SHARE or CTMOUSE sometimes use XMSUMB. MS DOS and PC DOS usually eat all XMSUMB memory and re-sell it as normal UMS memory. For DOS UMB high loading, use LOADHIGH (in autoexec) or DEVICEHIGH (in config). In general, you should let a program load itself high if it is able to do so and only use LOADHIGH/DEVICEHIGH if not. > Arkady adds that this is not too important for you unless you > are developing a TSR yourself. Matthias also points out that DR-DOS HIMEM.SYS has RDOSUMB/URAM like features for several 286/386 chipsets. This will give you XMSUMB or UMB. It can even use EMS to create UMB. Not practical if you ask me: Normally, you load the XMS driver FIRST, and normally, EMS drivers provide UMB already. Matthias mentions EMMXMA of DR-DOS: This one uses PS/2 XMA memory extension cards to offer EMS. DR-DOS HIMEM.SYS can also - like RDOSUMB/URAM - detect existing RAM in the UMB area and turn it into UMB/XMSUMB. Useful if you can enable some RAM though your CMOS setup. I remember I could do this with a NeAT 386SX chipset... Further, Matthias tells us then DR-DOS HIMEM offers XMS 2.0, while DR-DOS EMM386 has builtin (!) XMS 3.0, as well as partial EMS 4.0 (only 4 pages mapped at a time, but not limited to some frame area). Some versions can map 60 pages (of 16k each), I understand. The EMS 4.0 specs seem to max out at 32 MB, so DR-DOS EMM386 will offer you at most that much EMS. If you use XMS or "raw memory" as well, take care that EMM386 can cause troubles when you have more than 64 MB of RAM -unless- you install an XMS manager that can access all your RAM -before- installing EMM386. You can tell EMM386 of DR-DOS to use memory areas that are meant for ROM or video RAM, to have even more UMB. Use with caution! If your ROM or graphics card does need the memory, you have a problem. The idea is that parts of your ROM are only needed at bootup time, and parts of your graphics RAM are not needed in text mode. > Arkady adds that MS-DOS EMM386 uses a shared "memory pool" that > the user can allocate either as XMS or as EMS, depending on which > is currently needed (I mean, (amount XMS + amount EMS ) < size pool > is fine, no matter how you distribute your needs between XMS and EMS. > I think DR-DOS EMM386 can do this, too.