Message-Id:	<199709192356.JAA19936@rabble.uow.edu.au>
Subject:	Re: Where is my physical memory hiding?
To:	salvador AT inti DOT edu DOT ar (Salvador Eduardo Tropea)
Date:	Sat, 20 Sep 1997 09:56:15 +1000 (EST)
Cc:	djgpp AT delorie DOT com (DJGPP)
In-Reply-To:	<m0xC1M0-000S1qC@inti.edu.ar> from Salvador Eduardo Tropea at "Sep 19, 97 03:01:21 pm"
From:	Brett Porter <bporter AT rabble DOT uow DOT edu DOT au>
MIME-Version:	1.0

> At first you are asking for: 62*65536=4063232 bytes, so 7Mb is enough. Sounds 
> strange, what DPMI host are you using?, are you sure is 64000 bytes or perhaps 
> you are allocating 0x10000?

No, definately allocating 64000.

> Second: as you said you have: 8Mb-2Mb(cache)-1Mb(base memory)-4Mb(if you are 
> using RHIDE when you run the program)= 1Mb of real memory ;-))), don't spect 

It still says out of memory when run outside of RHIDE - this is where the
get physical memory function reports 7000000 or more free.

> that the DPMI host will use ALL the available disk.
> In particular CWSDPMI keeps some sanity about how much virtual memory will 
> report according to the real memory you have. For example, I have 24 Mb free 
> (after loading RHIDE), and CWSDPMI reports aprox. 150Mb free even if I have 
> 300Mb free on disk. Windows will report even less.
>
How do you find out how much CWSDPMI is using? RHIDE reports in the
top-right that I have 3M physical and 19M virtual - all of it (this number
decreases in Win95, and not because of a large swapfile, either.)

The reason you might only have 150Mb is that I believe the FAQ says CWSDPMI
uses 128Mb of Physical RAM + 128Mb of Virtual memory at most, and 24Mb+128Mb
is about 150Mb, right?
  
> > The actual sequence of calls is: (it's to load each frame of a FLI into a
> > seperate buffer)... BTW the size of the FLI file is < 40Kb
> So why are you trying to decompress it first, make it on the fly, I think it 
> will be faster because in this way you don't need to blit the whole screen.
>  
Well, first of all I wanted to just them up on screen, and then work on the
other routines, and refine the FLI stuff later. I am not actually animating
the FLI... my graphics editor of choice is Autodesk Animator (when using
DOS), and I store "libraries" of pictures in one FLI file (some of which are
animations, on successive frames), and the program I am writing allows the
user to select a frame(s) and clip a section of the screen into my game's
resource format.

> > 	* allocate a buffer for this frame (taken from frame_header.Size)
> > 	* allocate 64000 bytes and store the frame
> > 	* free the first buffer
> And perhaps here is the problem, when you allocate this temporal buffer and 
> then deallocate it you are fragmenting the memory. To test if that's true try:
> 1) Allocate the temporal buffer just ones.
> or 
> 2) Use my malloc function.
> > 
> > 	...	and do this 62 times.
> > 
> > Any ideas why I am running out of memory?
> Yes, fragmented memory is the most possible reason.
> 

I'l try (1)... as for the alternative, where can I find your malloc
function? I am still not sure it could be fragmentation, because I am only
allocating less than a kilobyte one average when I do this, so it can't
absorb that much memory, can it? Maybe I should delete some stuff off my HD
and then download the djgpp sources to see how the malloc function really
works.

Thanks for your help
Brett

-- 
"Give me ambiguity or give me something else"
--
Brett Porter
blp01 AT uow DOT edu DOT au

http://www.geocities.com/CollegePark/Union/3596
	Humour, Programming, and more.

- Raw text -