About me

Vladimir Nabokov

Books
Programming
Biochemistry
Aim | Communicate

Search
 


 
   
Letters from Terra - Life in water warmed by sunlight
 
 

     
 
 

     
The only way to store large amounts of data in a large program is to use the effectively limitless resource of extended memory - Click here to download
 
 
     

EMS and XMS memory units

A massive problem with real mode programming, and one that has dogged computing from the very earliesyt days, is the archaic structure used to manage the memory systems. Due to the 16-bit addressing system, in real mode only one megabyte of memory can ever be accessed at a particular time; so effectively limiting the working memory of simple applications to this allowance, minus of course the DOS drivers and OS, the program itself, the stack size, other variables, and most irritatingly windows itself. This places enormous strains on the programming, and creating even fairly straitforward application becomes nightmarish when these limits first begin to manifest themselves. The irony, of course, is that most modern machines have more memory than your average pascal programmer could ever use; it's just immensly difficult to access. Additional memory is managed in two ways; confusingly, they have remarkably similar names and almost interchangable abbreivations. Expanded memory (EMS) uses an arachaic upper memory block as a reading frame to access one particular block of additional memory at a time, allowing extra data to be stored and recalled, albeit sequentially. EMS is comparatively easy to implement and was certainly the most attractive option when I was first investigating these matters; allocating, mapping and utilising EMS is refreshingly straitforward. There are immediate, and critical, problems associated with a dependence upon EMS for your programs. The first is that many computers, even if they have copious additional memory, may have no driver support for EMS - it is simply not required for windows programs - and so many computers will not allow you to access it at all. Secondly, the reading frame mechanism is somewhat slow, and requires further provision within your program for a controlling device for the switching of pages of EMS in and out of the reading frame; and is catastrophically slow if diverse or disparate data needs to be accessed. Even if it si available, EMS tends to be much more limited than XMS by windows, and this can sometimes cause problems. The second method for making use of this memory is the more modern Extended memory, or XMS, specification. This again relies upon a reading frame, but in this case it is resident in the physical conventional memory itself, allowing you to upload data directly and immediately from any part of the the conventional memory to any part of the XMS, as well as the reverse process. This is a fast procedure, and allows access and modification of XMS much in the same manner as conventional memory, with the minor addition of the tranfer commands. XMS usually encompasses the entire compliment of memory installed as hardware, and so up to 100 MB can become available to you for use in your programs: it is also almost universally supported, and is utterly reliable. I offer on these pages two of the most refined and easy to use EMS and XMS memory units, that can be faciley added to your program by inclusion as a unit, available on the internet. These were originally downloaded by myself as part of extended investigation into EMS and XMS, but I found these the easiest to implement by some distance. Indeed, these are the units that power the automatic EMS and XMS facilities of my graphics engines, and have been included in most of my major projects. Each download is availbale with full source and instructions, as well as original desginers notes. I hope all this is of some use, Jon

Download the XMS library (9 Kb, zipped)
Download the EMS library (5 Kb, zipped) | Back to Units & Tools

 
 
Letters from Terra | Updated 15th December 2004 | By Jonathan Ayling