On Sun, 01 Jul 2007 12:13:36 -0700,
igottawang@yahoo.com wrote:
>On Jul 1, 7:18 am, "glee" <gle...@spamindspring.com> wrote:
Time for a PCR-style "master post"
>> Are you sure its upper memory, not expanded memory, that you need?
Let's start by running through DOS's different types of memory. It
all started when IBM stuck the ROMs in the top of the then-1M memory
map... <swimmy "back-in-time" effect>
Real mode, PC/XT era
DOS was originally written for 8086 and 8088 processors that extended
16-bit registers to 20-bit memory addresses, i.e. up to 1M.
IBM stuck the ROMs starting from 640k in this space. There are little
puddles of unused (and usable) RAM between these ROMs in the 640k to
1M range, but as they aren't contiguous, DOS won't use them (yet).
Expanded Memory (EMS)
In this era, a "killer app" was Lotus 1-2-3, which ran spreadsheets in
RAM. But RAM was a limiting factor in spreadsheet size, so Lotus,
Intel (or was it IBM?) and Microsoft (the "LIM" group) came up with
Expanded Memory standard. This was a physical card that added extra
RAM chips, which were paged into the existing address map through an
"EMS frame", i.e. a 64k "hole" between the ROMs above 640k.
Extended Memory (XMS)
286 processors offered a new mode whereby RAM > 1M could be accessed,
and some OSs (OS/2 the First, PICK) made use of this. DOS added a
memory manager called HiMem.sys that could provide eXtended Memory
Services (XMS) to parts of DOS, and apps that knew what to do with it.
High, UMB and Emm386 EMS
386 processors were THE breakthrough - they allowed physical address
ranges to be mapped as if they were actually somewhere else!
It was now that "real" OSs started coming out; OS/2 "part 2", Windows,
Netware, better PICK and UNIXes, NT, etc.
DOS added the Emm386.exe memory manager which could be used with
HiMem.sys, and this applied the ability to remap RAM in various ways:
- to emulate the old physical EMS standard
- to access loose puddles of RAM < 1M as Upper Memory Blocks (UMB)
- to access the first bit of RAM over 1M as if it were below (High)
These things were controlled by startup parameters on the Config.sys
line that ram Emm386.exe; RAM = EMS, NoEMS = No EMS. Without EMS,
there was more UMB space to be used as "conventional" memory.
UMB and High memory access were controlled via the Config.sys DOS
statement, as in DOS=High,UMB - but requires Emm386.exe to work.
DPMS
Late in the DOS era, DOS games needed more memory just as Lotus 1-2-3
had done before, and a standard called DOS Protected Mode Services
(DPMS) was evolved. Games like Doom, Duke Nukem 3D etc. would run
using a DPMS manager, which basically allowed the "DOS" game to be
written as big flat slabs of 32-bit-addressing code.
Windows 9x
When Windows 9x is running, memory management is taken over by that
OS, and the old DOS memory managers are not required (HiMem.sys is
auto-loaded, Emm386.exe is not, and WinME builds HiMem.sys in).
Win9x natively provides EMS, XMS and DPMS services, but does not allow
DOS apps to access UMB and (AFAIK) High memory, as those are used by
Windows instead. There's geneerally enough conventional (i.e. seen by
DOS as unfragmented < 1M RAM) memory for DOS apps that don't get too
specific about how they do things, plus memory can be paged to swap.
However, if your DOS app needs explicit access to UMB and/or High, you
need to reserve this by using Emm386.exe in the Config.sys that will
be in effect when Windows 9x boots up. If you add that line, you also
have to precede it with an explicit line to load HiMem.sys as well.
Note that the above is not possible in WinME, because WinME has
sludged this part of the boot process into one big lump of glue.
>> According to the old MoM FAQ, it needs 2700KB of EMS.
http://www.gamefaqs.com/computer/doswin/file/564960/2059
EMS is supported natively by Win9x, so maybe all you have to do is set
the Properties of the .PIF (shortcut) to allocate that to the process.
Rt-click the shortcut (or the DOS executable diorectly, which will
spawn a .PIF there) and go to the Memory tab, then select what you
want to pre-allocate from the various drop-downs there.
EMS is slow and clunky, but some games do sometimes use it to buffer
sound, as far as I could figure. XMS and DPMS much faster than "real"
EMS, and probably "cleaner" to code for in the 386 age anyway.
>> Glen Ventura, MS MVP Shell/User, A+http://dts-l.org/http://dts-l.org/goodpost.htm
>>
>> <igottaw...@yahoo.com> wrote in message
>>
>> news:1183290012.252372.20350@c77g2000hse.googlegroups.com...
>>
>> > Hi, I've recently been trying to get the multiplayer shell for Master
>> > of Magic to work. However, I have been unable to get enough required
>> > upper memory to run it.
By "upper memory", do you mean:
- EMS -> edit .PIF Properties, Memory
- XMS -> edit .PIF Properties, Memory
- DPMS -> edit .PIF Properties, Memory?
- UMB -> must use HiMem.sys and Emm386.exe
- High -> must use HiMem.sys and Emm386.exe
>> > When I do enable upper memory, however, all of it is taken up by
>> > "vmm32"! How do I stop vmm32 from accessing my upper memory?
In Win9x GUI, Vmm32.vxd will use that space (as seen by DOS Mem
command) unless it's been reserved via Emm386 in Config.sys
In DOS mode, there are no Win9x services or code available, so it's
back to HiMem.sys and Emm386.exe just like the old days.
Is this a DOS or a WIndows game?
If DOS, can you play from DOS mode instead of Windows?
That would avoid having to pollute Windows with DOS memory
(mis-)management, as I would generally try to do ;-)
>Well, it's not the GAME that needs upper memory... it's the
>multiplayer shell. (because I want to play hotseat with my brother) I
>need at least 60K of free upper memory. I've read all your links but
>still can't seem to figure out how to stop vmm32 from accessing all
>the upper memory I have. Once I enable upper memory, vmm32 just soaks
>it all up!
>--------------- ---- --- -- - - - -
I'm baaaack!
>--------------- ---- --- -- - - - -