Question

Aitor SantamarÃa Merino Tue, 06 Jul 2004 09:50:00 -0700

By the way, it's long since I last watched the EMM sources, but I've always thought that implementing RAM=/I=/X= couldn't be very difficult with current sources, by just modifying a bit ScanSystemMemory(), the current search range is fixed (at least it was in 2003):

for (mem = 0xc000; mem < 0xf000;) /* This is the range that should be IMHO modified with RAM= */

so you'd process the I's first, the X's next, and lastly the previous loop, so that if the entry is empty (hasn't been filled by the I/X processing) then you scan. Well, the fact that it might not have been done like that by current EMM386 developers gives a clue that it must be something more difficult behind... or am I wrong?

Aitor

Eric Auer escribió:

Hi!
Arkady, Tom rejected *implementing VCPI by himself* as he did not see the personal(!) need for VCPI. FreeDOS programs can be worked on by multiple people. Tom sometimes improves someone elses program, Eric does the same, and so do you.
About me and EMM386: I would have helped with VCPI, but I would not have
been able to do it all alone (compare my EMMSYS sketch or my suggestion
to fix VM386 (VMM386?) driver to make it an EMM386). Anyway, even minor
patches usually got rejected because I did not test them (how could I?
EMM386 cannot be compiled with free compilers) or because we did not
agree about RAM= / ROM= / HIGHSCAN semantics.
This is also the main problem now: Arkady wants RAM= and he wants
an HIGHSCAN change, as far as I understand. I have had longish
discussions with Aitor about what exactly those options should do,
so I recommend that Aitor tells us some more details. As far as
I remember, RAM= was I=ish, although I personally would have
preferred "RAM= just use this RAM area" (for people who can map
RAM into UMB area simply by enabling RAM visibility in CMOS setup,
e.g. NeAT 286/386 chipset has this)... And HIGHSCAN was "if there
are 2 identical copies of 32k ROM at f000:0 / f800:0 respectively,
attempt to remove one by mapping memory from elsewhere there (create
an UMB). Something like that, used for very old computers and had a
tendency to crash if some programs tried to use the removed copy.
-empty (FF's) -shadow RAM (00's)

This also needs a test whether area is writeable...

-PROM (AA55 signature)

This allows skipping the whole PROM - searching for unused areas inside is not recommended, and the ROM signature is followed by size information.

-misc (code fragments and random code).
 Interesting idea - might help to detect memory-mapped-I/O areas, e.g. of
 network cards and disk controllers. Would possibly be over-careful, but it
 can be used in some "X=auto" mode :-).
Eric
------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel

------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question

Reply via email to