At 07:00 PM 7/6/2004 +0200, Aitor Santamaría Merino wrote:
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
Alain schreef:
2) on NEW HW it works fine. In modern machines (mostly from PCI and
P133 up) upper memory area is not encombered with anything. Before
that QEMM's optimiser was the only way to make good use of UMB, but
now any conservative auto setup will just set one chunk that goes from
the
Steffen Kaiser schreef:
On Thu, 8 Jul 2004, Erwin Veermans wrote:
Hello Erwin,
would you please re-try all the steps you do with the non-swapping
command pl3e.
I wouldn't see in the changelog what might caused this behaviour.
Bye,
Erwin, please also try using MS's MEM.EXE, to see if the
Michael Devore schreef:
If you are using RAM without any parameters, EMM386 should not behave
any differently than if it didn't exist. Standard UMB area scan
occurs whether RAM is there or not. Only the optional range with RAM
makes a difference, changing the default scan area size. And if
At 12:53 PM 7/8/2004 +0200, Erwin Veermans wrote:
I cannot oversee compatibility issues here and my interest would
be that whatever is choosen it should be most compatible for most
hardware around. So would it be an option to add an Arkady-A000
switch that will skip the A000-A001 ? Everybody
Eric Auer schreef:
PS Bernd: Tell people to abort on the WHICHFAT critical error message. Then
unformatted is reported as 0, and FAT12/16/32 are all reported properly.
However, the kernel has to be fixed - there should be no interactive critical
error message when detecting an unformatted drive at
Hello Michael,Arkady, and everybody else
WITHOUT PROGRAMMING OR TESTING !!
some thoughts:
being pressed by arkady, I rethought the issue.
I think, that even IF EMM385 returns A000, the old kernels
will not merge a000 UMB into lower RAM.
old kernel, old a001 EMM386:
1 - 9
tom ehlert schreef:
however I still would prefer arkady to recompile emm386
and tell us if that works, instead of using mental input bandwidth of
all people subscribed to this list.
didn't you use some commercial compiler? Eric didn't have it, and
probably Arkady neither.
compiling is
I got this in an e-mail that was also sent to Steffen Kaiser. I haven't
included Roland's e-mail address per the note -- Gregory:
Hello,
do you know that Steve Gibson(www.grc.com) is Considering spending
$20,000 for DR DOS? There is a thread about this in
news.grc.com/grc.spinrite.dev.
He is
Hi, Tom pointed out that SORT was limited to sorting at most 15k of data.
I fixed the problem by
- compiling as EXE (do not forget to delete sort.com when installing the exe!!)
- thereby making malloc and qsort use far pointers (there is no explicit far
veraion of qsort, so I had to use a
Hi, I would like to add that:
http://www.wordiq.com/definition/Quicksort
Quicksort takes average O(n*log(n)) but worst O(n*n) comparisons,
and average O(log n) but worst O(n) stack (and no head)...
So I increased stack size of SORT to 16k, which means that it can
sort up to 700 (roughly)
Hi Michael,
I am 99.9% sure thar without RAM there is no UMB. I will check it tomorow.
Alain
Michael Devore escreveu:
At 01:08 PM 7/8/2004 -0300, you wrote:
Hi Michael,
I would like to give you my opinion about the RAM option:
I USE IT !!! And I have two reasons to use it:
1) it is easy and works
I believe this is a very typical representation of FreeDOS development.
Some people are optimizing it while critical problems (for some people)
remain unsolved.
Gregory Pietsch escreveu:
I got this in an e-mail that was also sent to Steffen Kaiser. I haven't
included Roland's e-mail address
13 matches
Mail list logo
