🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.ibm.pc.misc
Article #6772

Re: EMS hardware vs. software emulation

#6772
From: James Birdsall
Date: Thu, 10 Jan 1991 18:54
78 lines
5018 bytes
In article <1991Jan9.163046.25355@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes:
>>In article <37694@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson)
><It seems to me that anyone who designs a system with a 286, 386, or 486
><with more than 1M of memory should include hardware EMS registers and mapping
><logic, unless he only plans to run Unix.
>
> [...] First 
>of all, EMS is dead.  In several years little or nothing will support it. 

   Very doubtful. History is not so easily discarded. Look at how many
programs still support DOS 2.0. 

> [...] Look at all
>large packages (in price & function/not poplarity), autocad, mathmatica, Splus
>(statistics package which clones a major IBM mainframe package), lotus 3.1.
>All support extended directly, else support extended better than expanded,
>else support extended exclusively.  LArger and more complex packages become
>even more complex, and slower using expanded memory.

   This is true. Part of the reason is that more and more of the very large
packages are running under DOS extenders -- i.e. running in protected mode,
so that there is no more "extended" memory, it's just memory. The memory
requirement is expressed as "extended", because most people will understand
it better when put that way.
   Also, the appearance and rapid spread of the XMS specification is
helping. For all its faults, EMS has had a well-documented and reasonably
uniform interface. Until the XMS specification came along, extended memory
allocation was a howling nightmare with at least two different ways of
doing it, both of which might be in use at the same time! And there was
always the possibility of running afoul of a program which completely
ignored both and did whatever it pleased with extended memory.

>   Extended memory is the best thing under all circumstances.  

   Wrong. There are at least two areas where EMS beats extended memory.
Which is not to say EMS is better overall, but just to raise the point that
nothing is perfect.

1) The most common way of accessing extended memory is to switch into
protected mode briefly, copy bytes to/from conventional memory, and switch
back. On a 386 and up, this is no problem. On a 286, the switch back
involves halting the processor and getting the keyboard to wake it up
again, a process which may take milliseconds and cause lost interrupts.
EMS doesn't have this problem.
   The undocumented LOADALL instruction may be used to access extended
memory from real mode, but that has its own problems. For one, it's
undocumented. Big deal. But I also understand that the descriptor tables
are reset whenever an interrupt is received -- so use of LOADALL requires
that interrupts be turned off for significant amounts of time, too.

2) Space. Unless quite a bit of effort is expended on more sophisticated
methods, extended memory is accessed by copying data to/from it. 
Hence, in order to use data stored in extended memory, it must be
copied down into conventional memory. And if there is no space left in
conventional memory, then something must be swapped out first... etc. Since
the page frame of EMS is totally unrelated to conventional memory (except
for being below the 1M line, except in some pure-software EMS emulators
which are painful to contemplate), EMS does not have a gridlock problem.

>It is completely
>linear and available to anybody that writes software that isn't xt specific.

   Wrong. The 286 still has 64K segments, even in protected mode. Linearity 
(in the form of 4G segments) didn't happen until the 386.

   Actually, this is boiling down to the statement that the 386 is better
than the 286. For the 386, there's no point in doing EMS in hardware since
it can be done so easily in software using any extended memory, and
extended memory is the thing to have since it can be used both as itself
and as EMS. For the 286, extended memory has some serious shortcomings due
to shortcomings in the chip itself. And for anything below that, EMS is
what there is...

-- 
James W. Birdsall   WORK: jwbirdsa@amc.com   {uunet,uw-coco}!amc-gw!jwbirdsa
HOME: {uunet,uw-coco}!amc-gw!picarefy!jwbirdsa OTHER: 71261.1731@compuserve.com
========== "Think of an animal that's small and fuzzy." "Mold." -- RM =========
=========== "For it is the doom of men that they forget." -- Merlin ===========
Technical Details
Message-ID: <4814@amc-gw.amc.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!julius.cs.uiuc.edu!wuarchive!uunet!nwnexus!amc-gw!jwbirdsa
References: <37694@cup.portal.com> <5182@bwdls58.UUCP> <1991Jan9.163046.25355@rodan.acs.syr.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!julius.cs.uiuc.edu!wuarchive!uunet!nwnexus!amc-gw!jwbirdsa
From: jwbirdsa@amc-gw.amc.com (James Birdsall)
Newsgroups: comp.sys.ibm.pc.misc
Subject: Re: EMS hardware vs. software emulation
Message-ID: <4814@amc-gw.amc.com>
Date: 10 Jan 91 18:54:59 GMT
References: <37694@cup.portal.com> <5182@bwdls58.UUCP> <1991Jan9.163046.25355@rodan.acs.syr.edu>
Reply-To: jwbirdsa@europa.amc.com (James Birdsall)
Organization: Applied Microsystems, Redmond, WA
Lines: 78