Alain et al,
>> I do need as much conventional memory as I can get, and even the it is a
>> tight fit...
>>
>> So everyone belives that
>> JEMM386 X=TEST NOEMS
>> is safer? if so, I will change...
>
> My point was that ACPI tables (and/or too aggressive searching by FD
> [J]EMM386?) makes it necessary to either avoid X= I= or use both with
> "=TEST". At least, from my limited experience, that's the case. It's
> worth a try, at least, but who knows honestly. :-P
For the record, I use V6.22 MS-DOS (compatible with my equally
old V4.0 Windows/NT!), and I have always loaded JEMM386 with a
NOEMS command. No problem! Seems to work O.K., as I expect
it should, since I run no "VERY old" EMS programs!
In your case, if "conventional" memory is a concern but upper-
memory is not, you can try loading JEMM386/JEMMEX like this:
DEVICE=C:\DOS\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS
This specifically tells JEM386/JEMMEX to "map" upper-memory in
only the "monochrome video" (black-and-white) graphics area at
B000h thru B7FFh, which nobody uses now due to COLOR displays!
All other upper-memory address space, C800h thru EFFFh, is NOT
used, due to the X= and NOEMS commands. This gives you only
32K of upper-memory, but it may be SAFER than I=TEST, etc.
Also, as you can see Lucho doing in his "boot" diskettes, what
about providing users the CHOICE of loading JEMM386/JEMMEX, or
UMBPCI? Although UMBPCI cannot run on "absolutely" all chip-
sets and mainboards, it has never "failed" me or others in its
memory-test procedures. Might SAVE your CD "boot" scheme, on
a system that otherwise cannot use JEMM386/JEMMEX.
Jack R. Ellis
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
