The Physics computers should have both the old and new versions of the Microsoft Macro Assembler, MASM 4.00 and MASM 6.11. (Other versions were buggy and short-lived.) While MASM 4 and its associated programs DEBUG, LINK etc. are far easier to learn and work with, they are no longer available from commercial suppliers. MASM 6 and Borland's TASM 3 are very similar to each other, but both are more difficult to learn. MASM 4 worked directly under MSDOS, while MASM 6/TASM create their own "integrated development environment" (IDE), which consists of text windows (rather than the graphics windows of Windows 3.1 or Windows 95). Note that, although the latter two use windows, they are not really Windows programs; i. e., they run under DOS. Thus, managing the IDE windows generated by MASM 6 or TASM must be learned. To keep things simple, we will discuss the Microsoft version, whose main component programs are called PWB (Programmer's WorkBench), MASM, ML, LINK and NMAKE. TASM is very similar, and if anything, more user-friendly and easier to learn.
Concerning windows management under the IDE, note in particular:
the close button is on the top left like a Macintosh, not the top right as in Windows,
the minimize button is a down-arrow in the top right corner. Since there is no taskbar, the minimization iconizes the window and places the icon under all other windows.
the maximize button is the up-arrow, top right.
the resize control is the bottom right, as expected
note the Windows menu item. Cascading or tiling the windows makes it easier to move from one to the other. This is especially important in a heavy debugging session when you may have many windows open simultaneously.
Type in your program using any editor that can produce clean ASCII text, with no embedded control codes other than the usual <CR>, <LF>, <HT> (tab), etc. I like to use the old Turbo C editor.
To assemble and link a program under MASM 4, at the DOS prompt, you would enter the following commands [" fname" is the root filename of fname.asm; any other extension is illegal]
masm fname,,; [produces .obj, .lst (listing) files]
link fname,,; [produces .exe program file, runnable with command "fname"]
debug fname.exe [to run the program under DEBUG]
Exit Windows (the MSDOS PROMPT is usually OK) and enter the directory MASM611 (cd \masm611).
Run an autoexec.bat file which
will include paths to the directories under MASM611. Also
include the command
set help=C:\MASM611\HELP.
cd \MASM611\bin (move to the folder containing pwb.exe, ml.exe, etc.)
Enter pwb <CR> (runs Programmers WorkBench, generating the Integrated Development Environment, IDE)
File:Open fname.asm
Project:Compile fname.asm (runs ml.exe, the assembler)
Project:Build fname.asm (runs the linker, generating the .exe file, but no listing)
Run:Execute fname.asm or if there is a problem
Run:Debug fname.asm
HINT#1: some versions of MASM 6 will install themselves with two binary directories under the folder MASM, namely BIN and BINR. They will not create a separate file for your programs, and they will frequently lose their PATH environment variables and fail to find some of their working components such as LINK or NMAKE. I recommend you move the contents of BINR into BIN, remove the now-empty BINR folder, and create a folder where you will keep all your work (I call mine FILES). The FILES folder (or whatever you call it) should be kept backed up on floppy disk. Then if you have to re-install MASM, you can easily restore your original situation. Note also that by keeping your work separate from the other directories, it is easy to see if you have successfully created a .exe program with your last assemble. When your programs are mixed in with MASM's .exe files, they can be hard to find. Don't forget to change your PATH environment variable to reflect these changes.
HINT#2: When you first run PWB, make a new file and immediately save it in your files directory under MASM\FILES\asst1.asm. If you do this consistently, PWB will save its status files (CURRENT.STS and PWBnnnn, where nnnn is a string of 4 or 5 digits) in a consistent location. The loss or perversion of these ancillary files is one of the main reasons PWB fails to work properly.
Use the template below as a first step.
The following tiny program can be used as a template if the code between .STARTUP and .EXIT is replaced by your program. The upper case words are assembler directives, instructions to the assembler to tell it how to form the final product. They will be discussed below. For now, start PWB, use the menu item FILE:NEW and type in the following program:
.MODEL small
DOSSEG
.STACK 1000h
.DATA
msg db
0DH,0AH,'Hello World!',0dh,0ah,'$'
.CODE
main proc
.STARTUP
dspmsg: ;display message with the
following instructions ...
mov ah,9
;prepare for function 9 of interrupt 21
lea dx,msg
;point to the message at msg in the data segment
int 21h
;do it
.EXIT
main endp
END
The upper case words are directives to the assembler. They are sometimes called pseudo-operations or pseudo-ops in some books. Note that DOSSEG and END do not have a preceding dot (I don't know why). This style of using capital letters for assembler directives has become conventional. It serves to make the directives stand out from the rest of the program. MASM converts all lowercase to uppercase, so capitalization is only cosmetic. Note also that the two ways of specifying carriage return/line feed pairs under the .DATA heading are equivalent. [Also legal are 0Dh and 0dH (for carriage return characters).] Your text should have a thorough discussion of assembler directives, but the ones used here should suffice for most situations.
Now the lines "main proc" and "main endp" delineate a procedure's beginning and end. They are pseudo-ops, but are not capitalised. I don't know why, but it seems to be the convention. I suggest you follow it. This program has only one procedure, and its name is "main". Unlike C, however, "main" is not a reserved word, and it could have been called something else (e.g. hello proc and hello endp).
Whenever the assembler is parsing (interpreting the code) and it hits a semi-colon (;) it stops and moves to the next line. A comment is there for the reader, and it in no way slows the assembler, because it is ignored after the parsing of the single character ";". It is therefore wise to use comments freely, BUT commenting upon the obvious detracts from the professional mien of a program. In this example, there are really more comments than necessary, but I consider them acceptable in this situation, where pedagogy is the point.
Note that the semicolon applies for only one line. If a comment extends beyond one line, a semicolon must be inserted as the first character of the next line. If it is desired to write a short paragraph of comments, as in explaining how to use a program to the reader of the source code, there is an assembler directive which blocks out a section as a comment so that no semicolons are required. If the assembler sees the word "comment" at the beginning of a line, it will note the next (non-white-space) character, and ignore everything until it hits that character a second time. Thus
comment /
This is a comment that could be many lines long .../
uses the slash as the delineating character.
Under MSDOS, DEBUG.COM or DEBUG.EXE was found in either the root directory or the same directory as MASM.EXE. Under Windows 95, it is found in the Windows\Command folder, along with deltree, diskcopy, edit and other important MSDOS utilities. Different versions have slight variations in the command syntax. After typing debug, type a question mark ("?") to obtain a list of commands.
The modern equivalent of DEBUG is called CODEVIEW, which runs under the Integrated Development Environment (IDE). As explained earlier, one enters the IDE by initially running PWB in the MSDOS environment. CODEVIEW is "forked" (loaded and run as a shell under the IDE) when you run your program either (a) under the menu item RUN:DEBUG or (b) if you click on the <Debug Program> option after "building" the program (PROGRAM:BUILD ALL). If you are using Windows '95, you can create a "shortcut" (an alias icon) which will automatically exit Windows and start PWB.EXE from within DOS 7.0 (use the right mouse button after selecting pwb.exe from within Windows).
When the linker creates the final product (the .exe file), it has two options:
create a "release" version which is a binary program that will run on its own in an MSDOS environment, or
create a "debug" version which has extra hooks to enable CODEVIEW to display all segments associated with the program, including values of variables, the data area, addresses of variables, etc.
These choices can be set under the menu item OPTIONS:LINK OPTIONS to either debug or release by clicking the radio buttons at mid-screen. Choose the debug option if you wish to step slowly through your program, examining registers and memory contents after each instruction.
Note the difference between the two function keys at the bottom of your screen in CODEVIEW. Step will take you through a procedure call or interrupt as a single instruction, without your having to trace your way through the long and detailed BIOS or DOS interrupts instructions. Use trace to follow the main program through your procedure calls, but once the procedures are debugged, then use the step to "step" (skip) over them next time.
Use the Windows menu item to decide which windows you need to display. Size them (lower right corner) to make best use of your screen. The registers, for example might best be a tall narrow window off to the right, while the source code and memory windows need to be wide and can be only a few lines long. Note the output window which takes over the screen, but returns you to the debugger when you touch a key. The other buttons at the bottom are either self-explanatory, or easily understood by clicking on them (or using the key combinations).