[comp.sys.ibm.pc.misc] Extended and Expanded memory

wind@rruxi.bae.bellcore.com (Wind Chen) (08/15/90)

LIM 3.2 and LIM 4.0 are two different thing, they are not compatible.
To use LIM 4.0, you will need hardware support, if you EMS board didn't say it
supports LIM 4.0, chances are, it does NOT support.

rl@cbnewsl.att.com (roger.h.levy) (08/18/90)

In article <26045@bellcore.bellcore.com>, wind@rruxi.bae.bellcore.com (Wind Chen) writes:
> LIM 3.2 and LIM 4.0 are two different thing, they are not compatible.
> To use LIM 4.0, you will need hardware support, if you EMS board didn't say it
> supports LIM 4.0, chances are, it does NOT support.

Yes they are different but most of the rest is untrue.  From the Waite Group's
MSDOS Developer's Guide:

	The user does not have to buy any new hardware to use applications
	that are written to the LIM EMS 4.0 specification.  Older expanded
	memory boards designed for the LIM EMS 3.2 specification can
	support the 4.0 specification - the manufacturer just has to write
	a new EMM to implement the 4.0 function calls.

Established manufacturers such as AST do just this sort of thing.  Also, the
LIM 3.2 function calls exist in LIM 4.0 but 4.0 has more of them.  I would
call that "upward compatible" rather than "not compatible."

liberato@drivax.UUCP (Jimmy Liberato) (08/20/90)

rl@cbnewsl.att.com (roger.h.levy) writes:

>In article <26045@bellcore.bellcore.com>, wind@rruxi.bae.bellcore.com (Wind Chen) writes:
>> LIM 3.2 and LIM 4.0 are two different things, they are not compatible.
>> To use LIM 4.0, you will need hardware support...
>>...

>Yes they are different but most of the rest is untrue.  From the Waite Group's
>MSDOS Developer's Guide:

>	The user does not have to buy any new hardware to use applications
>	that are written to the LIM EMS 4.0 specification.  Older expanded
>	memory boards designed for the LIM EMS 3.2 specification can
>	support the 4.0 specification - the manufacturer just has to write
>	a new EMM to implement the 4.0 function calls.

>Established manufacturers such as AST do just this sort of thing.  Also, the
>LIM 3.2 function calls exist in LIM 4.0 but 4.0 has more of them.  I would
>call that "upward compatible" rather than "not compatible."

Both of these comments are correct in a way.  Though I can add a manufacturers
new 4.0 driver to a 3.2 board and gain some features, there does seem to be
a subclass of 4.0 that lacks the hardware dependent features of "genuine" 4.0
such as backfilling and mutitasking capabilities.  There are tons of Everex
boards out there that fall into this nether region.  Rule of thumb: if it is
inexpensive it is a 3.2 board with a 4.0 driver.  Almost all newer model EMS
boards are now 4.0 at the hardware level.  AST had it easy because their EEMS
standard used on the Rampage included the hardware dependent features
appropriated by the 4.0 standard.  Hence, a four year old Rampage board with a
4.0 driver is the equivalent of a contemporary 4.0 board.

--
Jimmy Liberato   liberat@dri.com
                 ...uunet!drivax!liberato

portuesi@tweezers.esd.sgi.com (Michael Portuesi) (08/20/90)

>>>>> On 18 Aug 90 11:04:04 GMT, rl@cbnewsl.att.com (roger.h.levy) said:

> In article <26045@bellcore.bellcore.com>, wind@rruxi.bae.bellcore.com (Wind Chen) writes:
>> LIM 3.2 and LIM 4.0 are two different thing, they are not compatible.
>> To use LIM 4.0, you will need hardware support, if you EMS board didn't say it
>> supports LIM 4.0, chances are, it does NOT support.

> Yes they are different but most of the rest is untrue.  From the Waite Group's
> MSDOS Developer's Guide:

> 	The user does not have to buy any new hardware to use applications
> 	that are written to the LIM EMS 4.0 specification.  Older expanded
> 	memory boards designed for the LIM EMS 3.2 specification can
> 	support the 4.0 specification - the manufacturer just has to write
> 	a new EMM to implement the 4.0 function calls.

> Established manufacturers such as AST do just this sort of thing.  Also, the
> LIM 3.2 function calls exist in LIM 4.0 but 4.0 has more of them.  I would
> call that "upward compatible" rather than "not compatible."

Okay, my question is:

	Is LIM-EMS 4.0 implemented in software on 3.2 hardware
	equivalent to LIM-EMS 4.0 on 4.0 hardware in both features and
	performance?

The reason why I ask this is that I am currently running DESQview 2.26
on my Toshiba T1000XE laptop computer.  It has an 80C86 and 2.4 MB of
EMS memory.  The Toshiba docs say that the hardware is 3.2, and that
the EMS driver supports LIM-EMS 4.0.  But DESQview certainly isn't
behaving like there is EMS 4.0 in the machine (yes, I am using XDV).

