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

Reply via email to