Hello,
I am trying to use indirect addressing to access elements in array. The program is to run in a DOSBox environment .... so extended registers are not available, such as esi
I get error which indicates the size of the operands are not equal when I do this
Mov si, offset name_of_array
It works fine if I code this
mov esi, offset name_of_array
but then when I try to store this value in esi into a variable so I can later use it
address_of_start_of_array dw ?
:
:
Mov address_of_start_of_array, esi I get same error ... the size of esi is different than the variable address_of_start_of_array
I think this is because there are 32 bits in the address and si is a 16 bit register and dw variables are 16 bits
I have see two possibilities:
1. change the directives to MASM to make it think it is assembling for a 16bit address space ... does anyone know how to do this? If this could be done, would that stop the debugging functions, such as those in
.include \masm32\include\debug.inc which I must have, at least until I get it to work the first time.
2. define a variable that is 32 bits in length .. so that the mov variable,esi would work .... does anyone know how to do this ? If I do this, then, after I get the code developled in MASM, I would move to a crappy assembler in DOSBox and take out the esi and put in si and recompile.
Any help would be appreciated.
well - you need to choose whether it is going to be a 16-bit program or a 32-bit program
i think 32-bit code can run in a DosBox - not sure - i know 16-bit code can
if you are writing a 32-bit program:
address_of_start_of_array dd ? ;<--- must be defined as a dword, not a word (dw = define word)
mov address_of_start_of_array,esi
all addresses are 32-bit in a 32-bit program
in a 16-bit program, there is a 16-bit segment and a 16-bit offset
Hello,
For #1
CODE SEGMENT USE16
For #2, use Dave's definition for a DWORD or store SI in
your word variable.
Show us the command you use to assemble your code.
You may be assembling in 32-bit mode.
Regards,
Steve N.
in the attached zip file, i have included simple 16 and 32 bit programs
also included are the batch files used to assemble them
it is assumed that you have installed the Masm32 package and have Link16.exe in the masm32\bin folder
Quote from: dedndave on October 30, 2009, 09:53:35 PM
in the attached zip file, i have included simple 16 and 32 bit programs
also included are the batch files used to assemble them
it is assumed that you have installed the Masm32 package and have Link16.exe in the masm32\bin folder
Hi Dave,
I added your 16-bit example to the MasmBasic package :U
Note that @DATA aka DGROUP is not known to masm 9.0, but ml 6.14, 6.15 and JWasm recognise it.
Steven,
I would be interested to know what you mean by a DOSbox environment.
1. CMD.EXE console in any of the WinNT based OS versions.
2. COMMAND.COM run in a VM in 32 bit Windows.
3. COMMAND.COM run in native 16 bit mode in DOS.
4. 32 bit DOS extender.
It effects,
(a) What is possible to do.
(b) Where I point this topic so you get the best support for your question.
hi Jochen and Hutch
very cool Jochen - i guess they have to grab it by segment name - i am not sure
Hutch - DosBox is an environment to run under windows that allows you to run older programs (like old games)
i don't think they have a 64-bit version of it - lol - maybe somebody with a lot of ambition will write one
http://www.dosbox.com
Thanks Dave, I am not up on the aftermarket for DOS based stuff.
It does not answer the question though, is this 16 bit code or 32 bit code. If it is the former I will move it to the 16 bit forum.
I would think, if you want a program to run in DosBox, you would write 16-bit DOS code.
that is probably correct
however, it is another case where the person does not understand the differences between 16 and 32 bit
sometimes, they don't know what they want to learn without a little more information
if he wants to write for DosBox, 16-bit code may be the right thing
but, i think the time might be better spent learning 32-bit
there is no harm in learning both worlds, really - it just takes more time
Apparently DOSBox handles 16-bit RM DOS apps, and since at least version 0.61 also DOS extenders.
Quote from: Steven on October 30, 2009, 09:07:39 PM
Hello,
I am trying to use indirect addressing to access elements in array. The program is to run in a DOSBox environment .... so extended registers are not available, such as esi
This is not correct. DOSBox emulates at least an 80486, so register esi is available.
Quote
... I would move to a crappy assembler in DOSBox and take out the esi and put in si and recompile.
jwasmd.exe works in DOSBox. Just verified.
> Note that @DATA aka DGROUP is not known to masm 9.0, but ml 6.14, 6.15 and JWasm recognise it.
Masm v9 needs -omf switch to know DGROUP.
Quote from: japheth on October 31, 2009, 04:40:34 AM
> Note that @DATA aka DGROUP is not known to masm 9.0, but ml 6.14, 6.15 and JWasm recognise it.
Masm v9 needs -omf switch to know DGROUP.
Works fine with ml 6.15 and upwards, but 6.14 throws a warning and then stops assembly. Oh my f...!
MASM : warning A4018: invalid command-line option : /omf
Quote from: dedndavebut, i think the time might be better spent learning 32-bit
there is no harm in learning both worlds, really - it just takes more time
I agree with that 100%.
dos box is more simply to fell how instructions work.
but today all asm books does not provide enough info about comparing 16 & 32 bit mode
Quote from: Steven on October 30, 2009, 09:07:39 PM
Hello,
I am trying to use indirect addressing to access elements in array. The program is to run in a DOSBox environment .... so extended registers are not available, such as esi
I get error which indicates the size of the operands are not equal when I do this
Mov si, offset name_of_array
It works fine if I code this
mov esi, offset name_of_array
but then when I try to store this value in esi into a variable so I can later use it
address_of_start_of_array dw ?
:
:
Mov address_of_start_of_array, esi I get same error ... the size of esi is different than the variable address_of_start_of_array
I think this is because there are 32 bits in the address and si is a 16 bit register and dw variables are 16 bits
I have see two possibilities:
1. change the directives to MASM to make it think it is assembling for a 16bit address space ... does anyone know how to do this? If this could be done, would that stop the debugging functions, such as those in
.include \masm32\include\debug.inc which I must have, at least until I get it to work the first time.
2. define a variable that is 32 bits in length .. so that the mov variable,esi would work .... does anyone know how to do this ? If I do this, then, after I get the code developled in MASM, I would move to a crappy assembler in DOSBox and take out the esi and put in si and recompile.
Any help would be appreciated.
you must understand what is the size of operands.
sample for you
array db 16 dup (0)
array_ofs dw offset(array)
...
mov SI,array_ofs
mov AL,'A'
mov [SI],AL ; just after 1 element of array will letter A
....
lea SI,array
mov AL,'B'
mov [SI+1],AL ; just after 2 element of array will letter A
....
mov SI,array_ofs
add SI,2
mov array_ofs,SI
...
mov BX,array_ofs
mov AL,'C'
mov [BX],AL ; just after 3 element of array will letter C
:8)
Thank you all for you many thoughtful responses. I tried seveal ideas from them, including instructing MASM to use 16 bit mode using CODE SEGMENT USE16 which then prevented the debug features (PrintHex & PrintText) from working ... so I used the idea of setting the variable which hold the address as DD and was careful to use only esi as the register to hold the address of the arrays.
address_of_start_of_array DD ?
mov esi, offset data_array
mov [address_of_start_of_array],esi
When I move back to dosbox, after getting the program to work well, I will change the DD to DW and change esi to si and I expect to be OK
Thanks again, Steven