Programming ASM in DEBUG 3

[Beatcow]

I recently got the urge to take on asm, but unfortunately got stuck in the first step(how sad). I used a tutorial that told me to use debug(i don't want to use TASM or MASM yet) but the code it gave me never works! I tried many different sites but only some parts of the code would work.


Please tell me what im doing wrong.

1. Go into MSDOS(i have win XP)
2.type debug
3. type n filename.com
4.type a
5.Type MOV AX,SEG MESSAGE on first line
6. Press enter, i get ^error

I don't even bother continuing the code since i cant even get past the first line.

What is wrong here? Other lines like MOV AX,02,etc.. work but certain ones don't. Is this normal?

Thanks in advance

 

[denc4]

Or the tutorial that you are using is (seriously) faulty, or
you are not reading it right. I would appreciate a link to
the tutorial so I can laugh at it, or in case it is ok, see
what you are doing wrong.

as for DEBUG, it does support some symbolic names, but not
"SEG" and "MESSAGE". DEBUG is too primitive for that. You
would have to use an assembler for that.

If you want to display a message on screen using only DEBUG,
try this at the hyphen (-) prompt of DEBUG:

-a
13A4:0100 mov ah,9
13A4:0102 mov dx,200
13A4:0105 int 21
13A4:0107
-a 200
13A4:0200 db 'This message is sent to the screen.',0d,0a,'$'
13A4:0226
-r
AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=13A4 ES=13A4 SS=13A4 CS=13A4 IP=0100 NV UP EI PL NZ NA PO NC
13A4:0100 B409 MOV AH,09
-t

AX=0900 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=13A4 ES=13A4 SS=13A4 CS=13A4 IP=0102 NV UP EI PL NZ NA PO NC
13A4:0102 BA0002 MOV DX,0200
-t

AX=0900 BX=0000 CX=0000 DX=0200 SP=FFEE BP=0000 SI=0000 DI=0000
DS=13A4 ES=13A4 SS=13A4 CS=13A4 IP=0105 NV UP EI PL NZ NA PO NC
13A4:0105 CD21 INT 21
-p
This message is sent to the screen.

AX=0924 BX=0000 CX=0000 DX=0200 SP=FFEE BP=0000 SI=0000 DI=0000
DS=13A4 ES=13A4 SS=13A4 CS=13A4 IP=0107 NV UP EI PL NZ NA PO NC
13A4:0107 0000 ADD [BX+SI],AL DS:0000=CD
-q

Hope this clears some stuff up..

 

[Beatcow]

The link is

http://www.geocities.com/SiliconValley/2072/asm.htm

(the examples that make errors appear a bit further down the page)

Hey thanks alot for the code you posted(it actually workded!). Now is there a way I could make this into a .com file and be able to run it through command prompt?
I tried saving it under a filename and then opening it, but nothing happened. What am I doing wrong this time?

 

[Beatcow]

Sorry for posting two replies in a row(is there an edit post button so I can edit what I wrote before?).

I also wanted to squeeze in a few questions about ASM. I've read many things saying that asm helps a programmer have a stronger base when he/she learns c++(which I do already). I believe that this would be true, but what assembly language is it? It seems as though there are millions of different types of assembly. What is the standard and universal one? Why can't I bring code from TASM to FASM or to MASM? It appears I need to tweak the code to make it compile? Is it because these assemblers have an assembly of their own? Thanks for the help.

 

[trollacious]

MASM, TASM, and the other popular assemblers allow you to use symbols, like line labels and data labels, where Debug is so primitive you have to calculate the actual numeric value of what you'd use as a line label or data label. Debug is real basic for assembly, where the others you mentioned will do some of the work for you, and some will allow macros and instructions almost like some of the higher level languages.

MS-DOS-based PC assembly language is the same no matter what assembler you use, though.

Lee

 

[denc4]

The tutorial is pretty neat, some good tips in there. But, in my opinion anyway, not suitable for a complete beginner.

I understand what might have gone wrong. First the author
explains some of debug, right after that he/she just jumps
to code which can only be read by an assembler without
informing the reader about this.

How to write yer program to disk using DEBUG is actually
explained in the tutorial you have read.

1. name the program.
2. store the length of the program in bx:cx.
3. write the program to disk.

So, considering a slight alternate version of my previous
example, one would write it to disk like this:

-a
13A4:0100 mov ah,9
13A4:0102 mov dx,109
13A4:0105 int 21
13A4:0107 int 20
13A4:0109 db 'Hello, World.',0d,0a,'$'
13A4:0119
-n HELLO.COM
-r cx
CX 0000
:19
-w
Writing 00019 bytes
-q

Microsoft has a great online manual for debug:

http://www.microsoft.com/technet/archive/msdos/comm2.mspx

If you're serious about learning assembly language, checkout
the Art of Assembly page and download Randall Hyde's book.
Although comprehensive, it is the best (free book) a
beginner can get.

http://webster.cs.ucr.edu/

 

[Beatcow]

Hey thanks trollacious and denc4 for making this a very informative post for me. I am surely going to look into the links and info that you have posted since you presented them in such an easy to understand method(i needed that ). Once again, I thank both of you for your effort and success at helping me! This might just be my beginning of Assembly.

D

(if its possible, i have some tiny little questions still...)
P.S=> Is it possible to code in pure machine code? If so where would you enter/code it?

 

[lionelhill]

You can, but there's really no point. Anything that can write bytes to memory (i.e. any language whatsoever) is suitable for writing pure machine code, because that is what pure machine code is: bytes in memory. If you call/jmp to the location where the bytes are, the processor will read them as code and have a go at executing them.

You can even use your assembler to do it; db, dw etc. allow you to set memory locations to any value you choose.

But assembly is just machine-code written in a human-readable form. Assembler gives you total control over what code is produced, at the byte-by-byte level, without having to remember that the prefix 066h is used to indicate a segment size change, (it probably isn't, I can't remember the actual codes) or that inc ax is actually.... what I can't remember.

Good luck!

 

[Beatcow]

So if it is possible, where do I go to program right into it? Like just tap 0's and 1's.

 

[trollacious]

You need to learn all the number equivalents for all the instructions first. You're getting in WAY over your head, though.

For example, to perform a jump, you first have to know the memory offset of the jump, then add or subtract that to or from the number of bytes you want to jump forward or backwards. Loading data from memory addresses into the registers is similar, and you have to know EXACT memory addresses, not relative ones. If you work with DEBUG some, you'll see the numbers that correspond to the opcode instructions when you disassemble a program.

While it may sound like an interesting learning project, it's really pointless and not worth as much as learning assembly language (rather than machine language/code) where you can spend your time writing good, fast code that works rather than memorizing (and forgetting) numeric equivalents of things.

Lee

 

[Beatcow]

I know it's over my head but I'm still curious since I can't find it anywhere on the net(instructions to where to put the 1's and 0's in). Where is it? Debug?

 

[trollacious]

Do a search on Google for "DOS Debug", in quotes like I have it here. You'll get a number of links on using Debug and what you can do with it.

The Debug command e allows you to input the hexadecimal numbers representing the assembly language instructions.

Another way to learn this is to assemble a few simple Debug scripts, then in a hex editor look at the assembled file to see what the actual numbers are that correspond to the instructions.

I used to use Debug a lot, back in the early 90s. Almost all the material I had on it is long gone, though.

Lee

 

[Beatcow]

Hey thanks a lot man. You have really helped me out!

D

 

[lionelhill]

Seriously, don't go that way! It's a total brain-turn-off to learn binary codes for instructions, and the code you'll write, assuming you get it right, will be utterly identical to what you'd get by typing assembler instructions instead. Noone, not the processor, not the deepest and most knowledgable IT expert, will ever be able to tell you did it in binary/hex/asm!

The only times when I've ever needed to know the real numerical value for an instruction are when I've written self-modifying code. For instance, you might have a Bressenham line draw that needs to go up (inc) or down (dec) and that's the only difference, so you write the inc/dec before you start the loop and save having two separate loops.

Otherwise if you're writing a compiler you'll need to know (obviously). But if you're writing a compiler, that's the least of your problems!

The tasm handbook, and numerous tutorial books on masm and tasm, include a table of op-codes at the end, with all the details of prefix bytes etc.
If you want one, make sure you get one with cycle-counts (they're only a start, but it helps to know roughly how difficult an instruction is for the processor), and make sure it includes prefix bytes for 32/16 bit operation etc. etc.

 

[trollacious]

I remember having a wild hair about this kind of thing around 1992. I'd say it gave me a view of programming that I wouldn't have had before. It certainly didn't produce anything serious, but was an interesting intellectual challenge at the time. And the idea of taking apart a file by each instruction helped me parse certain kinds of computerized embroidery files so I could figure out how to create an add-on program that could do things the commercial one we used couldn't do.

Lee