Page 1 of 1

COM memory arena?

PostPosted: Fri Aug 13, 2010 8:25 pm
by CommodoreJohn
So I'm working on a DOS project (writing a game engine in 8086 assembler, to be specific.) I'd like to build it as a COM file, mostly to save myself the hassle of linking individual bits together. If Wikipedia is to be believed, DOS's memory-management facilities are not available to COM programs; it states that "all memory is available to the application." This suits me fine, as I wanted a couple facets of memory management to line up with the rest of the engine more neatly, and it wasn't all that hard to hack up replacements for the routines I need. The thing is, I'm also trying to write the engine to play nicely with its operating environment; I want it to be able to make a nice clean exit and leave the computer in exactly the same state it found it, and I want to make sure that I know how to do my own memory management without clobbering any drivers or other TSR software loaded into conventional memory.

I'm currently figuring that it's a safe assumption that the program will be loaded fairly low in memory, so I don't need to bother with reading or writing below the start of the program segment, which means that I only need to worry about stuff that's been loaded under the top boundary of the conventional memory area (it's my understanding that this is where DOS and drivers tend to go.) I see an entry in the Program Segment Prefix for memory size, and what I'm wondering is if this reflects the actual, physical amount of conventional memory installed, or the amount free when my program was loaded; i.e., can I rely on that value to tell me where I should not write past?

Re: COM memory arena?

PostPosted: Fri Jan 07, 2011 12:56 am
by Retro
Hi, so did you make any progress with this? Sounds interesting.

As I understand it, DOS allocates all available memory to a COM program because it has no idea how much the program will actually need. So the simple answer to your question would be "yes". Any other drivers or TSRs already loaded should be below your program. In fact, the only thing above it should be the transient portion of COMMAND.COM, which gets reloaded by the resident portion if your program happens to clobber it.

It's not clear whether you intend this game engine to be a separate resident (TSR) and load other programs above it. If that's the case, normal practice is to shift its stack and release any memory it doesn't need back to DOS before terminating.

Re: COM memory arena?

PostPosted: Fri Jan 07, 2011 8:05 am
by CommodoreJohn
Yes, that's what I'd gathered from another forum. I wasn't intending for a TSR, though - I just wanted to figure out how safely I could write to the area between the end of the program and the top of conventional memory, as I want to use a custom memory manager for game resources, so's I can implement some basic garbage-collection.