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
Allocating 64k of memory in DOS
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
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.
=======================================
A man with no head is still a man.
A head with no man is plain freaky.
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.
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.
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
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
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
-Andreas
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
Thanx
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
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
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
#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.
http://members.theglobe.com/hecate_image/farmalloc.png
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement