Memory--like money and talent, it is rare that any of us have too much of it. Indeed, because of their inordinate demands for memory, some CD-ROM products force us to apply far more talent and money to the task of getting them working than we would like.
The memory I refer to is RAM, random access memory, the electronic, temporary repository in which programs perform their cybernetic dance with our data. When the computer is turned off, the contents of RAM, freed from the tiny, rapid-fire electrical pulses that keep then, figuratively and literally in line, subside into meaninglessness.
The behavior and performance of programs is dictated in part by the amount of memory "elbow-room available to them. The key word here is "available."
In the world of IBM-compatible equipment, a computer may have multiple megabytes of RAM installed yet still not provide enough memory to applications. Only the first 640KB of RAM, called "conventional memory," is unambiguously accessible. Depending on how the system is set up, what microprocessor it uses, what version of DOS is installed and how much physical memory has beet, installed, the amount of memory left over to run a CD-ROM retrieval package may be considerably less than 640KB.
A typical PC-compatible running under DOS 3.3 might have memory enough for programs that require 550KB to 580KB. DOS 4.0, mainly because of its own increased memory footprint, may leave 530KB or less. DOS 5.0 may be little better than 4.0 on an older computer, but allow up to 620MB of usable memory or so on a 386-based system.
The reason for all this fuss is the propensity for CD-ROM search software to require large amounts of available RAM. Data retrieval software benefits from loading indexes, pointers and other quickaccess mechanisms into RAM for manipulation preparatory to reading the actual data being sought from a disk drive. The relatively slow response of CD-ROM drives increases the motivation of software designers to use every RAM-gobbling trick in the book to speed retrieval. Even if a search application will tolerate a memory straitjacket, its performance is likely to be substantially enhanced by extra RAM.
The nitty-gritty realities of "RAMcram" surfaced here when we switched to a new vendor of services and software for MaineCat, the statewide CD-ROM union catalog that I manage. An index, a directory or an encyclopedia may be the trigger in your situation--the issues and the options are the same. Sooner or later, particularly as "creeping featuritis" overtakes multimedia-fixated developers, most users of CD-ROM products will face similar memory availability problems.
COPING WITH MEMORY
PROBLEMS OR "RAM-CRAM"
Fortunately, there are alternatives. Unfortunately, they require more explanation than one would wish. (At this point, Macintosh owners, if they have gotten this far, may wish to congratulate themselves on at least one bit of gratuitous complexity they have managed to avoid.)
First, it should be noted that 550KB is about the upper limit of what an applications software developer can reasonably expect users to dedicate to a CD-ROM product in a real-world environment. Unless there are major compensating benefits, purchasers should protest vehemently about products that are impossible to run on any but the latest and greatest speed-demon, memory-maxed super machines.
Here are a series of measures to take in attempting to cater to the memory requirements of the more demanding CD-ROM applications.
1. Establish a starting point. Determine how much conventional memory is installed in your system and what portion of it is available to programs.
The CHKDSK program must be in the current directory, or in one of the directories listed in the PATH statement in the AUTOEXEC.BAT file of your computer. At the C:, type CHKDSK. Following some statistics regarding your hard disk drive, you will see something like this:
654336 total bytes memory 535504 bytes free
In the peculiar world of binary arithmetic, 654,336 is equivalent to 640KB. DOS itself, the CD-ROM device driver, Microsoft CD-ROM Extensions and perhaps other device drivers and memory-resident utilities automatically installed on start up account for the difference between total bytes of memory and bytes free.
If version 5.0 of DOS is in use, the MEM command should be used instead. It provides the same information, plus a good deal of additional data about which programs are doing what and how much space each is occupying.
2. Examine the CONFIG.SYS file, the text file from which DOS accepts a variety of system configuration instructions. Superfluous and overly generous settings often can be trimmed to free up additional memory. This is particularly true of default installations of DOS version 4.0.
Is there a LASTDRIVE=Z line in CONFIG.SYS? Unless the computer is on a network or runs one of the prehistoric programs that insists oil looking for the CD in drive L: or some such, the "Z" can safely be changed to the last letter assigned to a disk drive in system. In fact, if the last assigned drive letter is "E," the LASTDRIVE line can be eliminated entirely. About 50 bytes of memory are saved for each letter by which LASTDRIVE is reduced.
Is there a BUFFERS lines BUFFERS-30 is a common, one-size-fits-all setting that is generally acceptable. With only a few exceptions, more than 30 buffers will not appreciably improve performance, though it will significantly reduce available RAM. If a disk-caching program is installed almost always worthwhile performance-enhancing measure--BUFFERS become redundant and can be reduced to the bare minimum allowed by your version of DOS. Each memory buffer eliminated saves slightly more than 500 bytes.
Eliminate unneeded device drivers. DEVICE=ANSI.SYS, for instance, is required by only a very few programs. INMAGIC comes to mind as a prominent example. Elimination of the line will save several thousand bytes.
Other DEVICE lines should be examined. If the purpose of each is not known, it should be determined. When attempting to slim down the demands of the system of RAM needed by programs, one should avoid assumptions about the inherent wisdom of the current configuration.
3. Examine the AUTOEXEC.BAT file for unnecessary memory-resident programs. Every time the computer is turned on or rebooted, the instructions in AUTOEXEC.BAT are automatically executed, loading any number of memory-resident programs into precious conventional memory.
The DOS utility FASTOPEN takes a significant amount of RAM and is unnecessary in a CD-ROM environment. GRAPHICS is another DOS program that should be loaded only when it is absolutely needed in this instance to insure proper printing of graphics characters from some screen displays.
Be especially watchful for desktop utility programs. While it may be convenient to have instant access to an appointment calendar, financial calculator or memo editor from within your CD-ROM software, the penalty in lost RAM is usually unacceptably high. This category of program usually consumes more RAM than any of the others mentioned here.
4. Local Area Networks (LANs) are right up there with CD-ROM as memory.devouring innovations. Novell and other full-featured LANs extract a heavy price in memory for the convenience of being able to access other resources connected to the network. The combination of network drivers and CD-ROM drivers spells trouble for application software.
Be sure that your LAN setup is taking advantage of all the memory installed in your computer. The tradeoffs between expanded memory, extended memory, extended memory made to look like expanded memory, high memory, and upper memory can be pretty involved. The options for taking advantage of such esoteric varieties of memory capacity are also usually more extensive in LAN software than in other product categories. Someone knowledgeable in the field may be able to reorganize the network setup to free significant RAM for CD-ROM use.
5. The incremental benefit of a change of DOS version should be considered. DOS 4.0 in particular is notorious for its use of RAM. it requires more conventional memory than any DOS version before or since. On XT.compatibles, computers based on the SOBS or 8086 microprocessors, DOS 3.3 is preferable.
On a 286 or 386 with at least IMB of RAM, an upgrade to DOS 5.0 will provide major advantages over DOS 4.0. The tricks DOS 5.0 supports will allow you to move some of the load from conventional to upper memory, thereby leaving more RAM for the applications software.
6. If the computer is based on a 386 or higher microprocessor with IMB of RAM and lacks DOS 5.0, an upgrade is definitely in order. The newer microprocessor in concert with DOS 5.0 supports several new strategies for freeing up conventional memory.
A hardware upgrade to at least 2MB of RAM is also in order. Four megabytes is even less restrictive and entirely defensible given the demands of mainstream software. Compatibility with Windows and other multitasking environments that run several programs simultaneously requires the additional memory.
7. Third-party memory management software can often free up more memory on 286 and 386 systems with a megabyte or more of RAM. The tricks played by such commercial utilities are frequently more sophisticated and effective than those built into DOS.
Now, for instance, the most current version of Microsoft Extensions cannot be loaded anywhere but in the conventional memory area if you are using DOS 5.0. QEMM from Quarterdeck Systems will handle the task, however, saving a valuable 20KB or so.
Such software generally includes an optimization feature, whereby a wide range of possible settings are tried and those that yield the biggest savings are automatically put into effect. This "feature could save several hours of trial and error.
8. Multiple start-up configurations are a last resort. If the demands of other programs sharing the CD-ROM workstation prevent the elimination of device drivers, memory-resident utilities, and other memory hogs, then the notion of a one-size-fits-all pair of AUTOEXEC.BAT and CONFIG.SYS files must be abandoned. In their place, multiple pairs of these essential start-up files can be created. The files that contain optimum settings for product X are saved in CONFIG.X and AUTOEXEC.X, those for product Z in CONFIG.Z and AUTOEXEC.Z, etc.
Prior to using product X, the user types the following lines, then reboots the computer:
COPY C:CONFIG.X CONFIG.SYS
COPY C:AUTOEXEC.X AUTOEXEC.BAT
If one wished, these two commands could be combined in a batch file called SETUP-X.BAT. To change the setup files, one would simply type SETUP-X at a C: prompt. A further enhancement would be the addition of a third line to the batch file that causes the system to reboot without the user having to press
. Such rebooting utilities are widely available from sources of public domain software.
Before implementing a system like this, the original configuration should be saved, perhaps in files called AUTOEXEC.ORG and CONFIG.ORG, One could return to the original set-up by running SETUPORG.BAT.
Several shareware ("try before you buy") programs that incorporate multiple configurations are available. I have yet to find one that is useful enough to justify becoming registered owner. Preferences in such supposedly labor-saving facilities are highly personal, however. Anyone with an interest in a less spartan approach than the one described here might profitably look into the shareware channel.
A SONY SPEED-UP
Back in the distant past--it was 1988 I think--we purchased 200 Sony 6101 CD-ROM drives. We had some horrendous problems. One would have thought that a technology transfer from Electrolux had been employed during the design phase. During the "Dusty Sumnjer of 1990" every one of the drives was gathered up and shipped to Sony in California for a cleaning and retrofit. Since then the units have performed reliably.
Not all is well on the software front, however. We were appalled to see our new union catalog software run at one-quarter of normal speed on the Sony drives. At 600 to 700 milliseconds average access time, the 6101s are far from speed den,ons. They should at least perform as well as Hitachi 1503s, however. The old 1988 SONYCDU.SYS device driver is probably partially the cause of the problem. Sony tells us that this is the current and best driver, however.
We did discover that these particular drives have both a normal and a high speed mode. The high speed mode is enabled by adding a /M:H parameter to the end of the device driver line, as below:
Suddenly, most of our becalmed Sony users were up and running again. The drives hooked to 286s and 386s have had no problems with the fix, but that has not been the case with slower PCs. IBM XTs, PCs and Model 30s choke on the speed-up option. While one can get a directory listing from the CD-ROM drive, running software or even TYPEing the contents of a file on the CD will produce immediate read errors.
Some XT-clones exhibit similar behavior, while others work fine. Sonle work only when the machine is set to "turbo," i.e., high-speed n,ode. Others lock up in turbo, but work fine at normal speed.
The investigation is ongoing, as they say.
If you have 6101s and encounter surprisingly slow response, the /M:H option may well help--particularly if you have a fairly fast computer to start with--and the high speed switch may work on newer Sony models as well.
Murphy's 87th Law of Computing states, "That which might be more complicated than it looks will be." Like any good law, it has a coronary: "One pays for improvements in performance and capacity through the sweat of one's cortex." That is true of memory management, it is true of coping with software/hardware incompatibilities, and it is true in general of CD-ROM.
Forthcoming columns will continue the effort to dissect the complications and optimize the potential of CDROM in the library and information center environment.
Communications to the author should be addressed to Karl Beiser, 18 Elizabeth Ave., Bangor, ME 04401; Internet--kbeisermaine.maine.edu.…