Archived

This topic is now archived and is closed to further replies.

NuffSaid

Allocating 64k of memory in DOS

Recommended Posts

Hi guys, Recently, I found my borland C++ 3.1 again, after years of being kept in my closet I tried programming MODE 13 graphics again. However, there seems to be a problem. I can''t alocate 64000 bytes for my double buffer. What gives? I set the memory model to medium, it fails. I set it to large, it fails. Does anyone remember how to allocate 64k of memory? I set it to tiny, it still fails(duh, obviously
    
unsigned char far *buffer = farmalloc(64000);
//this fails <img src="sad.gif" width=15 height=15 align=middle>

    
Sigh, any help would be appreciated. ======================================================== If something sounds stupid but works, it's not stupid

Share this post


Link to post
Share on other sites
It''s been years since I''ve worked in DOS, but that simply means (to me) that you just don''t have the 64k!

=======================================
A man with no head is still a man.
A head with no man is plain freaky.

Share this post


Link to post
Share on other sites
Wow, it has been so long since I did any 16 bit programming and I am not sure if I am remembering this correctly.
I think that there is also a huge memory model that should work for you. If I remember it right the large memory model gives you a single 64k data segment and multiple 64k code segments. Medium gives you a single 64k data segment and a single 64k code segment. Huge will give you multiple 64k data and code segments.

Share this post


Link to post
Share on other sites
Zipster :
No, I do have 64k. in fact, I''ve got 2000 time that amount of ram. Not that it matters though So nah, that couldn''t be it.

bstach:
I''ve tried all the memory models. medium, large, compact, huge. Nope, zip. doesn''t work. It only allocates up to 61000 bytes.

16 bit programming is really horrible. Now I rememebr why I left for 32 bit. Anyway, I''d still like to know how to allocate 64k of memory. I''m feeling nostalgic



========================================================
If something sounds stupid but works, it's not stupid

Share this post


Link to post
Share on other sites
I remember in Borland Turbo C++ for DOS that I had to change the heap size to a large amount (300K+). That always worked for me. Maybe it is the same with Borland C++ for DOS.

-Andreas

Share this post


Link to post
Share on other sites
Awright, now we''re getting somewhere. Icarus, how do you change the heap size? I have no idea how to do that. Is it in the config.sys, autoexec.bat or some flags in the compiler?

Thanx

Share this post


Link to post
Share on other sites
In c++ for dos, there is an optimization in the debug settings which are set to 64... i usually put that for 512 Kb and it works.. probably that is the Heap

Share this post


Link to post
Share on other sites
I don''t remember exactly how to allocate it. I am fairly sure that farmalloc in a huge program should do it. Maybe there was a hugealloc. Don''t try to increase the heap size, it is already taking up all of the free memory except for the stack. One way that could work is take space from the stack, and have dos allocate it for you. I think you can do it through one of those interupts. There''s a linked list, and you have to go through it to find a free space.

The big problem is that you probably don''t remember what happens when you allocate more than 64k. Do you remember segment:offset? If you allocate more than 64k its a pain to itterate through it since one memory location has more than one segment:offset pair that points to it

Share this post


Link to post
Share on other sites
#include 
void main(void)
{
unsigned int i;
unsigned char far *buffer=(unsigned char far *)farmalloc(64000);
for(i=0;i<64000;i++)
buffer=i;
farfree(buffer);
}


Make sure that you tell it to assign it as an unsigned character pointer. farmalloc() by default returns integers.

and if you give a damn, this might help you to see how the hell I compiled it.

[url=http://members.theglobe.com/hecate_image/farmalloc.png]http://members.theglobe.com/hecate_image/farmalloc.png[/url]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Ahh crap, partial UBB code.

stuff it, it is only 10kb
code is in the image somewhere.
compiled with tiny memory model into a com file
bcc.exe - 16bit DOS compiler
-mt - tiny memory option (also m for medium, h for huge and l for large, and s for small. Makes sense)
-lt - linker option to change it to a COM file target (proves that it is a tiny memory mode)
far.c - source code

Share this post


Link to post
Share on other sites
There is an easy answer to this question. Just use a 32-bit DOS extender, such as the one PharLap software used to make (called 386/DOS Extender SDK. I have a copy on my shelf from years ago.).

A DOS extender effectively lets you write 32 bit applications that run in the protected mode of 386 and higher processors. You have a full flat memory model up to 4GB and you have no problem allocating 64,000 bytes. The extender is basically a stub program, based in 16-bit mode, that switches the processor to protected mode, loads the application into flat memory, then calls a function in the main application to start it running. The memory footprint of the extender is small and there is a mechanism to share a fragment of memory with a 16-bit TSR if necessary (say, for video driver access).

Back in 1990-92 I was working on a 3D scientific visualization package called Reveal which worked with PharLap''s toolkit. We were able to allocate and use a full 8MB of RAM (all we had at the time) for our software. We actually had a full graphics pipeline, with gouraud shading and a 16-bit Z-buffer running under this system.

Don''t know if PharLap''s DOS extender is still available. It might be. Check out www.provantage.com or www.pparadise.com.

I would imagine that you can find a freeware/shareware DOS extender at this time. I''d bet that there is someone out there still using them.

You might have to do some research to figure out how to link applications to the DOS extender that were built with a modern compiler. We used a specialized compiler back then, since Borland and Microsoft were still 16-bit. I think Microway had a compiler that worked with the PharLap extender. I don''t remember all the details.... Hell, something like Borland 4.5 or GNU might actually work. There may even be a DOS extender under the GNU public license.

Graham


Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.
email: grhodes@sed.ara.com

Share this post


Link to post
Share on other sites