I understand that a big difference between 3.2 and 4.0 is that 4.0
provides a much greater range of places where the expanded memory can
be mapped into conventional memory.  How is this done in software for
3.2 boards?  By copying data all over the place?  Yuck.

				--M
--
__
\/  Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com

    "man, this is weak."

jwbirdsa@amc-gw.amc.com (James Birdsall) (08/21/90)

In article <1990Aug18.110025.28644@cbnewsl.att.com> rl@cbnewsl.att.com (roger.h.levy) writes:
>In article <26045@bellcore.bellcore.com>, wind@rruxi.bae.bellcore.com (Wind Chen) writes:
>> LIM 3.2 and LIM 4.0 are two different thing, they are not compatible.
>> To use LIM 4.0, you will need hardware support, if you EMS board didn't say it
>> supports LIM 4.0, chances are, it does NOT support.
>
>Yes they are different but most of the rest is untrue.  From the Waite Group's
>MSDOS Developer's Guide:
>
>	The user does not have to buy any new hardware to use applications
>	that are written to the LIM EMS 4.0 specification.  Older expanded
>	memory boards designed for the LIM EMS 3.2 specification can
>	support the 4.0 specification - the manufacturer just has to write
>	a new EMM to implement the 4.0 function calls.
>
>Established manufacturers such as AST do just this sort of thing.  Also, the
>LIM 3.2 function calls exist in LIM 4.0 but 4.0 has more of them.  I would
>call that "upward compatible" rather than "not compatible."

   While true, it isn't quite the whole story. Yes, it is possible to write
a LIM 4.0-spec driver for a LIM 3.2-spec board. My EMS board is just such a
beast and it works just fine.

   HOWEVER, a board with LIM 4.0 HARDWARE support can support more than
four 16K page frames (using the term loosely) and can map memory anywhere
in the 1M address space. A board built for LIM 3.2 can, with the proper
drivers, run 4.0, but it is still limited to the four page frames in a 64K
block which 3.2 specified.

   An example:
   Quarterdeck recently came out with a product called QRAM, which provides
some of the benefits of QEMM for those with 8086/8 and 80286 systems. It
requires LIM 4.0. While I have not actually inspected QRAM, it seems
reasonable to suspect that they are mapping pages into unused parts of high
memory, loading drivers/TSRs/whatever into them, then leaving the pages
mapped that way -- meanwhile leaving enough space unmapped that applications
have some places to use as  page frames. If this is indeed what they are
doing, they're probably going to get a lot of unhappy calls from people
with LIM 3.2 retread boards whose hardware can't support full 4.0.
   And there isn't a good way for the average user to even TELL if their
board is a retread or 4.0 hardware. The driver, if it displays a message at
all, probably says "LIM EMS 4.0". Mine does. I only know that it is a
retread because I've actually written EMS-using programs which queried the
driver about number of frames, addresses, etc.
   So the average user is going to look at their docs, say "It sez 4.0",
buy QRAM, and be very annoyed if they turn out to have a retread board. I
salute Quarterdeck for putting out a product which, even if it works
perfectly, is still going to cause them a lot of customer-support grief.
   And if QRAM has a way around this problem or does something else
entirely, please enlighten me.


-- 
---
James W. Birdsall        jwbirdsa@amc.com         71261.1731@compuserve.com
          Compu$erve: 71261,1731            GEnie: J.BIRDSALL2
For it is the doom of men that they forget. -- Merlin

phil@brahms.amd.com (Phil Ngai) (08/22/90)

In article <PORTUESI.90Aug20125512@tweezers.esd.sgi.com>
portuesi@sgi.com (Michael Portuesi) writes:
|Okay, my question is:
|
|	Is LIM-EMS 4.0 implemented in software on 3.2 hardware
|	equivalent to LIM-EMS 4.0 on 4.0 hardware in both features and
|	performance?
|
|The reason why I ask this is that I am currently running DESQview 2.26

The answer, particularly given that you are running DV, is NO!

