Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!brahms!phil
From: phil@brahms.amd.com (Phil Ngai)
Newsgroups: comp.sys.ibm.pc.misc
Subject: Re: EMS hardware vs. software emulation
Message-ID: <1991Jan9.221816.9381@amd.com>
Date: 9 Jan 91 22:18:16 GMT
References: <37694@cup.portal.com>
Sender: usenet@amd.com (NNTP Posting)
Organization: Advanced Micro Devices, Inc; Sunnyvale, CA
Lines: 34

In article <37694@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes:
|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.  At first, I thought maybe only

386 and 486 need only a software package like 386Max or QEMM because
they already have an MMU.

Generic 286s do need external hardware help to implement EMS.
AMD's Lonestar PC/AT on a chip has an on-chip MMU, similar
in flavor to the 386 MMU, for exactly the reasons you give.

|the 286 needs it, because the other chips have paging.  But then I remembered
|that all the DOS people run in real-address mode, so the paging mechanism
|is disabled.  The only way around this would be to run your DOS applications
|in virtual-8086 mode, but I don't think anybody does that, do they?

I believe you can turn on the 386 MMU without going all the way to virtual
8086 mode. In any case, I personally use QEMM and it works just fine.

|Am I right?  Is omission of the EMS hardware in a 2/3/486 >1M system
|a cardinal sin?  The reason I ask is that there are chipsets on the
|market for building PC-compatible system boards with for example
|a 386 and 16M but don't have hardware EMS.  Does that mean any memory
|above 1M is mostly useless (i.e. real slow due to software EMS emulation)?

Aside from the issues mentioned already, you're also assuming EMS is much
more useful than extended memory which is not true. Most of the time I use
Windows 3 which uses extended memory. (but almost all of the time I use QEMM
to load network device drivers high)

--
seifert@asylum.sf.ca.us is responsible for the
Ethernet slide latch.