indirect addressing when not using extended registered in DosBox

[Steven]

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.

[dedndave]

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

[FORTRANS]

Hello,

   For #1

Code Select Expand


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.

[dedndave]

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

[jj2007]

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.

[hutch--]

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.

[dedndave]

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

[hutch--]

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.

[GregL]

I would think, if you want a program to run in DosBox, you would write 16-bit DOS code.

[dedndave]

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

[MichaelW]

Apparently DOSBox handles 16-bit RM DOS apps, and since at least version 0.61 also DOS extenders.

[japheth]

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.

... 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.

[jj2007]

> 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...!

Code Select Expand

MASM : warning A4018: invalid command-line option : /omf

[GregL]

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

I agree with that 100%.

[Rockphorr]

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