News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

help for a newbee

Started by mdj21, September 10, 2005, 07:27:06 PM

Previous topic - Next topic

mdj21

Hi,

i haven't done any Assembly language programing in a few years so i consider myself a newbee.

can somebody take a quick look at this portion of a list file and tell me what MASM 6 is complaining about?

(clip from list file):

06C5  E8 02B2                 CALL    SET             ;   and col. 16
06C8  8B 1E 0450 R              MOV     BX,POS          ; Convert present position into
06CC  D1 E3                 SHL     BX,1            ;   table offset value  (word size table)
                    MOV     SI,OFFSET TAB1[BX] ;-
ext1.asm(316) : error A2098: invalid operand for OFFSET
06CE  C6 06 043C R 1E              MOV     SLEN,30         ; Redisplay menu option at present
06D3  A0 0437 R              MOV     AL,BG           ;   position now with back ground
06D6  A2 043B R              MOV     ATTRIB,AL       ;   color attribute
06D9 

everything else assembles fine except for this line. the program originaly compiled fine like this using MASM 5.1.

Tab1 is a table of addresses for some character strings.

i originally wrote this program to run under DOS in a 16 bit environment. Now, i would like it to run in a DOS window under Windows NT.

if anybody sees an obvious mistake, please let me know.

thanks in advance for any help.

Mike.

joe

Hi mdj21!
I'm not sure, but You combined OFFSET with register. Second problem is in size, BX & SI are 16-bit registers. Try use this:
mov ebx,pos
shl ebx,1
mov     ecx, offset tab1
add ecx,ebx

I'm sorry, if I mistake.

tenkey

Probably a change in operator precedence.

Try

MOV     SI,(OFFSET TAB1)[BX]

In this case, though, you don't need OFFSET.

MOV SI,TAB1[BX]

will probably create the correct code.

Also check into MASM 5.1 compatibility mode. I believe /Zm works on the command lline, and OPTION M51 in the source file. Check the MASM doc at Randy Hyde's web site.

You're still writing a DOS program, as opposed to a Windows (console) program. Is that what you want?
A programming language is low level when its programs require attention to the irrelevant.
Alan Perlis, Epigram #8

mdj21

this little piece of a program is part of some code i wrote about 5 years ago that is used to send simple signals through a port. i have a card in the back of my computer which has 48 input/output wires on it which is controoled by the value in the port. value of the lport decides which wires are off or on for output. reading the port tells you which wires have a signal on them or not. the whole idea is to get my computer to controol my house. i've always been facinated by that stuff. trying to get back into it before i forget every thing i have learned.

actually, the original program was written in about 1992 and its function was to be a menu driven CNC punch press program language compiler. you would select the action you wanted for the CNC pucnh press from the menues and the program would write the apropriate machine code to a file. it worked very well and was a whole lot easier than looking up machine codes in a book and typing them in yourself. well later i got my hands on this I/O card and i re-wrote the program to controol it.

as far as windows vs DOS, i would love to do windows instead. problem is i couold never figure out how to read and write a port in the upper level languages. i remember from GWBASIC that there is peek and poke, but when i tried to use visual basic i could not get these to work. never could figure out how to do it in C either.

that is why i always stuck with DOS and Assembly language. besides, i like Assembly language. it's kind of cool. like a secret code.

is it possible to write windows programs using Assembly language? my bible has always been "Using Assembly Language", 3rd edition, by Allen L Wyatt. are there any good books out there on this subject?

i also seem to be having trouble getting 16bit programs to run on my XP machine. i get this "16 bit MS-DOS Subsystem" window that pops up and says for instance.....

Command Prompt - link
C:\WINDOWS\SYSTEM32\AUTOEXEC.NT. The system file is not suitable for running MS-DOS and Microsoft Windows
applications. Chose 'Close' to terminate the aplication.

anybody know why i'm getting this problem?

MichaelW

For the autoexec.nt problem see:

http://www.masmforum.com/simple/index.php?topic=1500.0

A DOS program running under Windows 2000/XP can access most or all of the I/O ports. I know that the I/O ports that are used to program the VGA work as they should, but I haven't done much testing of the other ports.

eschew obfuscation

mdj21


WOw! thank you very much, MichaelW. it turns out that i had no Autoexec.nt at all. so i created it with wordpad and now even my old program runs without being recompiled with ML.

just for fun though, i think i'll try some of the code changes that others above have mentioned and see if i get the same results as my original code. I'm a self taught assembly language programer so i'm sure some of the things i do are not the best way of doing them.

the port my I/O card uses is 300h.

now my only problem is going to be finding a computer that still has at least one ISA slot in the bus. (or EISA)

thanks to all for all the help.

MichaelW

You should also consider using Windows 98. Compared to the later versions Windows 98 has lower system requirements, and AFAIK, at least for a non-EISA system, under Windows 98 you should be able to access port 300h from a Windows program.

eschew obfuscation

mdj21

you can't access port 300h from a windows program running under NT?

why?

MichaelW

A ring 3 app cannot access any I/O port without triggering a protection fault. I think this was a design decision, but I have no idea why the decision was made.

eschew obfuscation

Tedd

If you had free access to ports then you could reprogram any device you liked and therefore bypass any kind of security that may be set up.

Just think about access rights to the (local) file system - you could just access the files directly without caring whether you have access rights. Or play with the system clock, or mess up the screen, sound, etc. Basically do almost anything.
No snowflake in an avalanche feels responsible.

MichaelW

Yes, it stands to reason that Windows must protect the system I/O ports, and AFAIK Windows 9x did so. I failed to make clear that by 'design decision' I meant the decision to protect all I/O ports, including ports that the system does not use.

eschew obfuscation