The LIM 4.0 spec was written by a committee with many vested interests
to protect. It therefore came out with so many optional features
as to be almost useless as a standard (unless you are a vendor with
lots of 3.2 hardware you don't want to write off).

To run DV, several of the "optional" features are mandatory and
you seem to be aware of this.

|on my Toshiba T1000XE laptop computer.  It has an 80C86 and 2.4 MB of
|EMS memory.  The Toshiba docs say that the hardware is 3.2, and that
|the EMS driver supports LIM-EMS 4.0.  But DESQview certainly isn't
|behaving like there is EMS 4.0 in the machine (yes, I am using XDV).

Unfortunately, you are correct. DV is rather painful to use on such
a configuration. The best and most trouble-free platform to run DV
on is a 386 with QEMM. (but you might try turning on swapping if you
simply want DV as a task switcher)

|I understand that a big difference between 3.2 and 4.0 is that 4.0
|provides a much greater range of places where the expanded memory can
|be mapped into conventional memory.  How is this done in software for
|3.2 boards?  By copying data all over the place?  Yuck.

I believe the feature of 4.0 you are referring to is "optional" and
so 3.2 boards with "4.0" drivers simply refuse to perform the operation.

--
Phil Ngai, phil@amd.com		{uunet,decwrl,ucbvax}!amdcad!phil

phil@brahms.amd.com (Phil Ngai) (08/22/90)

In article <2774@amc-gw.amc.com>
jwbirdsa@europa.amc.com (James Birdsall) writes:
|   So the average user is going to look at their docs, say "It sez 4.0",
|buy QRAM, and be very annoyed if they turn out to have a retread board. I
|salute Quarterdeck for putting out a product which, even if it works
|perfectly, is still going to cause them a lot of customer-support grief.
|   And if QRAM has a way around this problem or does something else
|entirely, please enlighten me.

QRAM is for the purpose of relocating network drivers and such. It
will work either with full 4.0 or with the C&T NEAT chipset (by using
the shadow RAM feature, I believe) Since the latter is a large part of
the market, QRAM will be useful for many customers. (but I don't know
how QRAM interacts with Windows 3.0)

DesqView, on the other hand, is nearly useless without FULL 4.0,
either implemented in hardware or with QEMM-386.

--
Phil Ngai, phil@amd.com		{uunet,decwrl,ucbvax}!amdcad!phil

portuesi@tweezers.esd.sgi.com (Michael Portuesi) (08/23/90)

>>>>> On 22 Aug 90 03:20:56 GMT, phil@brahms.amd.com (Phil Ngai) said:
> In article <PORTUESI.90Aug20125512@tweezers.esd.sgi.com>
> portuesi@sgi.com (Michael Portuesi) writes:
> |Okay, my question is:
> |
> |	Is LIM-EMS 4.0 implemented in software on 3.2 hardware
> |	equivalent to LIM-EMS 4.0 on 4.0 hardware in both features and
> |	performance?
> |
> |The reason why I ask this is that I am currently running DESQview 2.26

> The answer, particularly given that you are running DV, is NO!
> To run DV, several of the "optional" features are mandatory and
> you seem to be aware of this.

Seems like I'm out of luck, then.  Though I'd like to point out that
DV still runs just fine on my machine with EMS 3.2; it's just that
many of DV's more powerful features aren't available.

> Unfortunately, you are correct. DV is rather painful to use on such
> a configuration. The best and most trouble-free platform to run DV
> on is a 386 with QEMM. (but you might try turning on swapping if you
> simply want DV as a task switcher)

[from another message...]

> DesqView, on the other hand, is nearly useless without FULL 4.0,
> either implemented in hardware or with QEMM-386.

DV works great for me as a task-switcher, which was all I really
bought it for anyway.  I got it for $80, which is pretty good deal
compared to the $50 fee on the shareware task-switching package I had
previously evaluated and discarded (Back and Forth).

I wouldn't go so far as to say DV is nearly useless without full EMS
4.0.  It can mulitask DOS programs, if they'll all fit into 640K.
This isn't so bad if one or more of your apps uses EMS to store their
data and hence can run in very little conventional memory.  It still
uses EMS to allow task-switching many more programs than could fit
into 640K at once.  DV also provides a keyboard macro facility, a
cut-and-paste mechanism between programs, a windowing facility for DOS
programs, and a nice top-level interface to get at all of your
applications.

DV is certainly a better alternative to wasting memory and inviting
conflicts by using TSR programs such as SideKick to mimic the same
functionality.  Even on an 386, DV doesn't turn your PC into an Amiga,
but I think it's worth the money no matter what hardware you currently
have.

				--M
--
__
\/  Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com

    "every now and then things become clear" -- jane siberry

phil@brahms.amd.com (Phil Ngai) (08/24/90)

In article <PORTUESI.90Aug23104340@tweezers.esd.sgi.com>
portuesi@sgi.com (Michael Portuesi) writes:
|Seems like I'm out of luck, then.  Though I'd like to point out that
|DV still runs just fine on my machine with EMS 3.2; it's just that
|many of DV's more powerful features aren't available.

Yes, you can run DV but if you want to do real multi-tasking, as
opposed to just task switching, then you either have to stick to
very small programs or have real 4.0. (and I know you know this,
I'm just clarifying my posting)

|I wouldn't go so far as to say DV is nearly useless without full EMS

Perhaps I was a little extreme. (but at least I didn't say it
was completely useless!) Nearly useless was my reaction when I
discovered the difference between what I had expected and what
I could actually do on a 286 NEAT system. I went on to get a 386
and QEMM and was happy with that.

--
Phil Ngai, phil@amd.com		{uunet,decwrl,ucbvax}!amdcad!phil