Dec 052017
A tutorial for PC assembler (TASM/MASM/A86.) (Part 2 of 4).
File ASMTUT2.ZIP from The Programmer’s Corner in
Category Assembly Language
A tutorial for PC assembler (TASM/MASM/A86.) (Part 2 of 4).
File Name File Size Zip Size Zip Type
BAS1.DOC 15760 4910 deflated
BAS2-1.DOC 32106 8802 deflated
BAS2-2.DOC 41897 10603 deflated
CHAP0-1.DOC 41545 10454 deflated
CHAP0-2.DOC 39806 10828 deflated
CHAP1.DOC 25019 6757 deflated
CHAP2.DOC 11469 3441 deflated
CHAP3.DOC 21648 6174 deflated
CHAP4.DOC 15984 4271 deflated
CHAP5.DOC 29029 7275 deflated
CHAP6.DOC 17314 4147 deflated
CHAP7.DOC 19196 4831 deflated
CHAP8.DOC 30879 8057 deflated
README2.DOC 1369 263 deflated
TPCREAD.ME 199 165 deflated

Download File ASMTUT2.ZIP Here

Contents of the BAS1.DOC file



So you like using BASIC. I can't blame you. BASIC has several
very nice features.

(1) Its graphics interface is easy to use and is very
powerful. If you want to draw lines, circles, patterns or
other graphics images, you can do it. Your only limitations
are the aspect ratio of the screen and the possible screen
colors. These limitations have to do with hardware, not with

(2) Its string handling capabilities are unparalleled. If
you want to have an array of strings like the following:

DIM STRING.ARRAY$ (50, 25) ' 1250 elements

and some of the elements are only a couple of characters
long but some of the strings are several hundred characters
long, BASIC is the ONLY language that can handle it
correctly. In fact, if you wanted one of the strings to be
1000 characters (it's allowed in the most recent BASIC),
then you would need 1.25 megabytes for this array in C or in
PASCAL. This would probably be too big for the computer.
BASIC, on the other hand, implements this without wasting
any space in memory.

BASIC has a few things that require a little more work than with
other languages. It has strings, integers, and floating point
numbers but it is missing characters and unsigned numbers - these
can be implemented by using integers (if you are careful). This
is not all that limiting.

If BASIC is so nice, why do I think that you should have some
experience with a structured language before doing assembler? It
all has to do with data INTEGRITY. The question is, are you sure
that you haven't inadvertantly screwed up your data? There are
two ways that this might happen. You need to know how BASIC works
to understand the problem.

A variable name in BASIC consists of a name followed by a type
identifier. The identifiers are '%', '!', '$', '#' (double
precision) and possibly '&' (long integer). The name:


is NOT a variable inside of BASIC while:



The PC Assembler Tutor - Copyright (C) 1990 Chuck Nelson

The PC Assembler Tutor mmii

are all valid variables. In fact, all three can be in the same
program, as we shall see shortly. I just said that that first
example is not a valid variable inside of BASIC, but that is
exactly what you have been writing since the first time that you
wrote a BASIC program. What's going on here? Well, when the BASIC
interpreter or compiler reads the text file, it reads the name
and the identifier. If the type identifier is missing, it tacks
the default identifier on to the end of the name.

What's the default type identifier? The answer is '!'. BASIC
maintains a default list. The legal first characters in a name
are A-Z. For each legal first letter, there is an entry in the
list which says what the default type for that letter is. When
you start the program, the type list looks like this:


When the interpreter sees a name without an identifier, it takes
the first character of the name and goes to the default-type
list, gets the appropraiate type identifier for that first
character, and adds the identifier on to the end of the name.
Externally (in your text file) there may be names without type
identifiers, but internally (inside the interpreter/compiler) ALL
variables have the type identifier after the name.

Though the list starts out with all '!'s, you can change this
list with a DEF statement. Here are some DEF statements and how
they change the list. I am assuming that we are always starting
at the beginning of the program (with all '!'s).

DEFINT A-Z ' This is probably your favorite



This last one is a recipe for disaster, but it's legal.

Have you understood everything so far? Then let's go on. This
ability to NOT use the type identifier leads to laziness. The
usual thing is to always identify strings with a '$' but to be
rather lax about the distinction between integers and floating
point numbers.

Now we get to the problem. Look at the following code:

BASIC I - Using Basic mmiii

20 FOR I = 1 to 5
30 LARGE.NUMBER! = 300.0 * I

If you can't see the error, I forgot to put the '!' after
LARGE.NUMBER in line 40. The problem here is that BASIC is not
going to complain. When it sees LARGE.NUMBER without a type
identifier, it will go to the default list (because of the DEFINT
statement, all defaults are integer) and put a % after it. BASIC
has created a SECOND variable with the same initial name, but a
different type. This is not because you wanted it to, but rather
because you forgot a '!'. Lets do a BASIC program. Here's some

******************* NINJA.BAS *******************

10 ' place for defint statement
20 '
30 ' enter all the data
40 NINJA% = 20
50 NINJA! = 4.7134E+13
60 NINJA$ = "Hey dude!"
70 '
80 NINJA$ (0) = "howdy! "
90 FOR I% = 1 TO 5
100 NINJA$ (I%) = NINJA$ ( I% - 1 ) + "doody! "
110 NINJA! (I%) = I% * 25.31
120 NINJA% (I%) = I% * 3
130 NEXT I%
140 '
150 ' print all the data
170 FOR I% = 1 TO 5
180 PRINT NINJA% (I%), NINJA! (I%), NINJA$ (I%)
190 NEXT I%
210 '
220 END


I actually want you to run this through your BASIC. I have
defined SIX different NINJAs. They are:

2) NINJA% ( )
4) NINJA! ( )
6) NINJA$ ( )

