with
the tools you need to create assembly language programs. Future topics
include an on-going inside look and comparison of the 6502/65c816 central processing units, the instructions these processors understand, data
movement, addressing modes, both simple and complex, application flow
control, arithmetic, and logic and bit manipulation. We will also devote
time to the stack and interrupts - advanced subjects that even many
seasoned programmers do not fully understand. But you will.

Along the way I'll throw some good programming tips and habits at you,
things I have picked up in my own never-ending path to knowledge. We have plenty of time to learn programming in assembly language, and I promise,
there is plenty to learn. Our goal is to explore and learn, so let's start right now...

THE ASSEMBLER

In order to create assembly language applications you will need an
assembler. An assembler is the tool you use to translate text-based source code into executable code. You, as the programmer, feed the assembler with symbolic pseudo-language text files and the assembler outputs binary files
the computer understands. Thankfully, the assemblers we can choose from
are free and easy to obtain, and below is a table showing you where to find them. In the course of my own personal exploration I have used countless assemblers, so I have seen some good ones and, shall we say, some not so
good ones. Some (arrggh!) I typed in from magazine or book listings.

But before we do that we have a decision to make. Do we want to create our applications directly on the Commodore 64 or do we wish to do our
development on the PC? Many purists would argue the former. Well, I have
an opinion about that, so it's probably a good time for Tip #1:

Tip #1: Create on the PC and test on
the c64.

I have what I feel are good reasons to believe this, but Tip #1 is not a
golden rule. The applications you create on your physical or emulated c64
are no different than those drawn up on the PC, so feel free to code on
either the real thing or in VICE, or both, but there are other factors you
may want to consider.

First, and most important, is development time. Twenty five years ago most programmers created programs right on their c64s. Most amateur
programmers, that is. The pros were busy developing on machines that were faster and had more memory. They stored their source files on disk drives
that were much faster and larger than the c64 could offer.

As projects grow in size the assembly process becomes a time-consuming
burden. And let's face it: this is not the 80s. Computer users today
expect sophistication. They expect things to be easy. This means you will have to work harder to impress them. What I am saying is that in today's
world you will probably not get away with rainbow colors, INPUT statements,
and CBM character graphics. A modern user interface is going to require
better planning, some creativity, the mouse, and ultimately much larger and more complex source files, so if you are developing on a stock 64, even one equipped with JiffyDOS or an IDE64, you will soon find yourself waiting increasingly longer for your project to compile into its final, executable
form - and that's just a waste of good development time.

A second major reason to create your applications on the PC is that
developing programs on the test machine risks contaminating both
environments. What if you need to use most or all of RAM for your program? That's going to be tough if you are developing and testing on the same
machine, especially since assemblers need some of that memory for
themselves. One assembler I consider to be excellent for native c64 development, Turbo Macro Pro, or TMP (listed below), has a version that
stores your source text in the REU. Although the size of the source is ultimately limited and the c64 can only compile the source code at 1 MHZ,
for small to medium-sized projects TMP would be my choice for native development. Noteworthy is the similarity between TMP and two PC
assemblers, TMPx v1.0 and 64Tass. Moving from one to either of the others should require few, if any, changes to your source text.

For larger applications the PC is the smart choice for development. For example, I am working on a project now that is comprised of well over 100 source files. By the time the project is finished it will use nearly all
of the stock c64 RAM and the source files will easily exceed 1 MB. It is further complicated by the fact that it is a SuperCPU-based project, and
makes extensive use of extended RAM. My 3 GHZ PC assembles all of it in
about a second - and does not disturb the Commodore 64 environment at all,
with testing in VICE an automatic task. I shudder to think how long it
might take to assemble on a real c64, even with a SuperCPU, and I wonder (doubtfully) if any native c64 assembler could pull it off.

In BASIC there is usually just one source file. There is a limit as to how large it can be and your program executes as soon as you type "RUN." If you make a typing mistake or some programming error the computer lets you know about it right away. Variables are stored safely away and unless you do
some crazy poke, the computer will not freeze up or "crash." The program
will just stop, tell you there is an error, and that's it. You are in
essence running managed code. Assembly language is different - there is no safety net. Syntax errors are caught by the assembler but otherwise you
are free to do what you want, where you want to do it. This leads to
frequent crashes, especially while you are learning. As you progress
through your assembly language journey the inevitable program crashes are a fact you will definitely get used to, and frankly, regardless your level of experience, crashes never really go away. The good thing, believe it or
not, is that crashes are almost always a good learning experience because,
if for no other reason, they bluntly point out a mistake you made
somewhere.

ASSEMBLERS FOR C64 APPLICATION DEVELOPMENT

-------------------------------------
ASSEMBLER (PLATFORM)
SUPPORTED CPU
WHERE TO GET IT
-------------------------------------
CBM prg Studio (PC-GUI)
6502/65816 (soon)
Arthur Jordison
www.ajordison.co.uk/
-------------------------------------
C64 Studio (PC-GUI)
6502
Georg Rottensteiner
www.georg-rottensteiner.de/en/
-------------------------------------
64Tass (PC-command line)
6502/65c816
Soci/Singular
sourceforge.net/projects/tass64/file
s/latest/download?source=directory
-------------------------------------
TMPx v1.0 (PC-command line)
6502
Style
style64.org/release/tmpx-v1.0-style
-------------------------------------
KickAssembler (PC-command line)
6502
Kick Assembler V3.30
theweb.dk/KickAssembler/Main.php
-------------------------------------
cc65 (PC-command line)
6502/65816
Ullrich von Bassewitz/Oliver Schmidt
oliverschmidt.github.io/cc65/
-------------------------------------
Turbo Macro Pro (TMP) (Native c64)
6502
The Wiz/Style, Elwix/Style
style64.org/file/Turbo_Macro_Pro_Sep
06_c64-STYLE.zip
-------------------------------------
Buddy/Power Assembler (Native c64)
6502
cbm8bit.com
cbm8bit.com/8bit/commodore/search
-------------------------------------
Sirius (Native SuperCPU)
6502/65816
Stephen L. Judd (The Fridge)
www.ffd2.com/fridge/sirius/
-------------------------------------

The list of assemblers above is by no means complete; rather, these are assemblers I am familiar with and have used with some success. These assemblers, many of which are being developed by active members in our community, come with different levels of complexity, functionality, and stability with regard to program bugs, which is to be expected, yet all are very capable and will help you get the job done. Just as with a home, car,
or TV, we all have have our own preference. There is no righ

--- MBSE BBS v1.0.01 (GNU/Linux-i386)
* Origin: Dragon's Lair ---:- bbs.vk3heg.net -:--- (39:901/280)