mcc@wlv.imsd.contel.com (Merton Campbell Crockett) (03/24/91)
This will seem like a terribly naive question to many of you--it does to me; however, I would like to understand the difference between extended and expanded memory. I'm sure part of my problem in understanding the documentation provided with my 80286 (home) and 80486 (office) systems is my background. I am and have been a systems programmer on NCR Century series, DECSystem 10, PDP11 series, and VAX series computers. And, with the exception of NCR all have memory management hardware managed by the various operating systems that I've used. In this environment, programs can be loaded anywhere in physical memory but from the program's perspective it's address space always begins at location 0 in its logical address space. (For the nit pickers, thats not entirely correct but will suffice for this discussion.) In writing device drivers, I simply remap the buffers involved into the device drivers address space and either use programmed I/O to transfer the data or set the devices hard- ware registers to access the physical memory associated with the logical memory address of the buffer for a DMA operation. Now, I have this 80486 system with 4 Mbytes of memory. I have MS-DOS 4.01 as an operating system but it only seems to know how to deal with the first 640 Kbytes of memory and the "device" address space between 640K and 1M bytes. To support the various devices and a 210 Mbyte disk, MS-DOS seems to load a significant number of system programs in memory significantly reducing the 640Kbytes it knows about--to the extent I have programs complaining about insufficient space to perform some of their operations. Now with the memory management logic in the 80486 chip it seems that there should be no problem loading these extensions to the operating system into the memory above 1 Mbyte and have them execute from there. Or for that, load a program anywhere that it will fit and let it execute from there. Now, given the above do I want extended or expanded memory? One memory schema allows me to map memory in 64Kbyte windows but doesn't really allow me to execute code from that segment--or do I have that wrong? Some application software contains logic to utilize memory above 1 Mbyte--do I have to check out each program and compute how much space it will utilize to install the memory management software? I'm sooooo confused! Merton
valley@uchicago (Doug Dougherty) (03/25/91)
jayh@ms.uky.edu (Jay Hofacker) writes: >Extended memory is memory above 1 Mbyte that is directly accessable to an >80286/386/486 in 'protected mode'. When theses chips first boot up they are >in 'real mode' which is completely compatible with the original 8088. In real >mode there is 1 Mbyte of memory total, divided into 64K segments. MS-DOS only >understands real mode, which is why it is limited to 1 Meg (640K because the >video buffer starts at 640K, and the addresses above that are used for ROMs). >In order to access extended memory, an extended memory driver must be used >to switches the chip into protected mode, retrieve the data requested, and >then swap back to real mode. Bzzzzzt. You need no special software drivers to access extended memory. Technically, all you need to do is set a bit in the MSW and away you go. Seriously, there is support in INT 15 to do the simple tasks of storing and retrieving data to/from extended memory. In fact, the so-called "VDISK allocation scheme" is entirely based on INT 15. XMS (i.e., the XMS specification) is a nice thing, but not a necessary thing. (EMS, on the other hand, is a necessary thing) nit pick, nit pick...
mikec@wam.umd.edu (Michael D. Callaghan) (03/25/91)
What I would like to do is load all my TSRs into the memory above 640k. I have a 286 with 1 meg, and when I load my ethernet, TCP/IP, and NFS TSRs into memory, I have less than 400k left, and my major software package no longer has enough room to run. Any suggestions? Someone told me that DOS 4.x would do the trick. I don't know... Thanks, -- MikeC _________________________________________________________ Michael D. Callaghan, MDC Designs, University of Maryland mikec@wam.umd.edu
mcc@wlv.imsd.contel.com (Merton Campbell Crockett) (04/07/91)
First, thanks to the many people who responded to my request for information on extended and expanded memory. I had intended to thank everyone individu- ally but the requirements of work intervened and I didn't get around to it immediately and some that I did get to had "bangland" return addresses which resulted in my mailbox filling with MAILER-DAEMON messages. The confusion, in large part, involves semantics and the documentation pro- vided in the readme files included with the manufacturer's MS-DOS distribu- tion for his IBM PC compatible. Reading the replies evoked a "Back to the Future" response--I had just forgotten many of the details of the transition from single-user, batch oriented operating systems to multi-user, multi- programming, real-time oriented operating systems that I had experienced twenty years ago. As several people pointed out, expanded memory was originally a hardware technique to "expand" the memory available to the 8088, 8086, and 80186 processors which are restricted to a total address space of 1 Mbyte as they only support 20 address lines. Either through direct program control or a device driver the hardware could map any of its 64 Kbyte pages of memory into the 1 Mbyte address space supported by the processors. With the 80286, the processor architecture was changed to "extend" the available address space by providing 24 address lines. This permits 16 Mbytes of memory to be directly accessed; however, the high-order 4 address lines are only enabled when in "protected" mode. [I have a vague recollec- tion from documentation for a Tandy 2000 that I owned that the 80186 did have "support" for 24 address lines but lacked the means for enabling the additional address lines.] Great for the multi-user operating systems--such as OS/2 and XENIX where you don't want users or programs to have direct access to devices or memory outside of their assigned address space--a pain for the single-user MS-DOS environment. With the 80386, the processor architecture was, again, changed to "extend" the available address space by providing 48 address lines. This permits 4 Gbytes of memory to be directly accessed. In the above paragraph I failed to mention that the 80286 did not provide an instruction to disable "pro- tected" mode once it was enabled. In addition to the additional address lines, the 80386 architecture was enhanced to provide instructions to en- able/disable "protected" mode. One respondent pointed out that I probably understood more than I thought. That is probably true, the problem is really with the software solutions to the problems of accessing the expanded/extended memory and the various stan- dards that have been developed for handling/requesting additional memory. You have XMS, EMS, EEMS, LIM, VCPI, etc. standards to choose from which address how a program requests access to expanded or extended memory, how software uses extended memory to emulate the hardware behaviour of expanded memory boards, and how software uses expanded memory to emulate the hardware behviour of extended memory. As a colleague likes to point out: "The nice thing about standards is that you have so many to choose from!" EMS (Expanded Memory Specification) defines the behaviour of expanded memory hardware. I ran accross a reference to an Enhanced Expanded Memory Specifi- cation (EEMS) but don't recall whether it was a hardware specification or a software specification. XMS (eXtended Memory Specification) is a software specification defining the use of extended memory. HIMEM.SYS is the device driver that implements this specification. A second device driver, XMA2EMS.SYS, implements this speci- fication for EMS compliant hardware. LIM (Lotus, Intel, and Microsoft Expanded Memory Specification) is a soft- ware specification that defines the emulation of expanded memory hardware in extended memory. EMM386.SYS is the device driver that implements this spec- ification. VCPI (Virtual Control Program Interface) is another software specification developed by Quarterdeck and Phar Lap which (I think) defines the memory management interface for the virtual 8086 mode introduced with the 80386 and used by windowing software in an attempt to implement a multi-user environ- ment within the MS-DOS single-user environment. Now the fun part begins--matching your hardware capabilities to the memory environment expected by the various programs that you use and attempting to develop a CONFIG.SYS which will maximize the performance of each program without constantly rebooting the system to change your configuration. How much memory does one allocate for each memory standard that is required? Which of the myriad of driver options do I need to use? Are there MS-DOS resource conflicts among the drivers that implement these standards? Do I have programs that have embedded, roll-your-own memory management logic that bypasses any drivers that you install or conditionally bypasses these driv- ers if the wrong one is loaded? Rather than grapple with the task of repetitively changing my CONFIG.SYS, I purchased Quarterdeck's QEMM-386 memory management program after noticing in another discussion thread a comment that it supported all of the above spec- ifications, allocated memory downward from the highest memory address, and didn't require memory for each specification to be physically contiguous. So far, QEMM-386 has lived up to its promised capabilities and my expecta- tions. It has allowed me to move the normally resident MS-DOS extensions which are, in actuality, seldom used into extended memory along with all the Novell software I had to have just to get to a printer. The net result was 120K of "real" memory available for those programs that were developed prior to the introduction of expanded or extended memory or weren't enhanced to make use of the memory. It may be illusory but system performance seems to have improved, as well. Again, my thanks to all who responded to my request for information. Hope- fully, the above is relatively accurate and someone will find it helpful.