Arkady V.Belousov wrote:
Hi!
27-Ноя-2005 12:58 [EMAIL PROTECTED] (Andreas Bollhalder) wrote to
[email protected]:
AB> Something stranges happens here.
AB> BUFFERSHIGH=29 -> 615kB conventional and 150kB upper memory free
AB> BUFFERSHIGH=30 -> 599kB conventional and 150kB upper memory free
This is not strange, because 29 buffers fit to remains of HMA, whereas
30 already not.
Just to help clarify the situation, the kernel does not use upper
memory, so if you have 150KB free, it should stay free regardless of the
# of buffers you specify. The kernel does use high memory [confusing
terms I know] which is limited to just under 64KB. The kernel uses this
full chunk of memory, part is for compiled code and part is for items
such as buffers. With several of my changes/additions the size of the
kernel has grown, so less high memory is available for buffers. (I try
to keep any size increasing changes that are not always necessary, such
as win3 or fat32 support, a compile time option so memory constrained
computers can use a custom compiled kernel removing unused portions to
increase available memory.) For FD, buffers statement is more of a
guideline, ie it will create at least as many as requested (so more may
be created if otherwise unused HMA space permits), but it needs a big
enough block of memory for them all. So at 30 buffers the kernel can
not allocate a large enough block high so it tries and succeeds doing so
in low (conventional) memory; whereas it succeeds with 29 buffers.
PS: Jeremy, do you test latest EMM386 with kernel _without_ saving fs/gs
registers?
I think so, I have so many versions lying about and have done so many
reboots I've lost track. I do not plan on removing the code from the
dev kernel that saves/restores these registers though, as other DOS
TSR/driver programs (based largely on what I've read in newsgroups
somewhat recently regarding the issue of 386+ registers and DOS) may
similarly assume it ok to change 386+ registers since MS-DOS doesn't use
them even though they should not for max compatibility.
Jeremy
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
