Dec 132017
XMEM - Source code to access 80286/386 Extended Memory from Turbo C.
File TC_XMEM.ZIP from The Programmer’s Corner in
Category C Source Code
XMEM – Source code to access 80286/386 Extended Memory from Turbo C.
File Name File Size Zip Size Zip Type
MAKEFILE 374 166 deflated
TC_CPUID.OBJ 131 127 deflated
TC_XMEM.C 9476 3191 deflated
TC_XMEM.EXE 7896 4849 deflated
TURBOC.CFG 37 30 deflated
XMEM.DOC 4887 2287 deflated
XMEM.OBJ 840 581 deflated

Download File TC_XMEM.ZIP Here

Contents of the XMEM.DOC file

XMEM - Access to 80286/386 Extended Memory from Turbo C

(c) 1987 Micro Consulting Associates
868 Ashford Ave., Suite 6B
San Juan, P.R. 00907-1018
(809) 721-8470

The XMEM routine is included here in .OBJ format, small memory model
only. Source is available for the routine for a $30 donation. The source
code is in assembly language (MASM 4.0) and will allow you to modify the
routine for use with other memory models. Along with the source code for
XMEM.OBJ, you will also get a copy of TC_CPUID.ASM, the source code to
the TC_CPUID.OBJ module. This routine allows you to identify any Intel
processor, from 8088 to 80386, from software.

TC_XMEM.C is a demonstration program which shows you how to use XMEM.
There is a full example of how to call the routine along with some
techniques which might prove to be useful if you intend to incorporate
the routine into your programs.

XMEM is a Turbo C callable routine that allows you to transfer up to
64k of data to/from low DOS memory (below 1 meg boundary) and high
memory (above the 1 meg boundary).



Calling format is:

int xmem(source_seg,source_offset,source_meg,dest_seg,dest_offset,
int source_seg,source_offset,dest_seg,dest_offset,size;
char source_meg,dest_meg;


source_seg : Segment where data is located
source_offset : Offset within segment where data is located
source_meg : Megabyte boundary for source data, min is 0 (within DOS
memory), max is 15 (F hex), a value of 1 or more means
data is in extended memory.
dest_seg : Segment where data is to be transferred to
dest_offset : Offset within segment where data is to be transferred to
dest_meg : Same as source_meg, but locates megabyte boundary where
data is to be transferred to
size : Number of bytes to transfer, min is 1, max is 64k


0 = successful transfer
1 = parity error encountered during transfer
2 = exception interrupt error during transfer
3 = 8042 slave processor failure (gate 20 not enabled)
4 =
5 = Invalid megabyte boundary, outside range (0 to 15)
6 = Not enough extended memory
7 = No extended memory installed

Now that you made it through all that, let's ask a simple question:

What do I do with all of this?

You can store data for your programs in expanded memory WITHOUT getting
into EMS or EEMS hardware or software (and therefore making your customers
happy about not having to shell out bucks to make full use of your program.)
Also, it gives you much more flexibility beacuse you do not have to conform
to either the EMS or EEMS standards or to their limitations, such as the page
sizes. You also don't have to worry about changes in the EMS or EEMS specs
or their respective drivers because the service routines for this interrupt
are burned into the ROM! One disadvantage is that after a while your
clock will get a little out of whack due to your taking away its precious
interrupts, but that is certainly not an insurmountable problem for
an enterprising programmer like YOU, is it? (Actually, the trick to that
is to play with the 8253 timer to make up for the lost clock, but I'm under
a non-disclosure agreement from Ronco Vaporware Products, Inc., etc...)

Some ideas for this are:

1) Overlay managers that use expanded memory to store and quickly
access code in overlays (16 megabytes of overlay code, wow!)

2) Spreadsheets that want to make use of up to 16 megabytes of
storage space (talk about your power-user blowing a fuse!)

3) Sorting massive amounts of data FAST! (anybody for sorting
the NYC telephone directory?)

... and so on.

If you wanted to implement the processes defined here in an overlay
manager, for example, you could take all the overlay code and data at the
beginning of execution and store it in blocks in extended memory.
Then, every time you needed an overlay, you just do a transfer from
extended memory into the overlay area. Mem moves are a heck of a lot
faster than disk moves, so, even though you spend a little time setting
up, you more than make up for it in time saved on disk accesses.

The disadvantages of this method for storing data are that it is up to you
to keep track of what is where (though that should not be hard to do, just
use double word variables to store locations of code or data blocks). Also,
you have to adjust the clock once in a while because all interrupts are
disabled or set to dummy handlers during operations in protected mode...
Oh, yes, if you use this you just made your program 80286- or 80386-
specific. No big deal about that, though.

 December 13, 2017  Add comments

Leave a Reply