tc and 64kb limit.....

hello there

somewhy the tc++ doesnt let me pass the 64kb limit.
i tryed malloc,farmalloc,and memory models - nothing !!!
i do not wish to use vc or external programs.
i might use later xms and ems but to transfer to xms memorys of 64kb i need free 64kb. shortly i need heap.

so if someone can tell me why the memory models, and farmalloc didnt helped and what can i do about it to fix it ill be very glad.
(more important for me to find how to get that heap then other ways to send to xms)

thank you

dolev

Comments

  • : hello there
    :
    : somewhy the tc++ doesnt let me pass the 64kb limit.
    : i tryed malloc,farmalloc,and memory models - nothing !!!
    : i do not wish to use vc or external programs.
    : i might use later xms and ems but to transfer to xms memorys of 64kb i need free 64kb. shortly i need heap.
    :
    : so if someone can tell me why the memory models, and farmalloc didnt helped and what can i do about it to fix it ill be very glad.
    : (more important for me to find how to get that heap then other ways to send to xms)
    :
    : thank you
    :
    : dolev
    :

    your tc compiler is very very ancient -- if you build with the large memory model the program can use up to 640K memory, minus the amount needed by the os and other device drivers, which will bring that down to somewhere about 450K to 500K or so. If you need more memory than that, then you will have to move to a modern 32-bit compiler, such as free Dev-C++ at www.bloodshed.net.
  • i know that compiler is ancient but i must use it...
    i tryed the lardge memory model but it still didnt enabled me to pass the 64k. otherwise i wouldnt post that message.
    and i sayed i also tryed the far version.
    nothing helped me pass the 64k.

    i will be happy to recieve more help

    dolev
  • [b][red]This message was edited by stober at 2005-12-30 16:58:37[/red][/b][hr]
    : i know that compiler is ancient but i must use it...
    : i tryed the lardge memory model but it still didnt enabled me to pass the 64k. otherwise i wouldnt post that message.
    : and i sayed i also tryed the far version.
    : nothing helped me pass the 64k.
    :
    : i will be happy to recieve more help
    :
    : dolev
    :

    I feel your pain -- I went through that for 10 years when writing for embedded systems using MS-DOS 6.X.

    it isn't possible to allocate an array larger than 64K. impossible with your compiler. Its also not possible to have a code segment larger than 64K -- no function can be bigger than 64K. That's one reason why most of us tossed that operating system out a long time ago. Port the program to *nix or MS-Windows and you will have unlimited (almost) memory. But I know if you are writing for an embedded system changing compilers may not be an option. Well, in that case you will have to find some other way to do what you want, such as divide the array up into several smallar arrays, use disk files to hold parts of arrays that are not being accessed. There are several tricks, all of them will just slow down your program. Even using an ems driver to get more memory will slow down the program.


  • a) damn.....
    b) i need to get at least the normal heap as i have done in pascal 640kb splitted to 64k segments.
    there every pointer could have reach 64k and there was total of 640kb.
    why here it doesnt?
    at least this i need.....

    (by the way - i found a program in pascal that someone have build that reachs all the RAM memory using dpmi, but again 64kb segments....)


    thanks again
    dolev

  • [b][red]This message was edited by stober at 2005-12-30 20:37:11[/red][/b][hr]
    : a) damn.....
    : b) i need to get at least the normal heap as i have done in pascal 640kb splitted to 64k segments.
    : there every pointer could have reach 64k and there was total of 640kb.
    : why here it doesnt?
    : at least this i need.....
    :
    : (by the way - i found a program in pascal that someone have build that reachs all the RAM memory using dpmi, but again 64kb segments....)
    :
    :
    : thanks again
    : dolev
    :
    :


    the compiler will also let you reach 640K limit with 64K segment pointers -- what I was referring to earlier was runtime limits, which your PASCAL program also had to encounter. It doesn't matter what language the program is written in, 640K - operating system - TSRs is the runtime limit.

    C can also reach dpmi, you need a dpmi device driver, and header file. I've done it before but don't recall just how it was done any more.
  • : hello there
    :
    : somewhy the tc++ doesnt let me pass the 64kb limit.
    : i tryed malloc,farmalloc,and memory models - nothing !!!
    : i do not wish to use vc or external programs.
    : i might use later xms and ems but to transfer to xms memorys of 64kb i need free 64kb. shortly i need heap.
    :
    : so if someone can tell me why the memory models, and farmalloc didnt helped and what can i do about it to fix it ill be very glad.
    : (more important for me to find how to get that heap then other ways to send to xms)
    :
    : thank you
    :
    : dolev
    :
    [green]
    Try this and see if it works. I found it at a website on TC.
    [/green]
    [code]
    Q. My far pointers "wrap around" when they are incremented over 64K. How do I reference a data object that is greater than 64K?
    A. Use huge pointers.


    Q. Can I declare more than 64K of global variables?
    A. You may have a total of up to 64K global and static data in the Tiny, Small, Medium, Compact and Large memory models. In the Huge model, the maximum is 64K per source module.


    Q. How do I declare an array that's greater than 64K?
    A. Arrays greater than 64K must be allocated off the heap. If, for example you wanted a two-dimensional array of characters that was 1024 by 128, the declaration you would expect to write would be:

    char array[1024][128];

    But since the size of this array is greater than 64K, it must be allocated off the heap. An example of this is:

    #include

    char (huge *array)[128];
    :
    main()
    {
    :
    array = farcalloc(sizeof(*array), 1024);
    :
    }

    The array can be accessed with the same code as an array not allocated off the heap. For example:

    i = array[30][56];

    will assign "i" the value stored at the 31st by 57th element in "array".

    The use of the "huge" keyword is necessary in the declaration of "array" since only a huge pointer can address objects greater than 64k. For further discussion of huge pointers, refer to the User's Guide.
    [/code]

  • i tryed this also.
    somewhy the far and the huge still use the same data segment of the program and takes mallocs memory again. like farmalloc and malloc are the same !!!???
    man - thats damn strange....


    thx anyway.....

    dolev
  • : i tryed this also.
    : somewhy the far and the huge still use the same data segment of the program and takes mallocs memory again. like farmalloc and malloc are the same !!!???
    : man - thats damn strange....
    :
    :
    : thx anyway.....
    :
    : dolev
    :

    in large and huge memory models malloc() will just simply call farmalloc(). Nothing strange about it, if you read your compiler's documentation, or google for keywords.
  • [b][red]This message was edited by shaolin007 at 2005-12-31 14:16:49[/red][/b][hr]
    : i tryed this also.
    : somewhy the far and the huge still use the same data segment of the program and takes mallocs memory again. like farmalloc and malloc are the same !!!???
    : man - thats damn strange....
    :
    :
    : thx anyway.....
    :
    : dolev
    :
    [green]
    All I can say is post the code portion that you are having a problem with so that others can take a look at it in more detail. Crazy question, are you allocating the memory off the heap or in main() function? Did you check the return code to see if there was an error returned?
    [/green]



  • i tryed generaly to check how much memory left using this.
    (althought i found it true in several acations.)


    void main()
    {
    void far *pt;
    long rus;
    char str[10];

    rus = 0;
    do
    pt = (char far*)farmalloc(100);
    rus += 100;
    while (pt != NULL);

    ltoa(rus,str,10);
    puts(str);

    getch();
    }



    well - thats not a code copy, but that sort of what i did to check the memory. it works althought i do not free the memory(the memory automaticly get freed once i finished running).
    i checked it for example also from allocating other pointers and checking if the memory drops down and it did in the same amount of size. it never passed the 64kb. and it uses the same memory of malloc, althought my pointer is far...

    im happy to get some of your help (-:

    dolev








  • [blue]If TC was not alowing for code and data over 64 Kb - it would not have been used so widely in the 90's!

    Use [b]huge[/b] pointers, not [b]far[/b] pointers.

    Few advices:

    1. Use function coreleft() to check on amount of left memory.
    2. Rearrange your data better, so it will fit into few segments of 64Kb.
    3. If not possible, use calloc() to allocate memory - it allocates more
    than 64Kb. To scan the array from calloc() use huge pointers.
    4. Using files for temporary storage will increase your available memory to huge amounts. The code will be slower, since you will be reading/writing files, but it WILL WORK.
    5. If using files for storage - do not use records with the variable length - use fixed size - preferably a multiple of 128. Well, you get the point - do not operate on disk byte-by-byte. Better allocate 64 Kb and operate on these pieces of memory.
    [/blue]
    [code]
    : void main()
    : {
    : void far *pt;
    : long rus;
    : char str[10];
    :
    : rus = 0;
    : do
    : pt = (char far*)farmalloc(100);
    : rus += 100;
    : while (pt != NULL);
    :
    : ltoa(rus,str,10);
    : puts(str);
    :
    : getch();
    : }
    [/code]

  • [code]
    #include
    #include

    char (huge *array)[128]; /* Allocate 131,072 bytes */

    main()
    {
    char x;
    array = farcalloc(sizeof(*array), 1024);

    if (array==0)
    printf("Not enough memory!
    ");

    x=array[23][109];

    more code...
    }
    [/code]

    [green]
    Try something like that similiar in your code and see if it works.
    [/green]
  • [blue]Do not run the program with large memory requirements from Turbo C itself - run it outside of TC. Usually, very little memory left in DOS to run both TC and your large program. It will be harder to debug, but you can use logging to debug the application - just like old times...
    [/blue]


  • for 16 bit DOS targets one method to get the size of the largest available memory block is as follows:

    [code]
    long memavail(void)
    {
    union REGS regs;

    /* Request impossibly large number of 16-byte paragraphs from DOS */

    regs.h.ah = 0x48;
    regs.x.bx = 0xFFFF;

    int86(0x21,&regs,&regs);

    return((long)regs.x.bx * 16L);
    }
    [/code]



    : i tryed generaly to check how much memory left using this.
    : (althought i found it true in several acations.)
    :
    :
    : void main()
    : {
    : void far *pt;
    : long rus;
    : char str[10];
    :
    : rus = 0;
    : do
    : pt = (char far*)farmalloc(100);
    : rus += 100;
    : while (pt != NULL);
    :
    : ltoa(rus,str,10);
    : puts(str);
    :
    : getch();
    : }
    :
    :
    :
    : well - thats not a code copy, but that sort of what i did to check the memory. it works althought i do not free the memory(the memory automaticly get freed once i finished running).
    : i checked it for example also from allocating other pointers and checking if the memory drops down and it did in the same amount of size. it never passed the 64kb. and it uses the same memory of malloc, althought my pointer is far...
    :
    : im happy to get some of your help (-:
    :
    : dolev
    :
    :
    :
    :
    :
    :
    :
    :
    :

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories