troubles with 48h function

[ghjjkl]

i've got some problems with 48h function (memory allocation)

input:
ah - 48h
bx - number of blocks to be allocated
output:
ax - segment address of block to be allocated / error code
bx - number of max available blocks (if there's not enough memory)

once program meets int 21h i can't see any code i've assembled. I have no idea why but cs doesnt point on my code anymore - it's set on 0000h, and i see yet another code, afdpro sends "invalid opcode", and my program stucks. What could this mean?

[Gunther]

Hi ghjjkl,

that function makes usual no problems. Please post your code here and we'll see.

Gunther

[sinsi]

If you are using DEBUG to trace your code, use P to "proceed" past the INT 21 call instead of T to "trace" through it.

[ghjjkl]

smth like this:

Code: [Select]

.data

__ptr dw 0

__block db 1,2,3,4
             db 5,6,7,8
             db 9,10,11,12
             db 13,14,15,16

DATA_SIZE equ 16

(...)

.code

mov ax,@data
mov ds,ax

xor ax,ax
mov ah,48h
mov bx,DATA_SIZE/16
int 21h

mov __ptr,ax

(...)

mov ax,__ptr
mov es,ax
mov si, offset __block
xor di,di
mov cx,DATA_SIZE
rep movsb



[ghjjkl]

maybe i should reallocate memory block first, using function 4ah?

[GoneFishing]

I have never used afdpro  but all debuggers have  options to Step into and Step over the code . When at int 21 line try to hit Step over (don't know how exactly it's called in afdpro) - This is what sinsi has advised to you .
Let us know if this will not help .

[nidud]

deleted

[FORTRANS]

maybe i should reallocate memory block first, using function 4ah?

Yes, you should.

Hi,

    By default, MS-DOS allocates all memory to a program when
loading it.  Therefor you must free some memory before using
Function 48H, Allocate Memory, or there will not be any free
memory to be allocated.  You can use Function 4AH, Free
Allocated Memory, to release some memory.  Or you can use
the linker option /CPARMAXALLOC to have the loader allocate
less memory at program load and execute.

HTH,

Steve

[ghjjkl]

thank you all,  /CPARMAXALLOC, that's it    :t

[nidud]

deleted

[ghjjkl]

why does ax contain 0008h after memory allocation? There's not enough memory, i suppose, yep? If i try turbo debugger instead afdpro it seems to be okay  :icon_exclaim:

[dedndave]

hmmmm - it means "insufficient memory"

personally, i would use the other method
if you specify .DOSSEG, you get DOS ordered segments
The .DOSSEG directive orders segments as follows:

1. Code segments
2. Data segments, in this order:
a. Segments not in class BSS or STACK
b. Class BSS segments
c. Class STACK segments

so, i would start the program with something like this:

Code: [Select]

        .MODEL  Small
        .STACK  4096
        .DOSSEG
        .386
        OPTION  CaseMap:Nonethen, you can use the stack segment and initial SP to calculate the end of the program
use the PSP segment to get the start, if needed
and free all memory above the loaded EXE

another reason for doing it that way.....
let's say it did work with the /CPARMAXALLOC switch (or by modifying the header with EXEMOD)...
a year later, you come along and forget that switch and it doesn't work   :(

[Gunther]

personally, i would use the other method
if you specify .DOSSEG, you get DOS ordered segments
The .DOSSEG directive orders segments as follows:

1. Code segments
2. Data segments, in this order:
a. Segments not in class BSS or STACK
b. Class BSS segments
c. Class STACK segments

so, i would start the program with something like this:

Code: [Select]

        .MODEL  Small
        .STACK  4096
        .DOSSEG
        .386
        OPTION  CaseMap:None

that's a good proposal. Another way is to name the segment in your source code simply by enumeration. The linker must link the segments in that order. The stack should be the last segment. A working example for shrinking the memory and allocating new memory you'll find here. Please check the file dpmi32.asm.

Gunther

[GoneFishing]

why does ax contain 0008h after memory allocation? There's not enough memory, i suppose, yep? If i try turbo debugger instead afdpro it seems to be okay  :icon_exclaim:

Yes, now I'm recalling that I managed to step into DOS interrupts with Turbo debugger  :t

[nidud]

deleted