DPRG
DPRG List  



[DPRG] C programming problem, large arrays in 16 bit DOS still not working

Subject: [DPRG] C programming problem, large arrays in 16 bit DOS still not working
From: Ed Okerson eokerson at texasconnect.net
Date: Tue Aug 19 17:13:01 CDT 2003

Hmmmm, I was sure the huge memory model would fix it.  There is no
guarantee that malloc will return consecutive blocks, in fact when I was
using the Borland compiler a long time ago, I had notice that it stores
some private info in a few bytes just prior to the address it returns to
you for the allocated space.  The private info contains the size of the
allocated block, so a call to free() knows how much space to release.  The
net result is as a minimum there will be about 4 bytes between the end of
one malloc()'ed area and the start of the next.  An alternative if you
absolutely must have contigous space might be a multidimensional array:

unsigned char picture_buf[2][32767];

Should give you 65534 bytes in a two dimensional array, but again this
could only work with the huge memory model.  You may have to make the
arrays global and static to get the larger sizes.

If you want some help getting Linux video capture working, I have written
a fair amount of code for that.

Ed Okerson

On Tue, 19 Aug 2003, Clay Timmons wrote:

>
> Thanks Steve and Ed for the feedback but no luck so far.
>
> I already tried different memory models, large is the default and I
> tried huge.
>
> Malloc was a great idea but it too failed.  Malloc takes a size_t
> argument which is an unsigned int.  Still can't get past 65536.  I even
> tried to malloc several blocks hoping they would be consecutive but that
> did not work either.
>
> Luckily it's not a problem for the upcoming contest. I can just use
> 180x120 image size. After that I'll see about switching to Linux.
>
> Later,
>
> -Clay-
>
>
> > -----Original Message-----
> > From: Ed Okerson [mailto:eokerson at texasconnect.net]
> > Sent: Monday, August 18, 2003 7:27 PM
> > To: Doug Evans
> > Cc: Clay Timmons; dprglist at dprg.org
> > Subject: RE: [DPRG] C programming problem, large arrays in 16 bit DOS?
> >
> > Actually, just use the Huge memory model and the 64K static data limit
> > will no longer apply and you should be able to use the large array as you
> > originally planned.  Alternatively you could do it with dynamic
> > allocation:
> >
> > unsigned char *camera_image = malloc(76800);
> >
> > The difference here is that malloc() takes memory from the heap instead of
> > the data segment. The advantage is that the 76800 can be replaced with an
> > unsigned long variable and your code can then adapt to different image
> > sizes as needed without recompiling.
> >
> > Ed Okerson
> >
> > On Mon, 18 Aug 2003, Doug Evans wrote:
> >
> > > A couple of observations:
> > >
> > > First, do you need an unsigned char to store a single pixel? If this is
> > a
> > > 0/1 value rather than a grayscale value, you could map each pixel to a
> > bit.
> > > This will reduce your memory requirement by a factor of 8 and
> > effectively
> > > eliminate the issue.
> > >
> > > Second, switch to "large" memory model, and declare the array as "huge".
> > I
> > > don't remember exactly how to do this using Borland under DOS (it's been
> > > awhile), but I do know that I have done it before. Under DOS, you are
> > > limited to 64K segments of memory for a single data structure. This is a
> > > fundamental issue with the x86 architecture. The "huge" directive
> > manages
> > > the larger structure under the covers for you.
> > >
> > > I'm not certain that you can safely ignore the "never used" warning. I
> > don't
> > > think the compiler will guarantee that all of the memory will be
> > contiguous,
> > > since each array will be in a separate data segment.
> > >
> > > -de
> > >
> > > -----Original Message-----
> > > From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org]On Behalf
> > > Of Clay Timmons
> > > Sent: Monday, August 18, 2003 4:08 PM
> > > To: dprglist at dprg.org
> > > Subject: [DPRG] C programming problem, large arrays in 16 bit DOS?
> > >
> > >
> > >
> > > I'm working on the image processing code on my robot and I have a new
> > > problem.
> > > The problem is dimensioning the image array.  The image is 320x240
> > pixels
> > > and each pixel is stored in a byte (unsigned char).  The problem is that
> > > I'm using 16 bit DOS (sorry I promise to move to Linux once I get those
> > > cans!).
> > > My declaration is like this.  I'm using Borland C v4.52
> > >
> > >   unsigned char   camera_image[76800];
> > >
> > > This gets an error that the constant is too large.  Anything dimensioned
> > > above
> > > [32767] gets this error.
> > >
> > > So then I thought well I'll just break up the array into three smaller
> > > pieces
> > > and pray the compiler puts them one after another in memory.  I figure
> > this
> > > should work fine since I only access the array with a pointer,
> > image_ptr++
> > >
> > >   unsigned char   camera_image[30000];
> > >   unsigned char   camera_image2[30000];
> > >   unsigned char   camera_image3[30000];
> > >
> > > Now the compiler is giving a warning that the last two are declared and
> > > never used.
> > > It's probably optimizing them away so I added some bogus code that uses
> > > them.
> > > Still it's not working quite right yet.
> > >
> > > I just want to make sure the compiler reserves enough space in memory!
> > > I think all the code is correct since it works for smaller sized images
> > > like 160x120 or 80x60.
> > >
> > > Any ideas are appreciated,
> > >
> > > -Clay Timmons-
> > >
> > >
> > >
> > > _______________________________________________
> > > DPRGlist mailing list
> > > DPRGlist at dprg.org
> > > http://nimon.ncc.com/mailman/listinfo/dprglist
> > >
> > > _______________________________________________
> > > DPRGlist mailing list
> > > DPRGlist at dprg.org
> > > http://nimon.ncc.com/mailman/listinfo/dprglist
> > >
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist
>


More information about the DPRG mailing list