At 12:50 PM 7/11/2005 -0300, Alain wrote:
Blair Campbell escreveu:
Hm, it works for me, but I use the VDS option for EMM386 in addition
to X=TEST. Plus also MEMCHECK but that should only be needed if you
use kind of "do not let HIMEM use all memory" in some way (e.g. HIMEM
options or some XMS driver which cannot see all RAM). So try if VDS
and/or MEMTEST solve the problem.
Adding only MEMCHECK made it work. Thanks.
What can produce this? Isn't Memcheck only a test or does it affect which
memory will be used?
MEMCHECK checks for illegal INT 15h function 87h memory transfers to/from
the real RAM address range -- the CHECK and MEM parts of the MEMCHECK
option -- and dynamically builds and sets two scratch page tables to allow
the access to occur if it is outside of normal RAM range. Otherwise an
exception is generated because the memory ain't there to access.
Generally you don't want to allow such access because when it happens it
usually means something has fundamentally screwed up and it scribbling
across invalid addresses or overshot the mark. However, with
memory-mapped I/O (MMIO), high addresses outside the normal RAM range are
used to talk to a peripherals and the computer bus. The EMM386 MEMCHECK
option was written so that MMIO devices don't auto-fault when using INT 15h
to transfer bytes in those ranges.
Now that MMIO is becoming more common, it would nice to automatically allow
MMIO access without having to specify the non-default MEMCHECK option,
while still keeping normal protections against faulty or crashed
application memory scribbling. Hence the idea of 3-4G address space
MEMCHECK behavior on by default. The non-default MEMCHECK option would
still be available for someone who needs to transfer to or from addresses
below 3G which remain outside of the normal RAM range.
Downsides for the proposal are loss of wild memory access protection in
3-4G range and additional (extended) memory of 16K always, rather than
optionally, consumed. Plus some nanoseconds of check address overhead on
each transfer.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
