Hello everybody,

I'm using

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