Re: need to be able to know basic MASM ONLY

giddy wrote:
hi,

Thanks Dirk, I haven't looked at your program very intently but
confusing, especially because I find it being a little different from
other asm programs I've seen. I don't know almost anything when it
comes to assembly language. I just know some "concepts"

Hi Gideon,

The "concepts" are the "important" part, but often it's the nitty-gritty details that are the "hard" part - as in "frustrating". I guess you're discovering this... :)

I am very happy your code compiled and ran though! loL

Good start! This is a bigger deal than it sounds like!

The reason Dirk's code looks "different" may be that it's for dos. You say you don't want to program for Windows, but you want to use Masm. That pretty much leaves dos... and bootsectors. (a bootsector is where the computer starts, but probably isn't where a beginner wants to start - you need to know a bit, and they're hard to debug) Dos is "obsolete" - not much "commercial potential" these days - but it's "easy"... in some ways... in other ways it's "harder" (segmented memory, and limited addressing modes - concepts you can forget about - with great joy - when you get into 32-bit code).

The thing is, you pretty much have to program "for" something. We can "add eax, ebx"... but to see the result, we pretty much need to call an OS function. We're going to need to "exit back to OS", at the very least. This is about *all* Dirk's "skeleton" does, but it can easily be enhanced...

;------------------------------------------
...MODEL SMALL
...386P
...387
Contant = 123

CODE SEGMENT use16 'CODE'
assume cs:CODE,ds:DATEN,ss:STAPEL
org 100h
START: mov ax, DATEN
mov ds, ax

; print a "X"
mov ah, 2 ; subfunction to print the char in dl
mov dl, 'X' ; put a character there :)
int 21h ; call OS to "do it"

mov al, 0 ; ERRORLEVEL
mov ah, 4Ch ; exit to DOS
int 21h
CODE ends

DATEN SEGMENT use32 'DATA'
VALUE DD ?
DATEN ends

STAPEL SEGMENT use16 STACK 'STACK'
DB 10h dup (0)
STAPEL ends
end
;------------------------------------------

There, now you've got a program that *does* something! :)

An "advantage" of dos is that we have more direct access to the hardware. Instead of the above, we could have:

mov ax, 0B800h
mov ds, ax
mov byte ptr [0], 'X'
mov byte ptr [1], 5 ; nice cyan color, IIRC

(that's going to scroll off the screen when we "return to dos", I guess - put 'em at [160] and [161])

This "direct access to hardware" is somewhat limited in a "dos box", but in "real dos" the whole machine is yours! But it's 16-bit code, and the CPU is operating "with one hand tied behind its back"...

If you're content with dos, and want to use Masm, Randy Hyde's old, obsolete, 16-bit AoA may interest you:

http://webster.cs.ucr.edu/AoA/DOS/index.html

Which brings me to Dr. Paul Carters tutorial,

Which starts right off with 32-bit code. I suppose on a 64-bit machine, that's "obsolete" too... but 64-bit code looks "hard" to me...

Dr. Carter gets around the "which OS?" question by calling the C library. Not really "the"... the Linux C library has routines for interfacing with the Linux OS, a Windows C library has routines to interface with the Windows API, etc. We can "just call printf" and let the library handle the ugly details. The actual call to printf is further wrapped in a macro, so we don't even have to know how to do that! It's "easy", and all the source code is there, if we care to look... if we "just wanna know", or want to go beyond the few routines that Dr. Carter provides, or... if we need to know to diagnose why it's *not* workin' for ya...

I downloaded the whole
things

Okay... besides the "book", which is generic (that's the point), you need examples for your OS and compiler... You'd want the "Microsoft" package, presumably. The "wrong one" would be a problem...

many months ago with great enthusiasm but had a real headache
trying to compile his first program, after that I abandoned it all.

Should've asked... I'll bet we can figure it out!

I
come from a very pampered Visual Studio/C#/Intellisense world

A google for "nasm visual studio" turns up some instructions for using VS with Nasm (hmmm, Python is written in Nasm? Who knew?). Looks "complicated" to me, but perhaps if you're familiar with VS it isn't so bad.

One thing they mention is the "-Xvc" switch to Nasm (more recent than Dr. Carter's tut, I think?). This causes a minor change in the punctuation of error messages - apparently a "big deal" to VS(?). If you can get this set up, it should work fine for the examples. I personally prefer to run these tools from a command prompt, but some people like an IDE, and if you want it you should have it!

so i
might give it a shot if you could please, Phoenix, tell me *exactly*
how I could compile his code.

First, before first.asm, you'll need asm_io.obj. If this doesn't come pre-assembled in the examples...

nasm -f win32 -d COFF_TYPE asm_io.asm

That's what it says in the comment - you might want to add "-Xvc"... and perhaps "-Ox"... but those shouldn't matter at this point.

Then assemble first.asm into first.obj...

nasm -f win32 -d COFF_TYPE first.asm

Nasm is going to need to find asm_io.inc. If it isn't in the same directory as first.asm, you can tell Nasm where to look for include files by adding "-I D:\path\to\my\includes\" to Nasm's command line - note that the final '\' is required.

Then I've got a problem, I don't know what your compiler calls itself - "vcc" I suppose. The book suggests that you compile driver.c to driver.obj separately "vcc -c driver.c", but the comments in the files suggest using driver.c on the command line - "vcc first.obj driver.c asm_io.obj" or so - either should work. This assumes that vcc(?) uses the first filename as the executable name (gcc needs to be told "-o first.exe", and you *may* need to do something like that for vcc).

That "should" do it. If it doesn't, let us know just where and how it fails. If you can get it set up in VS, it may be as simple as clicking "build", or however you do it...

Will this RadAsm IDE do it for me!?(yes i'm on windows)

I'm not familiar with RadAsm (either), but it should. I'm not sure how RadAsm does with calling a C compiler. You're probably better off with VS, if that's what you're used to.

Even the odd C
program he has for output or something, will it compile smoothly with
no hitches, i wouldn't mind anything as long as you give detailed
instructions.

If the above hints don't help... maybe we can find more details to fill in. :)

Best,
Frank

.

Relevant Pages

  • Re: Nasm Detecting The Type Of OS
    ... What's the suggested way to detect the OS and get NASM to compile ... Since the OS information is passed to NASM from the command line, ... solution is to use some other compilers' portable method for creating host ... DOS, if DJGPP was installed, could use ...
    (comp.lang.asm.x86)
  • Re: changing meaning of opcodes in nasm
    ... 15 mov ax, welcome ... I compile it using this command: nasm esc.asm -f bin -o esc, ... it appears that this code may be wrong interpret to machine language. ... if you're getting Nasm from SourceFrog. ...
    (alt.lang.asm)
  • Re: which way is faster?
    ... So what you ask me here would be a tiny OS on top of DOS. ... alternatives to unless using hardware acceleration. ... PUSH ebx ... MOV edx,01000;scan line size ...
    (alt.lang.asm)
  • Re: Input/Output
    ... You can *use* 32-bit stuff even in dos. ... Register A86, if you like it, and get A386... ... Santosh suggested int 21h/0Ah. ... mov ah, 3Fh ...
    (alt.lang.asm)
  • Re: which way is faster?
    ... So what you ask me here would be a tiny OS on top of DOS. ... PUSH ebx ... MOV edx,01000;scan line size ... EMM and XMS wont do well here, because IRQs become disabled for too ...
    (alt.lang.asm)