djb@wjh12.harvard.edu (David J. Birnbaum) (09/07/89)
I'm running into a conflict with Nota Bene and EMS (4.0). I
have a Computer Elektronik Infosys Ramflex board in my AT clone
with a the following memory configuration (addresses are in hex):
0000 - 9FFF 640k regular memory (on system board)
A000 - AFFF Extra 64k of regular memory supplied by
backfilling from Ramflex board; the system
recognizes 704k of regular, contiguous DOS
memory. This range is normally part of the
video buffer, but my Hercules Plus monochrome
graphics card uses only B000 - BFFF.
B000 - BFFF 64k video memory (used by Hercules Plus
monochrome graphics card)
C000 - CFFF 64k page frame for EMS swapping
D000 upward Empty addresses and system ROM
I have been running 4DOS as a replacement for command.com and I
configure 4DOS to load a 5K resident portion and swap the rest of
its memory (about 50K) to EMS when not needed. This works per-
fectly with all my applications except Nota Bene. Nota Bene is
a modified version of XyWrite version 3.52 produced under a
licensing agreement with XyQuest. It is significant that XyWrite
does not exhibit the problem that Nota Bene shows below.
If I load Nota Bene, all is well until I exit, at which point
the system hangs. Loading command.com as a secondary command
processor, either by typing 'command' before running Nota Bene or
by typing 'command /c nb' does not help. What does help is if I
tell 4DOS not to swap to EMS; all is well if I run 4DOS as fully
resident (but this takes about 55k) or if I tell it to swap to a
disk. The 4DOS support people inform me that 4DOS allocates EMS
memory strictly by the rules; this is confirmed by the fact that
their program operates flawlessly with everything I have thrown
at it except Nota Bene. I DO NOT THINK 4DOS IS AT FAULT, but the
problem showed up here because of the frequency with which the
command processor is used. I am not using any other EMS-aware
programs that might have to coexist with Nota Bene.
The programmers at Dragonfly Software (home of Nota Bene) sug-
gest that my EMS board may be using the B000-BFFF range that is
used for video memory. Using the Special Language Supplement
feature of Nota Bene requires the entire B000-BFFF range for the
video display (via the Hercules Plus graphics card operating
in 48K ramfont mode), so that a conflict might arise if there
were other claims on these addresses. I think this explanation
is unlikely for two reasons. First, other programs that use the
same video memory to operate the Hercules Plus card in the same
mode have no trouble. This includes XyWrite; I can load a 48k
ramfont font into video memory, enter XyWrite, and exit safely
without causing any problem with 4DOS's EMS swapping. Second,
the manufacturer of my EMS card assures me that I can backfill
A000-AFFF and set an EMS page frame to C000-CFFF without
encroaching on the B000-BFFF video memory area at all. The
EMS setup program confirms the memory mapping at the top of
this posting; it knows that there is video memory at B000-BFFF
and that it should not overwrite those addresses.
That other programs can use the video memory area safely sug-
gests that my EMS card is operating properly. What seems most
likely is that Nota Bene might be carelessly overwriting the
C000-CFFF range. Since Nota Bene makes no use of EMS and has no
EMS support or awareness built in, it might not check to see
whether these addresses are in use. The programmers at Dragonfly
said that this was unlikely. But Nota Bene can support an EGA
card as well as the Hercules Plus card that I am using; if it
writes to memory outside B000-BFFF *just in case an EGA card
might be in use* without first checking to see whether such a
card is, in fact, in use, it could overwrite memory that I have
allocated for other purposes. If it overwrites the EMS page
frame, when 4DOS requests expanded memory it might be told that
the memory it needs is already in the page frame, since no EMS
application has caused it to be paged out. If that memory is not
where 4DOS expects to find it, the misinformation could lead to a
crash.
There are a couple of temporary solutions. First, I can
tell 4DOS not to swap to EMS. This works and I am doing it for
the moment, since I don't want to open my computer and reset the
switches on my EMS card unless absolutely necessary. I can tell
4DOS to swap to a ramdisk, which is just as fast as EMS swapping.
Alternatively, I could try resetting the EMS page frame to
C800-D800 or D000-DFFF or some other range; I have free space
from C000-DFFF and I can configure my EMS board to use any 4
contiguous pages within this eight-page range.
Alternatively, I could stop using Nota Bene. If my suspicion
is correct and Nota Bene is misbehaving, that would seem that
best solution, since ill-behaved programs should not dictate
the system configuration. If my diagnosis is incorrect or there
are other possibilities that might exonerate Nota Bene, I would
be happy to hear them.
I can not confirm whether Nota Bene is overwriting the EMS
page frame, but this seems to be the case. Are there any users
out there familiar with this type of problem who could suggest
a way of diagnosing it? The Nota Bene program that would be
the culprit is called nbmaster.exe; it is called from within
Nota Bene and is apparently charged with, among other things,
making sure that the video display is set up properly. I do not
understand its workings well enough to make sense of a
disassembly myself.
Thank for any suggestions or advice.
--David J. Birnbaum
==================================================================
djb@wjh12.harvard.edu [Internet]
djb@harvunxw.bitnet [Bitnet]
=================================================================