Chip 2004 July/CMCD0704.ISO/Software/Complet/FreeDOS/fdbootcd.iso/FREEDOS/DOCS/MOREINFO/MEMFAQ.TXT

Text File | 2004-01-31 | 14.0 KB | 326 lines

This document combines several mails that wandered around in fd-dev
(@topica.com) during October 2002. Editing done by Eric.

It's getting quite old, especially regarding the driver development advances
made in the last months.

For configuration of FreeDOS's config.sys and autoexec.bat files,
please have a look at config.txt
(c:\fdos, or in \freedos\packages\disk04\samcfg.zip)

*** 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 / himem: offer XMS and HMA on 386 PCs, up to 64 MB.
fdxxms: offers XMS and HMA, up to 2 GB RAM can be used.
DR DOS himem: like himem.
MS DOS himem: like himem.


*** EMS ***


FreeDOS emm386: offers EMS and UMB, but no VCPI. Read the warning above.
   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.
The FreeDOS emm386 does not allow you to access RAM > 64 MB inside the
DOS task, so if you first load fdxxms on your 512 MB system and then
FreeDOS emm386, fdxxms may become confused about the vanished RAM.

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 (if you feel like it)
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)
or DEVICE=HIMEM.EXE (if you feel like it)
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 <[e-mail]>
Date: Sat, 26 Oct 2002 22:45:12 +0200
Message-ID: <[e-mail]>
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 builtion (!) 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 do 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.