Author Topic: got to enter the path for nasm.exe everytime  (Read 10289 times)

nobody

  • Guest
got to enter the path for nasm.exe everytime
« on: May 26, 2008, 01:04:32 AM »
Hey guys,
got a newbie question. Each time I close and restart nasm-ide, I have to re-enter the path for nasm.exe. Is there a way to make it memorize the location?

Thx.

nobody

  • Guest
Re: got to enter the path for nasm.exe everytime
« Reply #1 on: May 26, 2008, 05:02:50 AM »
OMG, someone is still running nasmide???

After you've entered the full path to nasm once, nasmide should remember it - stored in nasmide.ini as "NASM_LOCATION" under "[ASSEMBLER]". What do you see if you look in that file (if any)?

Hmmmm... did you copy this file from the "Step by Step" CD, by any chance? Seems to me there was an issue with files copying with the readonly attribute set. Should be able to fix it with "attrib -r nasmide.ini", if that's the problem...

Best,
Frank

nobody

  • Guest
Re: got to enter the path for nasm.exe everytime
« Reply #2 on: May 27, 2008, 04:04:27 AM »
Hi Frank, yeah, I am reading an ebook version of Jeff Duntemann's Step by Step 2nd edition. It's the only beginning assembly language tutorial that's making some sense to me.

I have no problem with the readonly files, and thanks for the tip, I changed to location in the .ini file and got it to work.

However, some of the exercise files give me the error "C:/asm/nasmide.exe The NTVDM CPU has encountered an illegal instruction. CS:11 d9 IP:0179 OP:63 61 6c 6c 20 Choose "Close" to terminate the application". I can assemble all files with no errors, but as I said, when I run some files, I got that error (different numbers for different files).

What's the cause of the problem? I'm running Vista, nasm 2.02, nasmide 1.8.

nobody

  • Guest
Re: got to enter the path for nasm.exe everytime
« Reply #3 on: May 27, 2008, 07:51:36 AM »
Well... there *are* instructions which are perfectly okay with the CPU, but which are "illegal" in "protected mode" OSen - Windows or Linux (it's "protected" from *us*!). Reading/writing ports, for example, or accessing memory you don't "own". But I don't think that's the problem in this case...

The "instructions" shown, when viewed as ascii, say "call "! Seems like you're trying to "execute data" for some reason. Failing to "exit" cleanly would do it, if the word "call " appears in the data. Possibly "line wrap", although I don't think Nasm will assemble it ("invalid combination of opcodes and operands"... there would be no "operands")... ("fire.asm" has the word "call" at the end of a comment line, where it might wrap - but when I deliberately "wrap" it, Nasm barfs).

I suppose you might get this result by renaming "myfile.asm" to "myfile.com" and attempting to execute it. In any case, I think it's a "simple error" rather than a real "illegal instruction". More than one file does this, eh? Which one(s)?

I haven't read Jeff's book, but I've looked at the example code downloadable from duntemann.com - there were a couple of bugs in the version I've got... errors "translating" from the Masm syntax of the first edition, I think. Probably fixed by now. If you... well, here:

-------------------
diff -u orig/eat3.asm ./eat3.asm
--- orig/eat3.asm   Sun Dec 12 14:18:02 1999
+++ ./eat3.asm   Mon Jan 28 19:41:28 2002
@@ -110,7 +110,7 @@

ClrScr:
     mov CX,0          ; Upper left corner of full screen
-    mov DX,LRXY       ; Load lower-right XY coordinates into DX
+    mov DX,[LRXY]       ; Load lower-right XY coordinates into DX
 ClrWin:
     mov AL,0          ; 0 specifies clear entire region
 ScrlWin:
diff -u orig/eat5.asm ./eat5.asm
--- orig/eat5.asm   Sun Dec 12 14:25:04 1999
+++ ./eat5.asm   Mon Jan 28 21:09:18 2002
@@ -15,7 +15,7 @@

[SECTION .text]             ; Section containing code

-%include "BOOK\MYLIB.MAC"        ; Load in screen control macro library
+%include "MYLIB.MAC"        ; Load in screen control macro library

START:                      ; This is where program execution begins:

diff -u orig/info.asm ./info.asm
--- orig/info.asm   Sun Dec 12 14:29:22 1999
+++ ./info.asm   Mon Jan 28 20:44:00 2002
@@ -21,7 +21,7 @@
 START:                      ; This is where program execution begins:
            call VidCheck    ; Initialize all video information variables

-           Clear VidSegment,ClearAtom,VidBufSize  ; Clear the screen
+           Clear VidOrigin,ClearAtom,VidBufSize  ; Clear the screen

; Here we display the name of the program and its author:
            Writeln IDString,LIDString      ; Display the program name
@@ -274,8 +274,8 @@
 ; system and are initialized by the VidCheck procedure:
 ;---------------------------------------------------------------
 DispType   DB      0       ; Code for display adapter type
-VidSegment DW      0B000H  ; Segment of installed display buffer
 VidOrigin  DW      0       ; Offset for FAR pointer to refresh buffer
+VidSegment DW      0B000H  ; Segment of installed display buffer
 VisibleX   DB      80      ; Number of columns on screen
 VisibleY   DB      25      ; Number of lines on screen
 VidBufSize DW      4000    ; Default to 25 X 80 X 2 (char & attribute)
diff -u orig/mylib.mac ./mylib.mac
--- orig/mylib.mac   Mon Sep 20 12:04:08 1999
+++ ./mylib.mac   Mon Jan 28 20:58:40 2002
@@ -32,8 +32,8 @@
 ;---------------------------------------------------------------
 %macro  Clear 3  ;VidAddress,ClearAtom,BufLength
         les DI,[%1]      ; Load ES and DI from FAR pointer
-        mov AX,%2        ; Load AX with word to blast into memory
-        mov CX,%3        ; Load CX with length of buffer in bytes
+        mov AX,[%2]        ; Load AX with word to blast into memory
+        mov CX,[%3]      ; Load CX with length of buffer in bytes
         shr CX,1         ; Divide size of buffer by 2 for word count
         cld              ; Set direction flag so we blast up-memory
         rep stosw        ; Blast away!
---------------------

As you can see(?), the main problem is "[]" where Masm doesn't need 'em, but Nasm does. I don't know what the story is with "info.asm" - the version I've got is "just plain wrong"! (offset before segment in memory - we're "little endian" in that respect, too!) But worry about that when you get to it... (IIRC, "eat3" works with the error in, but *looks* a lot nicer with it fixed)

But that's got nothing to do with the "illegal instruction"... if you can't get that fixed, holler!

Best,
Frank