Newsgroups: comp.sys.ibm.pc.misc
Path: utzoo!utgpu!barry
From: barry@gpu.utcs.utoronto.ca (Barry Lay)
Subject: Re: Command.com in ramdisk
Message-ID: <1991Apr25.161248.18791@gpu.utcs.utoronto.ca>
Organization: UTCS Public Access
References: <cs352a41.672535168@zippy> <9o8X13w164w@graphics.rent.com>
Date: Thu, 25 Apr 1991 16:12:48 GMT

I have seen a number of remarks concerning 384k above the 1 meg line and what
it is good for.  While I also agree with the suggestion that a disk cache is
probably the best because of the overhead of a XMS-EMS driver, I did notice
some misinformation.  For example, it was suggested that the 64k frame for
EMS emulation had to go into conventional memory (below 640k).  This is not
true.  Most emulators (such a QEMM, 386^MAX, even Windows, I think) will
attempt to find a 64k window in the system area, between 640k and 1 meg.  As
most people don't have half a dozen different kinds of monitors or network
cards installed in their machines, this is usually possible.  On a 386
machine this can be achieved by remapping some of the 384k extended memory
below the line.

Another opportunity for some extra space is to use the 64k-16 above the line
for TSRs etc., as it is accessable from real mode.  This is available on 286s
and up because the highest value for the real mode segment register is
0xffff, which points to an area sixteen bytes below the top.  A sixteen bit 
offset register will take you almost 64k into new territory.  Under normal
circumstances this area is not accessable from real mode as the A20 line on
the processor is normally gated off so that such memory accesses will wrap
around to the bottom of memory, which is exactly what a 8088 will do.  The
HIMEM program (and probably QEMM as well) allows an application program to
toggle the A20 gate so that TSRs or whatever can be loaded up there.  
Microsoft does warn that there are programs out there which assume that the
wrap-around occurs, so you may experience curious results.

Most of this information came from Microsoft's XMS specification which is
available from Compu$erve in the Microsoft area.  I am not sure why there 
isn't a version of HIMEM which installs itself into the first 64k of extended,
but as there is source code for HIMEM (in assembler, unfortunately), there is
no good reason why someone couldn't write one.  I am also unaware of any
programs which expect wraparound on high memory access, and it doesn't
really make any sense to me to do such a thing.  Probably something in DOS,
as Microsoft makes special mention of it :-)  Anybody know for sure?

Barry
