Hello everybody,
I'm using int 21h, function 42h (move file pointer) With al=02, cx=0 and dx=0 this function moves the file pointer to the end of the file and the file length is returned in dx:ax For example dx=000bh and ax=5400h the file length is actually b5400h. How can I put these two values together and save in a variable for future use when I'm using 16 bit registers? Is this possible? I tried shifting left, rotating, adding, it just doesn't seem to work.
Any help or suggestions appreciated.
best regards,
czDrillard
I'm using int 21h, function 42h (move file pointer) With al=02, cx=0 and dx=0 this function moves the file pointer to the end of the file and the file length is returned in dx:ax For example dx=000bh and ax=5400h the file length is actually b5400h. How can I put these two values together and save in a variable for future use when I'm using 16 bit registers? Is this possible? I tried shifting left, rotating, adding, it just doesn't seem to work.
Any help or suggestions appreciated.
best regards,
czDrillard
Hi czDrillard,
Maybe this:
I don?t know if it?ll work?
The problem is that you are accesing a 32-bit variable with two 16-bit registers.
Maybe ypou should just use 2 16-bit registers like in dx:ax, even though it's only a 20-bit pointer.
Sounds funny, but that is the way, I think.
Maybe this:
push dx
push ax
pop dword [variable]
I don?t know if it?ll work?
The problem is that you are accesing a 32-bit variable with two 16-bit registers.
Maybe ypou should just use 2 16-bit registers like in dx:ax, even though it's only a 20-bit pointer.
Sounds funny, but that is the way, I think.
Hi sloppy, thanks for your reply. I tried it and it didn't work:( However, I found this method does work...sort of.
mov ,dx ;where dx = 000Bh
mov ,ax ;and ax = 5410h
dwFileLen is declared as dd 0
only problem is dwFileLen looks like this: 0B001054h
instead of 000B5410h (true file length) This is due to the Little Endian format. Anybody got any ideas on the best way to deal with this so that I end up with a meaningful file length?
best regards,
czDrillard
mov ,dx ;where dx = 000Bh
mov ,ax ;and ax = 5410h
dwFileLen is declared as dd 0
only problem is dwFileLen looks like this: 0B001054h
instead of 000B5410h (true file length) This is due to the Little Endian format. Anybody got any ideas on the best way to deal with this so that I end up with a meaningful file length?
best regards,
czDrillard
First, you should store ax in the lower memory location so that dWord is in correct order.
When you load the values back into the registers the order will be restored.
When you load the values back into the registers the order will be restored.
Thanks eet_1024 for your reply. This looks much better, (1054B000h) but it is reversed and if I use it as file length it is still not right. Is there any way to get the number into memory so it looks like this 000B5410h ? Or am I blind to something obvious. I want to be able to decrement the number one step at a time and don't know how to do this with a reversed number.
best regards,
czDrillard
best regards,
czDrillard
The intel processors store numbers in so-called 'Little-Endian' notation:
that is, if you have the hex number 1234h, the processor stores:
Similarly, if you have a hex number 12345678h, the processor stores:
This is the NORMAL way the intel processors work. 680x0 and compatible processors use the Big-Endian notation which is looks more 'normal' when dumped.
When the data is dumped or displayed as bytes, you need to realize that the processor stores numbers in reverse order, so you must mentally rearrange the numbers. This, in the opinion of the defenders of Little-Endian, is the only advantage that Big-Endians have, aside from the supposed weakness of Big-Endian notation. In any case, if you store the two numbers in the way that eet_1024 described, then load it into a 32-bit register, the number WILL be in proper order.
I hope that helped.
that is, if you have the hex number 1234h, the processor stores:
addr n#
0000 34
0001 12
Similarly, if you have a hex number 12345678h, the processor stores:
addr n#
0000 78h
0001 56h
0002 34h
0003 12h
This is the NORMAL way the intel processors work. 680x0 and compatible processors use the Big-Endian notation which is looks more 'normal' when dumped.
When the data is dumped or displayed as bytes, you need to realize that the processor stores numbers in reverse order, so you must mentally rearrange the numbers. This, in the opinion of the defenders of Little-Endian, is the only advantage that Big-Endians have, aside from the supposed weakness of Big-Endian notation. In any case, if you store the two numbers in the way that eet_1024 described, then load it into a 32-bit register, the number WILL be in proper order.
I hope that helped.
Thanks AmkG, the trouble is I can't load it into a 32 bit register. I'm running this program in '8086' mode so all my registers are only 16 bit but the file size is too big to fit in one 16 bit register :(
best regards,
czDrillard
best regards,
czDrillard
And you need to do 32-bit maths in 16-bit mode, I presume?
Okay, so you use <TADAA> the CARRY BIT!
(One advantage of starting programming on an 8-bit comp.: you learn about stuff 32-bit programmers rarely get into.)
You are now getting into multi-word computations.
Now you must know that if you add:
and you are 16-bit code, you will get ZERO.
However, a flag in the processor's status, known as the CARRY FLAG, will be SET if you do such a thing.
This means that, an extra bit had to be carried over to the next word. So if you are simulating 32-bit maths in 16-bit code, you must add an extra 1 to the higher word if the carry flag is set.
Now there are two instructions, ADC and SBC, which take the carry flag into account. They will automatically add (or subtract, as in the case of SBC) that extra 1 to a word if the carry flag is set. If it is reset, then ADC and SBC work in exactly the same way as ADD and SUB.
This means that, if you want to add 32 to a 32-bit number in 16-bit mode:
To increment, you add 1!
I hope this helps.
Also BTW this can also be done in 32-bit mode to work with 64-bit numbers.
Okay, so you use <TADAA> the CARRY BIT!
(One advantage of starting programming on an 8-bit comp.: you learn about stuff 32-bit programmers rarely get into.)
You are now getting into multi-word computations.
Now you must know that if you add:
1000000000000000b
+1000000000000000b
and you are 16-bit code, you will get ZERO.
However, a flag in the processor's status, known as the CARRY FLAG, will be SET if you do such a thing.
This means that, an extra bit had to be carried over to the next word. So if you are simulating 32-bit maths in 16-bit code, you must add an extra 1 to the higher word if the carry flag is set.
Now there are two instructions, ADC and SBC, which take the carry flag into account. They will automatically add (or subtract, as in the case of SBC) that extra 1 to a word if the carry flag is set. If it is reset, then ADC and SBC work in exactly the same way as ADD and SUB.
This means that, if you want to add 32 to a 32-bit number in 16-bit mode:
;dx:ax is 32-bit number
add ax,32 ;low word of addend
adc dx,0 ;high word of addend
To increment, you add 1!
I hope this helps.
Also BTW this can also be done in 32-bit mode to work with 64-bit numbers.
This is very helpful AmkG :) Thank you.
best regards,
czDrillard
best regards,
czDrillard