Far Malloc?

[prozacgod]

how does one alloc beyond a 64k segment? Currently messing around with writing a mode 13h game, and right after implementing my backbuffer, it all came crashing down.

My LUTS for my raycaster ate up about ~30k of memory, and so the malloc fails when getting the graphics buffer.

I'm guessing that I'd need some far malloc, but I'm not sure where to get reference materials on how to even sort ouf the answer here.

[tkchia]

Hello @prozacgod,

For gcc-ia16, you can use my non-standard libi86 library (https://gitlab.com/tkchia/libi86), which currently implements functions _dos_allocmem (...) and _dos_freemem (...). Note that _dos_allocmem expects a count of paragraphs (16-byte units), not bytes, and it always directly asks MS-DOS for memory rather than doing its own memory management.

My libi86 aims to be compatible with Open Watcom's C runtime library, so it basically uses the documentation for that library as the reference point (https://github.com/open-watcom/open-watcom-v2-wikidocs/blob/master/docs/clib.pdf). (I hope to also get around to implementing in libi86 some other far memory allocation functions that are supported by OW, such as _fmalloc and maybe even halloc.)

Other compilers such as Borland Turbo C++ have their own incompatible interfaces, so if you are considering porting your program to those as well, you will need to look up their documentation separately.

Thank you!

[prozacgod]

It looks like your _dos_allocmem calls the int21 services for memory allocation. so just to be clear when exe files generated by gcc-ia16 are ran they don't allocate more than 2 64k block of memory, one for the code and one for data?

Okay, so I'm guesing that gcc-ia16 targets the small memory model? ( CS != DS, I think that's small - tiny is CS == DS ) and at the moment can't generate more than 64k code?

But other than that all of conventional memory is available? Int 21/48h will allow you to allocate memory as needed/available (it doesn't just assume you're using all available memory).

EDIT: Also feel free to correct me if I'm just way off into left field here, I could be getting a bunch of stuff wrong. That part of my brain is rather dusty.

[tkchia]

Hello @prozacgod,

Okay, so I'm guesing that gcc-ia16 targets the small memory model? ( CS != DS, I think that's small - tiny is CS == DS ) and at the moment can't generate more than 64k code?

gcc-ia16 currently defaults to the tiny memory model (64KiB combined code and data). You can ask to use the small memory model (64 KiB code + 64 KiB data) using the -mcmodel=small option. There is also experimental support for the medium memory model (multiple code segments + 64 KiB data), with -mcmodel=medium.

so just to be clear when exe files generated by gcc-ia16 are ran they don't allocate more than 2 64k block of memory, one for the code and one for data?

For the small and medium models in gcc-ia16, I arrange for the output .exe file headers --- specifically the "maximum allocation" fields --- to be filled in such a way that MS-DOS only allocates the memory needed for the code and data segments at startup.

As for tiny model programs, i.e. .com files, I arrange for them to shrink their own memory blocks to 64 KiB at startup.

Thus either way, yes, you can use _dos_allocmem (...) to allocate any remaining memory.

Thank you!

[prozacgod]

I managed to implement my own dosallocmem function with some inline assembler, and I have broken the 64k barrier!....

I have enabled medium mode and we'll see how this all fairs - thanks for the help.

[tkchia]

Hello @prozacgod,

Cool. :-) Thanks!