Dec 152017
Text info on using ems memory.
File EMSSCOOP.ZIP from The Programmer’s Corner in
Category Tutorials + Patches
Text info on using ems memory.
File Name File Size Zip Size Zip Type
CHKMEM.EXE 2072 1184 deflated
EMSSCOOP.TXT 18079 6529 deflated

Download File EMSSCOOP.ZIP Here

Contents of the EMSSCOOP.TXT file

What To Do With
Expanded/Extended Memory
by Mark Petry

So you just laid down some big bucks to add a memory expansion board
to your PC. Spent a whole evening plugging in expensive RAM chips,
setting switches, and scrutinizing arcane details like "enable JP2
serial port with switch SW5 only if IRQ4 desired for port interrupt
level or game port installed." Neat, huh? Now that the box is all
closed up and you are ready to power on, give some thought about what
to DO with all that expensive memory. Most AT extended memory
hardware is provided with some type of support software such as a RAM
disk or print spooler programs, none of which provide (my opinion)
enough of a performance or convienience gain to offset the $200 to
$500 cost of an expansion memory board with a megabyte of RAM. When I
first installed additional memory in a system it took quite a bit of
experimentation to arrive at a configuration that dramtically
increased performance and was very reliable.

"Expansion memory" really is a generic term that deserves some
clarification. DOS is fundamentally limted in being unable to
directly address memory locations above 640k because of the 2-byte
memory addressing scheme used in an 8-bit operating system. The
memory locations between 640k and 1Mb are used principally by disk and
display devices for ROM BIOS extensions and are (generally)
unavailable to the user. The CENV program presents an excellent map
of the system memory and its allocation at locations below 1MB. A
sample screen from this program is shown in Figure 1.

Memory added on expansion boards is usually mapped at locations
beginning at 1Mbyte, though some boards offer an option to "backfill"
the motherboard RAM if less than 640k is installed. If a memory board
is installed on an 8088-class machine, the memory must be configured
as "Expanded Memory." The term refers to a "paging" scheme of memory
management which uses a segment of the memory below 640k as a "window"
through which the expansion memory may be viewed in 64k segments.
This is the so-called EMS or LIM-spec (Lotus/Intel/Microsoft) memory
which may be used by certain programs for manipulating large
spreadsheets, etc. LIM/EMS memory may be implemented as hardware
(with a board so designed) or with software on both XT and AT-class

AT-class machines are also capable of using "extended" memory. This
is memory where ram disks, print spoolers, etc., are installed,
usually with a device driver installed in the system at boot-up. The
RAM disk device driver supplied with DOS 3.X is called VDISK, and a
number of RAMdisk programs are available in the public domain. They
allow a disk device to be simulated in high memory. Just like a
floppy disk device, it isn't used unless specifically called for I/O.

IBM PC Memory Map with 64kb/Line
D = DOS Related . = Empty
* = This Prog. ? = Unused (RAM)
m = Monochrome c = Color/Graphics
b = BASIC (ROM) s = BIOS (ROM)
r = ROM (sum=0) R = ROM (sum<>0)
Seg: 0 1 2 3 4 5 6 7 8 9 A B C D E F
3000: ****************************************************????????????
4000: ????????????????????????????????????????????????????????????????
5000: ????????????????????????????????????????????????????????????????
6000: ????????????????????????????????????????????????????????????????
7000: ????????????????????????????????????????????????????????????????
8000: ????????????????????????????????????????????????????????????????
9000: ????????????????????????????????????????????????????????????????
A000: ................................................................
B000: ................................cccccccccccccccc................
C000: rrrrrrrrrrrrrrrr................................................
D000: ................................................................
E000: ................................................................
F000: ssssssssssssssssssssssssbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbssssssss
Seg: 0 1 2 3 4 5 6 7 8 9 A B C D E F

Figure 1 - Sample CENV Screen
Some users copy frequently-accessed programs to the ram disk at boot-
up with command lines in AUTOEXEC.BAT, or write batch files to do the
same thing when they start a large application. I have found that
copying MS Windows, for example, to a RAMdisk does increase its speed
somewhat, but not so much so as to offset the effort required to
refine the batch file and reconfigure the application for RAMdisk
operation. If the AC power glitches out or you crash the computer,
all your data is lost. I use my RAMdisk to hold a screen-manager
program which is rerun each time an application terminates. The PATH
command in AUTOEXEC.BAT should list the VDISK device **FIRST**:

PATH E:\;C:\;C:10-JAN-88 11:47:00OS:\;......

Some of the low-cost clone expansion memory boards work fine at 6 or 8
mhz but are plagued with problems such as parity errors (or worse) if
installed in a 10 mhz 286-class machine operating at 1 or 0 memory
wait state. Be aware of this as you select your memory board. Saving
a few bucks here may seem very attractive until you end up with a
system that crashes every few hours (corrupting all data in RAM) or,
worse yet, will not work at all. Another feature of some memory
boards is the capability to reconfigure the memory and
serial/parallel ports (if any) through software rather than by setting
jumpers or DIP switches...meaning you dont have open the box again to
reconfigure the ports or memory allocation.

Unless you plan to use your expanded memory with 1-2-3 to make really
HUGE spreadsheets or to run ORACLE (one of the few "protected mode"
applications currently on the market) the best use by far for
expanded/extended memory is to install a disk-caching program. A
disk-cache will dramatically improve the performance of most PC's and
most applications, especially the ones which are slow due to disk I/O.
What a disk cache does is to get between the disk and the application
for disk "reads" and "writes". When the application looks for data
that is not found in memory, it requests a disk "read". The caching
program intercepts the request and, using a caching algorithm to
determine the most-recently used data, check to find if that data has
recently been read from the disk. If the data is found in the cache,
no disk "read" is commanded and the cache supplies it to the
application much more quickly than the disk could have because there
is no lag associated with moving the disk head in a "seek" or
rotational latency in the disk (related to the disk interleave,
controller buffer size, and other factors.)

Two caveats apply here. First, a disk cache probably will not work
with a Bernoulli Box due to the controller's non-standard ROM location
at CE00 hex. Additionally if you have a disk that uses Run-Length-
Limited (RLL) encoding for data storage, reliable operation of the
cache cannot be assured. IBM now supplies a caching program with the
PS/2 Model 60 and 80, and the technique has been used on mainframes
for years. Works fine on disks with ESDI and SCSI interfaces, too.

Use of a benchmark program (PTDISK) which is highly disk intensive and
allows "clocking" of various I/O operations such as random reads,
sequential read and update write, multi-sector read and write, etc. is
very helpful in determining the best configuration for your system.
PTDISK shows the time in milleseconds for various disk operations and
presents a final figure called "Sequential Data Tranfer Rate" which
represents the date rate of the I/O channels between the disk and the
application in kilobits per second. This is a highly subjective
measurement, but provides a basis for comparison. A sample screen from
a PTDISK run is presented as Figure 2.

Various hardware and software configurations were evaluated using
PTDISK. Among the variables were number of DOS buffers, disk
interleave, several different cache programs... enough parameters for
a pretty good doctoral thesis. Table 1 is a summary of some
representative systems taken from my notes, all using Disc Wiz by
Performance PC as the caching program (which provides cache I/O
statistics-See Figure 3), PTDISK Testfile size of 100000, DOS 3.3 and
default disk interleave:

** The Disk Wizard (tm) -"WIZ" is installed **

Enter comments about test until bare return:
Super 286/10 DOS 3.3 Buff=12 Intel AB 512K EMS

Enter number of bytes to be used in TESTFILE: 100000
TESTFILE will contain 195 sectors for filesize of 100000 bytes

Type of Test Milliseconds per Operation
------------ --------------------------
sequential extending write: 3.57
sequential read and update write: 0.77
sequential read: 0.41
random read: 2.60
random read and update write: 4.10
random multi-sector reads: 13.10
random multi-sector reads and writes: 14.80
** sequential read transfer rate = 1228 kb per second **
** total real time in seconds to complete tests = 10.67 **
** total real time in seconds with forced flush = 13.52 **

Figure 2 - Sample Disk Wiz Screen


------------------ ---------
IBM-PC Buff=4 No Cache 33 kb
IBM-PC Buff=4 64 K Cache in Conventional Memory 96 kb
6 Mhz AT Buff=15 No Cache 112 kb
8 Mhz AT Buff=12 256 K Cache in Extended Memory 435 kb
8 Mhz AT Buff=12 512 K Cache in S/W Simulated EMS 712 kb
10 Mhz AT Buff=12 512 K in Hardware EMS (Intel A/B)1165 kb

Table 1 - Comparision of PTDISK Test Results


The disk caching program approximately triples the effective system
throughput on disk intensive applications. All else being equal,
conventional memory provides the fastest access to the cache, but
speed must be traded against the number of "Hits" (how often the
caching algorithm finds the target data without doing a disk read)
which is a function of the cache size: It's pretty hard to justify
giving up 512K of main memory just to improve disk I/O. Access to
hardware EMS (implemented on such boards as the AST RAMpage, Intel
Above Board, etc.) is very fast and allows a large cache with a fast
read rate because it is accessed as 64K pages swapped into and out of
main memory.

Software simulation of expanded memory in extended memory is the next
best setup. A program (TeleWare's AboveDisc, for example) which
simulates EMS in software is loaded as both a device driver and an EMS
manager application and the disk cache is established there. Access
to the cache is only about 20% slower than with hardware, there is no
need to use more expensive EMS boards, and reconfiguration can be done
simply by editing the CONFIG.SYS and startup batch file (rather than
manipulating those ~&$%*@!! damn DIP switches). One problem is that
this setup is fairly profligate with main memory...It used up 220K by
the time 4 device drivers and the other stuff was loaded up; So if you
like pop-up applications this may not be the way to go.

Slowest disk-caching location was Extended Memory. I believe this is
because there is no I/O channel from DOS into extended memory except
through VDISK and the like. Another problem I had was that VDISKs
don't like to share their extended memory space with any other
program, tending to crash the system if forced to do so. The DOS
manual mentions something about this. The EMS manager discussed above
co-existed with the DOS VDISK just fine, though, and I ran just such a
configuration on a cheap clone Extended Memory board for some time
before going to my present setup. Note that the benefits derived from
a VDISK are IN ADDITION to the dramatic speedup in apparent disk I/O
realized through disk caching.

To sum up: Tuning PC's for speed involves juggling a number of
factors, the most important of which are disk interleave,
bus/processor speed, size and location of caching if any, and careful
testing to find the point of diminishing returns. I noticed that the
results of the benchmark tended to improve with succesive executions
of the test-all my data is fom iteration 3 to reduce variations from
the "learning" effect. As the cache size is increased from zero to
about 256k the results of the benchmark program show the greatest
improvement; The returns increase more slowly out to about 512k where
a point of diminishing returns seems to be reached. The caching
advantage is reduced as the program spends more time searching for
memory locations in 64k EMS segments than a disk read would take.

Mainframe computers like VAXes often have a fixed, relatively small
cache tightly coupled to the processor, and a larger cache consisting
of memory allocated from the system pool which is accessable via the
bus. Also, a few 80386 boards (such as the new Compaq 386/20) feature
an on-board processor cache (usually 64 K); implementing a two-tier
scheme might be interesting.

Microsoft Windows Version 2.03 includes both a disc-caching program
and a RAMdisk as part of the package. After trying both programs and
running the benchmark, I was unable to establish that the Windows
disk-cache performed any better than Disk Wiz. The Windows manual
claims that SMARTDRV (the Windows cache) is "optimized" for Windows
application but provides no technical information. I'm skeptical
about reconfiguring a system to improve the performance of one
particular application.

If you wish to run Windows and currently have 3 MB of EXTENDED memory
on a non-EMS board configured as one large VDISK, I would suggest that
you reduce the VDISK size to 1 or 1.5 Mbytes, configure the remainder
of the Extended memory with the Windows caching program yielding a
CONFIG.SYS as follows:

DEVICE= (Your Hard Disk Device Driver If Any)
DEVICE=SMARTDRV.SYS 1024 :Use /a switch here?
DEVICE=NANSI.SYS :Screen driver
BUFFERS=12 :An important variable!

Then edit the WIN.INI program configuration file and define the VDISK
as the swapping space. Windows Notepad is the editor used for this

My system has an Intel Above Board AT with 1Mb of Expanded and 1Mb of
Extended memory. CONFIG.SYS is shown below.

DEVICE= (Your Hard Disk Device Driver If Any)
DEVICE=EMM.SYS AT D000 208 EXP=1024 Intel EMS Driver
BUFFERS=12 :An important variable!

Mark Petry is a Silicon Valley engineer, computer consultant, and a
sometime writer. He can be reached on the Stanford-Palo Alto Computer
Exchange BBS- (415) 964-9039 2400/1200-8-N-1 or (415) 369-7635 voice

All Copyrights Acknowledged, All Writes Wronged.

 December 15, 2017  Add comments

Leave a Reply