Path: utzoo!attcan!lsuc!maccs!cs4g6ag
From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn)
Newsgroups: comp.sys.ibm.pc
Subject: Re: EMS
Message-ID: <26255292.20756@maccs.dcss.mcmaster.ca>
Date: 13 Apr 90 04:16:17 GMT
References: <3238@moondance.cs.uq.oz.au>
Organization: McMaster University, Hamilton, Ontario
Lines: 81

In article <3238@moondance.cs.uq.oz.au> iain@batserver.cs.uq.oz.au writes:
$BTW I have a 386 clone with 4M of RAM - 3M extended.

   So the 3M starts at the 1M mark, and the other 384K is probably used
for ROM BIOS and video BIOS shadowing.

$	EMS 4.0 Simulator, Ver. 1.1 (C) 1989 Ziff Communications
$	PC Magazine + Douglas Boling

   Unless this has been made aware of the 386 (and I don't know if it
has or not), this is not a good choice.  If it is not 386-aware, then
it performs its task by copying chunks of memory from extended into
conventional (i.e. SLOW and eats up 64K of your main memory) and it
will return to real mode via a CPU reset (yech!  SLOW!).  Of course, if
it does recognize a 386, that's no problem.

$The documentation I have says that if no parameter is given to the
$driven at startup, 384K will be used as a default. This suggests to me
$that if the driver is installed with no parameters, the 384K of memory
$above the 640K waterline will become expanded memory. Does this make
$sense - isn't the video buffer located in this part of memory? Also,

   This is likely not correct for three reasons:

1.  Your other 384K is probably being used for shadowing of ROMs, so the
    384k it mentions will be from the upper 3M
2.  Most boards, if they don't do shadowing, don't map any of the memory
    into the 640K-1M region; instead, you'd have 3M + 384k starting at
    the 1M boundary.  The fact that you only have 3M there suggests to
    me that the rest is being used for shadowing.
3.  Extended memory is usually allocated from the top of memory downwards,
    so it would take the last 384k of extended memory.  This is because
    the only support for extended memory in the original AT is a word that
    says how much there is ... so programs will take the highest chunk
    they can find and then change this word so that other programs which
    come along later will think there's less than there is.

   The video buffer is located in that region ... addresses A0000 through
BFFFF are reserved for video RAM.  Also, ROM BIOS and BIOS extensions
such as those found in video cards go in the upper 256k of memory, as do
network adapters and anything else that needs to have some of its
on-board memory mapped into the memory address space.

$what happens when the ROM BIOS is relocated to RAM - where is it
$typically relocated to. Again if its somewhere above the 640K mark, and
$I've installed the EMS driver with no parameters, won't I have big
$problems?

   I would imagine that the ROM BIOS is copied to RAM at the same location
the BIOS used to be at.  This is by far the simplest solution, since it
avoids problems such as having to relocate the code as you move it (and
try doing that with binary code!)

$On a related point, my old version 3.4 driver is ~10K bigger that the
$new version 4.0 job (i.e. length of .SYS file), but the new driver uses
$~50K more low memory that the old one. I think the old driver used
$memory above 640K as a frame buffer for EMS memory. I can only guess
$that this new driver is using memory below 640K. Does this sound
$reasonable? This is fairly concerning because 50K of low memory is quite
$a slab. Again, advice/comments welcome.

   Yes, this is in fact what is happening.  This driver must not be
aware that it's running on a 386.  The 386's built-in memory management
unit can map 4k pages of memory from anywhere in the address space to
any other place - which means that it can map selected 16k EMS pages
from anywhere in the extended address space into gaps in high memory,
exactly emulating hardware EMS.  EMS40, however, assumes it's running
on a 286, which can't do this, so it eats about 70k of low memory, which
includes 64k that's used as the page frame, and it copies stuff back
and forth between the actual location in extended memory and the
apparent location in low memory.  This is the only way to do it in
software on a 286, but is exceptionally inefficient given what the 386
is capable of.  I'd strongly advise you to ditch this driver and buy
one of the commercial drivers for the 386 (they aren't very expensive)
that does a much better job.

-- 
               More half-baked ideas from the oven of:
****************************************************************************
Stephen M. Dunn                               cs4g6ag@maccs.dcss.mcmaster.ca
     <std_disclaimer.h> = "\nI'm only an undergraduate ... for now!\n";