Author Topic: troubles with 48h function  (Read 6041 times)

ghjjkl

  • Member
  • **
  • Posts: 53
troubles with 48h function
« on: June 23, 2014, 05:01:58 PM »
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

  • Member
  • *****
  • Posts: 3518
  • Forgive your enemies, but never forget their names
Re: troubles with 48h function
« Reply #1 on: June 23, 2014, 05:58:46 PM »
Hi ghjjkl,

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

Gunther
Get your facts first, and then you can distort them.

sinsi

  • Member
  • *****
  • Posts: 1007
Re: troubles with 48h function
« Reply #2 on: June 23, 2014, 06:25:14 PM »
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.
I can walk on water but stagger on beer.

ghjjkl

  • Member
  • **
  • Posts: 53
Re: troubles with 48h function
« Reply #3 on: June 23, 2014, 06:33:56 PM »
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

  • Member
  • **
  • Posts: 53
Re: troubles with 48h function
« Reply #4 on: June 23, 2014, 06:40:55 PM »
maybe i should reallocate memory block first, using function 4ah?

GoneFishing

  • Member
  • ****
  • Posts: 967
  • Gone fishing
Re: troubles with 48h function
« Reply #5 on: June 23, 2014, 07:04:08 PM »
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

  • Member
  • *****
  • Posts: 1411
    • https://github.com/nidud/asmc
Re: troubles with 48h function
« Reply #6 on: June 23, 2014, 07:30:20 PM »
maybe i should reallocate memory block first, using function 4ah?

Yes, you should.

FORTRANS

  • Member
  • ****
  • Posts: 946
Re: troubles with 48h function
« Reply #7 on: June 23, 2014, 11:03:35 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

  • Member
  • **
  • Posts: 53
Re: troubles with 48h function
« Reply #8 on: June 24, 2014, 12:09:00 AM »
thank you all,  /CPARMAXALLOC, that's it    :t

nidud

  • Member
  • *****
  • Posts: 1411
    • https://github.com/nidud/asmc
Re: troubles with 48h function
« Reply #9 on: June 24, 2014, 12:25:42 AM »
4Ah - RESIZE MEMORY BLOCK

the size of the program is (STACK - PSP)
the start of the program (PSP) is in ES on startup
the end is (SS + SP / 16)

assuming the stack size is 128 the new size may be set like this:
Code: [Select]
mov dx,ss ; Stack segment
mov bx,128 / 16 + 1 ; stack size in paragraphs
add bx,dx ; BX = end
mov ax,es ; ES = PSP (start)
sub bx,ax ; BX = new size in paragraphs
mov ah,4Ah
int 21h

the stack size could also be calculated from SP:
Code: [Select]
mov bx,sp
add bx,15
shr bx,4

ghjjkl

  • Member
  • **
  • Posts: 53
Re: troubles with 48h function
« Reply #10 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:

dedndave

  • Member
  • *****
  • Posts: 8752
  • Still using Abacus 2.0
    • DednDave
Re: troubles with 48h function
« Reply #11 on: June 24, 2014, 02:51:49 AM »
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:
Quote
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
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

  • Member
  • *****
  • Posts: 3518
  • Forgive your enemies, but never forget their names
Re: troubles with 48h function
« Reply #12 on: June 24, 2014, 03:02:20 AM »
personally, i would use the other method
if you specify .DOSSEG, you get DOS ordered segments
The .DOSSEG directive orders segments as follows:
Quote
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
Get your facts first, and then you can distort them.

GoneFishing

  • Member
  • ****
  • Posts: 967
  • Gone fishing
Re: troubles with 48h function
« Reply #13 on: June 24, 2014, 03:28:12 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

  • Member
  • *****
  • Posts: 1411
    • https://github.com/nidud/asmc
Re: troubles with 48h function
« Reply #14 on: June 24, 2014, 03:31:39 AM »
Some other things to consider..

The debugger also use some of this memory but will use EMM if available. If you running XP you may want to install this

After resizing, the start of the heap will be the end of the stack, and the normal way to allocate memory is to extend the size of the program using 4Ah. This is faster and more rational than using 48h, and all memory will then also be freed on exit.