News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

troubles with 48h function

Started by ghjjkl, June 23, 2014, 05:01:58 PM

Previous topic - Next topic

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
You have to know the facts before you can distort them.

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:

.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

#6
deleted

FORTRANS

Quote from: nidud on June 23, 2014, 07:30:20 PM
Quote from: ghjjkl on June 23, 2014, 06:40:55 PM
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

#9
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:
Quote1. 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:
        .MODEL  Small
        .STACK  4096
        .DOSSEG
        .386
        OPTION  CaseMap:None

then, 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

Quote from: dedndave on June 24, 2014, 02:51:49 AM
personally, i would use the other method
if you specify .DOSSEG, you get DOS ordered segments
The .DOSSEG directive orders segments as follows:
Quote1. 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:
        .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
You have to know the facts before you can distort them.

GoneFishing

Quote from: ghjjkl on June 24, 2014, 12:53:15 AM
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

#14
deleted