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: <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