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?
Hi ghjjkl,
that function makes usual no problems. Please post your code here and we'll see.
Gunther
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.
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
maybe i should reallocate memory block first, using function 4ah?
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 .
deleted
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
thank you all, /CPARMAXALLOC, that's it :t
deleted
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:
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: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 :(
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 (http://masm32.com/board/index.php?topic=2100.msg21948#msg21948). Please check the file dpmi32.asm.
Gunther
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
deleted
thank you all, finally it works! Set you /CPARMAXALLOC for the greater good :t
but still one thing. Could you tell me, why doesnt file open? I use function 3dh, al=0, but after int 21h i get ax=05h=access denied. What should i do to open that file?
Hi,
Access denied usually means that you don't have access rights
to the file (ownership), or the file has been opened by another
process and will not share it. You can try Function 59H , Get
Extended Error, to get more information about why the error
occurred, and possible actions to take.
Without seeing your code that is about all that can be said.
HTH,
Steve N.
hmfff when i use afdpro, ax=0008h(insufficient memory), but when i use td, ax=0002h(file not fount),(when i use function 59h) so what if i created this file in my program? I wrote some data to it, an then closed it, and all bytes were written correctly. :(
very few forum members are familiar with AdfPro
one logical guess might be that the AdfPro debugger EXE allocates all available memory to itself
so, when you try to access it, none is available
i.e., not necessarily the fault of your code :biggrin:
hmfff ax=0005h but CF is turned off... magick
DOS standard handles
0000 STDIN
0001 STDOUT
0002 STDERR
0003 STDAUX
0004 STDPRN
So the next free handle would be...0005 (with NC)
if the carry flag is clear, no error
well - that's how it's supposed to work
i dont know why but now it appears to work! :biggrin: