DOS / PB3.5 Memory Basics?

[John R. Seitz]

Hi all,

I'm looking for a place to learn the correct way to manage DOS memory from within PowerBasic for things like graphic arrays, were/how to BLOAD graphic files, how much 'extra' memory is available to allocate to a large numeric array, etc.

I'm new to PowerBasic and this forum, but have been programming in basic (BBX) for many many years. In a previous life I wrote small DOS .com utilities in assembly. I understand most of the general layout of DOS memory but not completely how PowerBasic interacts with it.

I've recently inherited a moderate sized (200k) PowerBasic program that reads files into large arrays and does vga screen graphics, the program also loads graphic images via BLOAD.

I made some simple changes to the program which changed the executable size by about 16k (smaller)... The program would not run without crashing (CNTRL-ALT-DEL style) and/or some graphic images BLOADed wouldn't display.

My hunch is that some Arrays are declared in the wrong places in the basic program, or there are files being BLOADED into the executable in memory or over some DOS memory, and that by changing the size of the executable, I've caused the program to somehow improperly cross a segment boundary or load graphics into program areas.

I need to learn how to properly use DEF SEG and all the related commands to properly handle the memory needed for this program.

Specifically, I'm looking to learn:

1. After dimensioning a bunch of 4k-10k byte arrays how do I locate them correctly so I can BLOAD the graphics into them? Do I need to take any precautions so they don't cross 64k segment boundaries?

2. How can I tell (within the PB program) where the PowerBasic executable ends up in DOS memory? how much memory is left for additional data arrays and can I have the program allocate the remaining memory to a large array.

3. There are two $segment directives spaced in the source code, how do I know that they are at the 'right' places? For a 200k program, shouldn't there be three $segment directives for a total of four 64k blocks?

4. The program has DIM statements scattered throughout it, many after varying amounts of executable code. Is this a problem, shouldn't most/all? DIM's be in the beginning of the program? How big a problem is this?

5. Is there a way to 'see' the memory layout of the executable and all of the arrays to know where things are going into memory?

Any suggestions on where I can learn more about these issues would greatly appreciated. I've been through my PB-DOS 3.5 manuals but don't feel that I've absorbed all I need to know.

TIA,

John

[Michael Mattias]

. After dimensioning a bunch of 4k-10k byte arrays how do I locate them correctly so I can BLOAD the graphics into them? Do I need to take any precautions so they don't cross 64k segment boundaries?

No precautions are necessary as long as each array is 64 K or less; the compiler always handles this for you.

BLOAD must be executed with DEF SEG set to the VARSEG of the first element of the target array. (As stated and shown in the help file under BLOAD).

2. How can I tell (within the PB program) where the PowerBasic executable ends up in DOS memory? how much memory is left for additional data arrays and can I have the program allocate the remaining memory to a large array.

Under MS-DOS, programs load 'where they will' and will use all available memory. The FRE() series of functions tell you how much memory is currently available for various things. See help file under FRE().

3. There are two $segment directives spaced in the source code, how do I know that they are at the 'right' places? For a 200k program, shouldn't there be three $segment directives for a total of four 64k blocks?

When you compile, the compiler reports the segment sizes in the message box. I think you will get a compile-time error if any one segment would exceed 64K. Not all the 200K exe size is code requiring segmentation, so it's possible you could have only two $SEGMENT directives and be just fine. (e.g., there is a data segment, but I forgot if there are limits on the size of that) .

4 The program has DIM statements scattered throughout it, many after varying amounts of executable code. Is this a problem, shouldn't most/all? DIM's be in the beginning of the program? How big a problem is this

Putting all the DIM statements together at the start of the program I think will result in more static arrays; and is pretty much a 'style' thing. Eg, if you write with lots of procedures (SUBs and FUNCTIONs) you might use LOCAL arrays, which can't be DIM'd "outside" the procedure header/trailer boundaries.

I think you should make sure you are using dynamic arrays, which can be done by using either the $DYNAMIC directive, REDIM instead of DIM, the DYNAMIC option in the DIM statement or by using a variable for the max subscript in the DIM statement. I'm guessing you probably are using dynamic arrays (or program would not load at all if insufficient memory were available), but I'd check anyway.

5. Is there a way to 'see' the memory layout of the executable and all of the arrays to know where things are going into memory?

Well, you can get the address of any variable using VARSEG + VARPTR; from that I guess you could make a map. But that can't tell you anything important at all. Either the array is there or it ain't. You can know this by testing the ERR value after the DIM/REDIM (if program has error trapping enabled) or when the program aborts on a runtime error 7 (when error trapping is NOT enabled and you generate a run time error).

I need to learn how to properly use DEF SEG and all the related commands to properly handle the memory needed for this program

Yes.

MCM

[Hans Ruegg]

There are also CODESEG / CODEPTR statements which will return the location of a specific piece of the executable code in memory.