Mail Archives: djgpp/1997/08/04/04:02:46

From: "Art S. Kagel" <kagel AT bloomberg DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: djgpp and RAM
Date: Fri, 1 Aug 1997 09:32:33 -0400
Lines: 25
Message-ID: <Pine.D-G.3.91.970801092544.16551B-100000@dg1>
References: <01bc9dad$1625a480$bee0f9ce AT somebody DOT jaguarsystems DOT com>
Mime-Version: 1.0
In-Reply-To: <01bc9dad$1625a480$>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On 31 Jul 1997, Locke wrote:

> Hey everyone,
> I've just started in djgpp and am still trying to understand all the perks
> of a 32 bit programming system.  My understanding is that you can access
> the system ram very easily from a 32 bit program, but that's just what I've
> heard.  What I'm wondering is, that if I wanted to put say, a two
> dimensional array (a map for a game), in the ram instead of just loading it
> to conventional memory, could I do that?  Or does djgpp do this already?
DJGPP lets you see all of the memory in your machine plus virtual
memory in the form of disk swap files, as a single flat virtual memory
space of up to 256MB (actually real memory + up to 128MB of swap
depending on free disk space).  Flat memory model means 1) there are
no segment/offsets to deal with just a 32bit linear address, 2)
Individual objects are not limited by any artificial segment size so
if you have a machine with 128MB of RAM and 128MB of free disk you can
define an array containing over 200MB of memory (you've got to leave
some room for the OS and you code!)  DJGPP makes no distinction
between "conventional" RAM, "extended" RAM, "expanded" RAM, and swap
space.  It is all just seen as "memory".  Hope this helps.

Art S. Kagel, kagel AT bloomberg DOT com

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019