where the parentheses indicate an array. If I had gotten carried
away, I could have included 4 more NINJAs for double precision,

The PC Assembler Tutor mmiv

double precision array, long integer and long integer array.

Running this through my computer I get:

20 4.7134E+13 Hey dude!
3 25.31 howdy! doody!
6 50.62 howdy! doody! doody!
9 75.93 howdy! doody! doody! doody!
12 101.24 howdy! doody! doody! doody! doody!
15 126.55 howdy! doody! doody! doody! doody! doody!
4.7134E+13 75.93

Notice that I have 3 different array types and 3 different
variable types. As you can see from the bottom line (which prints
the defaults), the default here is '!'. If we now put DEFINT A-Z
on line 10:


everything will stay the same except the bottom line which now

20 9

which are the integers. Finally, if we have DEFSTR A-Z


we get:

Hey dude! howdy! doody! doody! doody!

as the bottom line of output. If you didn't know all of this
before, make sure you have assimilated this before going on.


Both PASCAL and C require you to account for every variable. You
need to specifically state what kind of variable it is and you
need to enter it in a list of variables used in that block of

int ch, variable1, variable2, variable3[60] ;
char long_array[4027] ;

A name can be used in only one way in any block of code. If you
try to use it differently, the compiler will generate an error.
Though people moan and groan about having to specifically list
all the variables used in a block of code, over time they get
used to it. It offers two advantages.

(1) No variable can be inadvertently used in an incorrect
way (used as a string when you wanted an integer, used as an
integer when you wanted a floating point number, etc.).

(2) There can be no variables which are misspelled, are left

BASIC I - Using Basic mmv

over from a previous version of the code or appear by
mistake, without both the compiler and you knowing about

Slightly modifying names is one of my major problems. I might use
'long_array' and 'longarray' in different places in the C code,
though I want the same thing. C will catch this, BASIC won't.
Every time BASIC encounters a slightly different name it simply
creates a new variable (and normally sets it to 0). In programs
larger than a few pages, this situation is almost impossible to
detect or control.


When talking about PASCAL and C I kept using the word BLOCK. Both
languages have a modular (or block) design. The philosophy behind
this is that when you write a program you want to divide a task
into a number of distinct subtasks, and you don't want these
subtasks to interfere with each other. You put each of these in a
subprogram. In BASIC you can put sections of a program in
subprograms too. This is good programming practice. There is a
difference, however. In C and PASCAL, a variable is valid ONLY in
the block in which it is declared (unless you take specific steps
to make it universally valid). If you try to use this variable in
a different block of code the compiler will generate an error -
it literally has no information about where this variable is. In
BASIC, all names are valid everywhere in a file. If on page 1 you

210 CURRENT.PRICE! = 427.11

you may want to use this as a constant number throughout the
program. But if in a subprogram on page 23 you have:

12060 CURRENT.PRICE! = 0

you have changed the value. You're saying to yourself "But why
would I change a variable like "CURRENT.PRICE!"? You probably
wouldn't. But you will have dozens and dozens of variables around
with names like I, J, K, COUNT, START, STARTING.NUMBER,
type). It is exactly these that will be corrupted in BASIC but
will be reliable in C or PASCAL.

1920 MINIMUM! = RATE! * 5.0
1930 MAXIMUM! = RATE! * 7.32
1940 COUNT% = (MAXIMUM! - MINIMUM!) / 3.0

In this section of code, did 'CALL CHECK.ANSWER' change any of
the four variables MINIMUM!, MAXIMUM!, RATE! or COUNT%? In BASIC,
we hope so, but we can't be sure. In PASCAL or C we KNOW that it

The PC Assembler Tutor mmvi

didn't change any code. This is the difference between a
structural engineer HOPING that a bridge won't fall down and
KNOWING that a bridge won't fall down.

In fact, the PASCAL and C programmers will probably be annoyed
when they start using assembler because in assembler, ALL names
are valid everywhere. More importantly, however, these
programmers will make great efforts to insure that all constants
stay constants and that each variable is used for one job only.

Finally, some BASIC programmers still do most of their
programming using GOTO statements instead of CALLs. This is the
antethesis of modular programming and is called spaghetti
programming. The code winds up as an intertwined mess. If you are
one of these people, once you start writing assembler code it
will be impossible to figure out what the code is doing once it
is longer than a page or two.

All that being said, if you feel that your programming style is
clear and orderly, have a fun time learning assembler. When you
are done with all the chapters, read the second BASIC appendix on
the problems associated with linking a non-BASIC subprogram to a
BASIC program.

 December 5, 2017  Add comments

Leave a Reply