EASy68K Beginner’s Guide

Introduction to Software Development Using

the EASy68K Assembly Language Tool
Part I

EEE3231 – Microprocessors Lab

Supplementary Material

Peter Csaszar
Department of Electrical and Computer Engineering
Lawrence Technological University

All Rights Reserved

HANDY HANDOUTS™ COLLECTION

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

TABLE OF CONTENTS

1. INTRODUCTION ............................................................................................................................... 3
2. PROGRAMMING IN 68000 ASSEMBLY........................................................................................ 3
2.1. THE CLASSIC ASSEMBLY PROCEDURE ........................................................................................... 3
2.2. DEVELOPMENT OF 68000 CODE ON A PC....................................................................................... 4
2.3. ASSEMBLY PROCEDURE USING THE EASY68K ............................................................................. 4
2.4. ADVANCED TOPICS ........................................................................................................................ 5
3. INTRODUCTION TO THE EASY68K ASSEMBLY LANGUAGE TOOL ................................. 6
3.1. EDIT68K EDITOR/ASSEMBLER....................................................................................................... 6
3.1.1. Launching Edit68K .............................................................................................................. 6
3.1.2. Customizing Edit68K............................................................................................................ 6
3.1.3. Creating, loading and saving a source file .......................................................................... 7
3.1.4. Editing a source file ............................................................................................................. 7
3.1.5. Assembling and running a source file .................................................................................. 8
3.2. SIM68K SIMULATOR ...................................................................................................................... 8
3.2.1. Launching Sim68K ............................................................................................................... 9
3.2.2. Loading an S-record file ...................................................................................................... 9
3.2.3. Running and pausing the simulation .................................................................................... 9
3.2.4. Single step execution .......................................................................................................... 10
3.2.5. Breakpoints ........................................................................................................................ 10
3.2.6. Restarting execution........................................................................................................... 10
3.2.7. View windows..................................................................................................................... 11
3.2.8. Logging .............................................................................................................................. 12
3.2.9. Simulating exceptions......................................................................................................... 13
3.2.10. Using the TRAP #15 Simulator Function Calls.................................................................. 13
4. CONCLUSIONS ................................................................................................................................ 14
REFERENCES ........................................................................................................................................... 14

Peter Csaszar – Lawrence Technological University, ECE Department 2

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

1. INTRODUCTION
This document is the first part of the two-part series introducing the development of assembly
language programs for the Motorola 68000 microprocessor with the excellent EASy68K
Assembly Language Tool. In the first part of this writing the generic procedure of assembly
language programming, and the specific process offered by the EASy68K assembler/simulator
platform, are introduced. This is followed by the detailed guide for the executables in the
development suite. This writing’s companion document [2] takes the discussion to the next step;
it introduces the fundamental knowledge necessary for writing assembly programs, thus creating
the link between the assembler utility (requiring specific details about the processor’s
environment) and the microprocessor’s assembly language (a collection of abstract instructions
specific to the processor itself, see [1]).

2. PROGRAMMING IN 68000 ASSEMBLY

2.1. The Classic Assembly Procedure
From the very early days of computer programming, the translation of human-friendly program
code (referred to as source code) into code that is executed by a computer’s processing unit
(referred to as machine code or executable code) was a procedure of key importance, which
enabled programmers to successfully produce reliable high-complexity programs, without losing
their sanity. This translation is commonly referred to as compilation, and the software responsible
for this task is the compiler. The simplest programming languages, bearing a very close
correspondence to a processing unit’s machine code, are the assembly languages. The assembly
compilation procedure is referred to as assembling, carried out by the software tool called
assembler.
According to the generic compilation paradigm, one large program may be developed out of more
than one source code, which may even be written in multiple different languages. These sources
are compiled with the appropriate compiler into fragments of unfinished machine code referred to
as object code. The task of merging the object code fragments together into the final single
machine code is the job of the linker. The idea is demonstrated in Figure 1 below.

Source 1:
C compiler Object 1
C code

Source 2:
68000 assembler Object 2 Linker Executable
68000 code

Source 3:
Pascal compiler Object 3
Pascal code

Figure 1 - Classic Compilation Procedure

With the advent of the Java language and the Microsoft .NET platform, the compilation scheme
has gotten even more complex. However, with the EASy68K tool, the actual 68000 assembly
procedure will be simpler than the one depicted above; the details will be shown in Section 2.3.

Peter Csaszar – Lawrence Technological University, ECE Department 3

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

2.2. Development of 68000 Code on a PC

The Motorola 68000, now replaced by more advanced devices in industry, is the microprocessor-
of-choice in many introductory microprocessor courses for several reasons.
1. The 68000’s hardware is sufficiently simple, so the basics of computer architecture can
be demonstrated, but it also contains advanced solutions that became the precursors of the
complex features in modern microprocessors (for example memory interleaving).
2. The 68000’s software architecture, inspired by the DEC PDP-11 minicomputer, is
amazingly well-designed and powerful; the perfect platform to introduce the basic
concepts of assembly programming, and assembly’s linkages to high-level languages.
3. In many of its newer microprocessors and microcontrollers, Motorola keeps maintaining
software compatibility with the 68000, in order to make legacy programs easy to port,
and make the learning curve for new products less hectic.
However, at the time of this writing, most desktops and personal laptops running the Microsoft
Windows operating systems are Intel 80x86 microprocessor-based (so-called PC-compatible)
computers, for which the 68000 machine code is not native. This leaves all 68000 assembly
expert wannabes with two choices:
• Get hold of a development board containing a real-life 68000 microprocessor (or a
microcontroller supporting backward-compatibility with the 68000 assembly), and do all
programming and debugging on this platform. The success of this venture greatly
depends on the quality of the assembler utility (be it on-board or PC-based) and the
debugging facility supported by the board.
• Get hold of a 68000 assembler/simulator software package written for the PC
environment.
This document assumes that the reader followed the latter approach. The best utility currently
with the aforementioned features is the EASy68K Assembly Language Tool, an exquisite freeware
developed by the fine gentlemen at the Monroe County Community College in Monroe,
Michigan. The tool supports the Win32 platform of the Microsoft Windows products (including
XP), and consists of an integrated editor/assembler and a simulator. The simulator tool simulates
a minimal 68000-based architecture, including a complete 68000 processor with all registers, and
the entire 16 MB memory space available as RAM. It also provides basic input/output services
through the host computer’s keyboard and screen, and even more advanced features such as file
handling, graphics and sounds. The built-in full-fledged debugging facility supports step-wise
execution, and continuously updated register/memory content display. The EASy68K homepage
is located at
http://www.monroeccc.edu/ckelly/easy68k.htm
This page contains the tool’s downloadable install file, news about upgrades, and plenty of great
examples.

2.3. Assembly Procedure Using the EASy68K

The 68000 program development in the EASy68K environment will be different from the classic
procedure depicted in Figure 1.
Assembling is done with the EASy68K suite’s Edit68K Editor/Assembler (Edit68K.exe)
program, which is a source editor and 68000 assembler built together. The assembler only
supports the assembly of a single 68000 assembly source code (.X68), therefore there is no need
for generic object codes and linking. (A very long assembly source can be separated and included
one-by-one using the INCLUDE assembler directive. However, from the assembler’s point of
view this is considered as a single source.)

Peter Csaszar – Lawrence Technological University, ECE Department 4

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

The PC-simulation of the non-native 68000 assembly code described in the previous section is
implemented by the Sim68K simulator (Sim68K.exe).
The EASy68K assembler generates two important files, the S-record file and the list file.
1. S-record file (.S68): This file serves as the equivalent of the 68000-executable binary
machine code, but in a “tame” ASCII format (encoded to contain only printable ASCII
characters, arranged in lines with limited length), as specified by Motorola. (This
encoding guarantees that the machine code can be handled by communication protocols,
such as RS-232, used by development boards for receiving machine code. EASy68K’s
simulator can also read the S-record file, and conduct the simulation of the “executable.”
Note: The EASy68K assembler can also produce the optional Binary file (.BIN), with
the actual 68000 machine code inside. This may be used with development boards,
emulators or other simulators requiring the machine code in this format; however, the
Sim68K simulator has no use for this file.
2. List file (.L68): This file contains the copy of the original source file, with one important
difference: each line of the source is preceded by the corresponding machine code, and its
absolute address, in hexadecimal format.
Tip: The historical purpose of the list file is to verify code correctness during the
debugging procedure. However, it bears a crucial importance in the EASy68K
environment; without the corresponding list file, the Simulator is not able to do source-
level debugging of the assembly program represented by the S-record file. (Source-level
debugging means the ability to execute instructions in single steps with the help of the
original source code.)
The following figure summarizes the software development cycle using the EASy68K suite.

Assembly List Source-level

File [.L68] Debugging

68000 Source Edit68K 68000 Machine Sim68K

Code [.X68] Assembler Code [.S68] Simulator

68000 Machine Processor Board

Code [.BIN] or Emulator

Figure 2 - Assembly and Debug Procedure with EASy68K

The objects represented by dashed line are optional, and are not part of the usual procedure
discussed in the rest of this document.

2.4. Advanced Topics

A few other terms mentioned in conjunction with assembly programming will be introduced here
briefly for reference purposes. The interested reader is encouraged to study these topics further.
Disassembly – The act of disassembly consists of restoring the original assembly source code
from the machine code. (Applications range from different malicious intents to desperate attempts
to reproduce accidentally deleted source files.) Due to the close correspondence between

Peter Csaszar – Lawrence Technological University, ECE Department 5

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

assembly code and machine code, disassembly sessions can be quite successful. (Don’t expect
similar results restoring massive C++ sources…) However, disassembly will never be able to
restore the helpful hints contained in the source file, such as meaningful label names, and most
importantly, comments.
Cross-assembly – The original meaning of this overloaded term is the conversion of machine
code for a certain processor into machine code for another one. In most cases, this task is not only
useless, but also very complicated due to the vastly different features offered by microprocessors.
A somewhat sensible application is the upgrade of legacy code for a newer processor within the
same family; however, even this task is better achieved by recompiling the original [platform-
independent] source to the new processor.

3. INTRODUCTION TO THE EASY68K ASSEMBLY LANGUAGE TOOL

As it was pointed out in Section 2.3, the EASy68K tool consists of two stand-alone executables:
the Edit68K editor/assembler and the Sim68K simulator/debugger.
Tip: To make the program development process easier, it is possible to invoke the Simulator
from within the Editor shell (see Section 3.2.1); however, it must be understood that each time it
is done, a new instance of the Sim68K executable will be launched. Failure to realize this fact is
one of the primary sources of confusion among EASy68K users.

3.1. Edit68K Editor/Assembler

Edit68K is responsible for editing and assembling a 68000 assembly language program.

3.1.1. Launching Edit68K

There are two ways to launch Edit68K:
1. Choose the “Start > Programs > EASy68K > Edit68K” menu item in Windows. In this
case, an editor window for a new source named “untitled1.x68” appears, with the
contents of file “template.NEW” (located in the EASy68K install directory) preloaded.
The template is a few lines of code that helps to get started; it can also be customized.
2. Double-click on an already existing source file (*.X68); this will launch Edit68K, with
the source file loaded into the [first] editor window.

3.1.2. Customizing Edit68K

If run for the first time, it is a good idea to customize the operation of Edit68K to one’s
preferences. Below is a recommended configuration:
• Assembler options (“Options > Assembler Options…” menu item)
o “Generate List File” checkbox: On (See Section 2.3.)
o “Generate Binary File” checkbox: Off (Unless it is required by a third-party
product; see Section 2.3.)
o “Generate S-Record” checkbox: On (See Section 2.3.)
o “Save Source Before Assemble” checkbox: On
Tip: It is highly recommended to turn this feature on! Save source under a
different name if you want to revert to a previous version.
o “Show Warnings” checkbox: On (Warnings typically indicate something
erroneous in the code, and even though they don’t prevent the assembler from
generating machine code, they should be eliminated by all means.)

Peter Csaszar – Lawrence Technological University, ECE Department 6

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

o “List File Options” group: It is sufficient to check the “Cross Reference”

checkbox; the rest is only necessary if structured control statements or macros are
used. (These tools are beyond the scope of this document; see the EASy68K
Online Help [4], under “Assembler Commands > Structured Control” and
“Assembler Commands > Macros” for further information.)
o “Template” tab: In this editor box, the “template.NEW” file can be
customized. (Make sure to save it with the “Save Template” button; OK-ing the
entire Options dialog without a prior save will discard all changes!)
• Editor options (“Options > Editor Options…”)
These options are really up to one’s personal taste. However, here are some ideas:
o Font: Among the fixed-width fonts, probably Courier New font looks the best.
o Font size: This is where the real trade-off is. Size 10 is easy to read, but limits the
amount of comments that can be put in a line. The total number of characters
fitting in one line is 91 when printing the source from Edit68K. Size 8 fits 115
characters in a printed line, but is certainly harder to read. In most cases, size 10
is probably the most practical.
o Fixed vs. assembly tabs: Assembly tabs [shorthand for tabulator stops] are placed
at uneven distances predefined in Easy68K, to best fit the typical character
requirements of the assembly source. Fixed tabs span even distances adjustable
from the same dialog box. One reason to stick to fixed tabs with size 8 is that if
there is ever a need to open the assembly source in a generic editor (for example
on a machine, where EASy68K is not installed), or to send it to a generic printer,
any other tab setting will result in a disgustingly messy appearance.

3.1.3. Creating, loading and saving a source file

A new assembly source can be created in Edit68K anytime if the “File > New X68 Source File”
menu item or the usual <New> toolbar button is chosen; an editor window titled
“untitled<n>.x68” pops up with the contents of file “template.NEW” preloaded. An
already existing assembly source can be loaded through the “File > Open…” menu item, the
Ctrl-O hotkey or the usual <Open> toolbar button. (The same can be achieved directly from
Windows by double-clicking on the desired .X68-file.) The “File > Save” menu item, the Ctrl-S
hotkey or the standard <Save> toolbar button updates the edited file on the disk; with the
“File > Save As…” menu item, the file can be saved under a different name.

3.1.4. Editing a source file

The built-in editor of Edit68K provides the usual editing features familiar from general-purpose
editors (e.g., Notepad), including cut/copy/paste through the system clipboard, Undo (only 1 level
in Edit68K!), a Find/Replace facility and printing.
The most important formatting requirement for a well-written assembly source code is proper
tabulation. The assembler accepts any kind of white space between fields, which can be as little
as a single Space character; however, a human reader would require that each of the different
fields of the assembly source line (see [2]) be tabulated to the same column.
Having concluded in Section 3.1.2 that the Fixed Tabs option is the most practical, the only
remaining question is, at which tabulator positions the different fields should begin. Since the
width of the statement field and even the arguments field are rather consistent (unless both
arguments are labels, which is relatively rare), the trade-off is between the length of labels and the
length of in-line comments. Section 2.2 of the 68000 Quick Start Guide [2] explains why labels
are preferred to be in the same line as the statements; this means that the statements should be

Peter Csaszar – Lawrence Technological University, ECE Department 7

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

sufficiently indented, in order to leave room for reasonably long labels. The following tabulator
column recommendation (counted from the beginning of the line) assumes fixed tabs with size 8:
o Label: 0 tabs [i.e., the beginning of the line]
o Statement: 2 tabs (max. label length: 15 characters)
o Arguments: 3 tabs
o Comments: 5 tabs (max. argument length: 15 characters)
Note: The EASy68K assembler allows white space after any comma (‘,’) character, e.g., between
two arguments, or within the value list of the DC assembler directive. This decision is really left
up to the programmer; it is not considered bad assembly programming style not to put spaces to
the aforementioned positions.
Tip: The caret (‘^’) character on the bottom of the editor window helps to identify where a line
should end. For the Courier New font, the caret enforces the following total line lengths:
• Size 8: 89 characters
• Size 10: 79 characters
This is more conservative than the printing limitations, therefore typing past the caret is not a big
disaster.

3.1.5. Assembling and running a source file

The completed assembly program can be assembled with the “Project > Assemble Source…”
menu item, the F9 hotkey or the <Run> (“Play” arrow) toolbar button. Upon successful
completion, the “Assembly Status - <filename>” pop-up dialog box offers to execute the
program; clicking the “Execute” button will launch Sim68K, the EASy68K suite’s simulator,
with the corresponding S-record file and list file loaded. All assembly warnings and errors are
displayed in the lower part of the editor window; if the program contained errors, the “Execute”
button in the pop-up dialog box is disabled.
Further help on the Edit68K’s operation is available from the EASy68K Online Help [4], under
“Editor Operation”.

3.2. Sim68K Simulator

Sim68K is used to execute, and optionally debug, a previously created and assembled 68000
assembly language program. Figure 3 shows the toolbar provided by the Sim68K program.

Auto Trace Reset

Run
Trace Into Program
(F9)
(F10) (F7) (^F2)

Run To Step Reload

Open Pause
Cursor Over Program
(F6)
(^F9) (F8) (^F3)

Figure 3 - Toolbar of Sim68K

These buttons will be referenced in the following discussions.

Peter Csaszar – Lawrence Technological University, ECE Department 8

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

3.2.1. Launching Sim68K

There are three ways to launch Sim68K:
1. Choose the “Start > Programs > EASy68K > Sim68K” menu item in Windows. In this
case, the Simulator opens with a blank environment.
2. Double-click on an already existing S-record file (*.S68); this will launch Sim68K. If a
corresponding list file (same name, “.L68” extension) exists in the same directory, it will
be loaded into the simulated environment’s source-level debugging field [the large area
under the register displays].
3. Upon successful assembly in Edit68K, click the “Execute” button in the “Assembly
Status - <filename>” pop-up dialog box. (Since this action produces both an S-record file
and a list file, the source-level debugging field will show the lines of the list file, and the
Simulator is ready for operation.)

3.2.2. Loading an S-record file

A 68000 assembly program can be simulated by loading its corresponding S-record file into the
Simulator using the “File > Open…” menu item or the <Open> toolbar button.
Note: If the S-record file is not accompanied by a list file with the same name [but with extension
“.L68”], source-level debugging is not possible i.e., the user cannot see the trace of execution
through highlighted lines of the source. Furthermore, simple breakpoints cannot be placed.

3.2.3. Running and pausing the simulation

The following commands can be used for simple execution control:
• Run – “Run > Run” menu item, F9 hotkey or <Run> toolbar button
Switches the Simulator to Running Mode and starts program execution. While the
program is in Running Mode, the emerging Output Window will display all program
output, and prompt for user input whenever desired; also, all execution control menu
items and toolbar buttons other than Pause are grayed out.
• Pause – “Run > Pause” menu item, F6 hotkey or <Pause> toolbar button.
Pauses program execution, and switches the Simulator to Paused Mode. All information
in the Simulator’s main window (registers and the Cycle Counter), as well as the contents
of the view windows (see Section 3.2.7) are refreshed. Execution can either resume with
the Run command, or continue in Paused Mode with the single step execution commands
of Section 3.2.4.
Note: The Simulator does not have a Stop command per se; it can only be paused with the
possibility to restart. Only the TRAP #15, task code 9 function call (or the STOP #n assembler
instruction in certain conditions) can terminate the simulated program; when this happens, all
execution buttons become grayed out. A program [terminated or still active] can be restarted
using the Reset Program or Reload Program simulator commands (see Section 3.2.6).
Tip: A very useful feature suggested by the author of this document was added to the Simulator
in version 2.9.8:
• Run to Cursor – “Run > Run To Cursor” menu item, Ctrl-F9 hotkey or <Run To
Cursor> toolbar button.
Runs the program, but automatically pauses it before the instruction under the Execution
Cursor. This command offers a breakpoint’s functionality, without the need of placing a
permanent breakpoint (see Section 3.2.5). This is a great way to quickly hone in to
problematic areas in the program, and continue debugging with single step execution.

Peter Csaszar – Lawrence Technological University, ECE Department 9

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

3.2.4. Single step execution

When the program is in Paused Mode, it is possible to step through individual instructions using
two different commands.
• Trace Into – “Run > Trace Into” menu item, F7 hotkey or <Trace Into> toolbar button.
Executes the instruction under the Execution Cursor; if the instruction is a subroutine
call, the execution will descend into the subroutine.
• Step Over – “Run > Step Over” menu item, F8 hotkey or <Step Over> toolbar button.
Executes the instruction under the Execution Cursor; if the instruction is a subroutine
call, the execution will not descend into the subroutine.
Warning! Instructions skipped through the commands of Section 3.2.3 will not leave a trace
behind in the Execution Log (see Section 3.2.8); only the above two commands will generate an
entry, reflecting the execution context (register and/or memory contents) after the stepped-
through instruction completed.
Tip: A very useful and extremely spectacular feature was added to the Simulator in version 2.9.1:
• Auto Trace – “Run > Auto Trace” menu item, F10 hotkey or <Auto Trace> toolbar
button.
Automatically executes a Trace Into command with the time interval defined by
“Options > Auto Trace Options… > Auto Trace Interval”. This simulation command
is helpful when an execution log entry is required for every instruction. However, it can
also be quite educational to see the execution path a program takes, especially to
understand the principles behind nested loops, recursive subroutine calls and other non-
trivial situations. Furthermore, observing the constantly updating values of register
contents can help identify the location of certain bugs quickly.

3.2.5. Breakpoints
If only a certain section of the program exhibits problems, it would be very tedious to reach the
desired point through single steps. The EASy68K makes it possible to “cut to the chase” through
breakpoints. If a program execution launched with the Run command encounters a breakpoint,
the Simulator is switched to Paused Mode, and the commands for single step execution become
available. Breakpoints can be toggled by clicking on the colored dot preceding each line of the
list file in the Simulator window. Red indicates the presence of a breakpoint; otherwise the color
of the dot is green.
Tip: Breakpoints can be “hard-wired” into the source code by placing the “*[sim68k]break”
string starting from position 1 into the line immediately preceding the line to be breakpointed.
(This feature is useful when a certain portion of the code is being tested for an extended period of
time; there is no need to place a breakpoint in the Simulator manually over and over again.)
Note: Advanced breakpoint conditions can be selected through the “View > Breakpoints” menu
item; however this feature is only recommended for advanced users!

3.2.6. Restarting execution

A terminated program, as well as an active program [in Running or Paused Mode] can reset from
the Simulator (although it is not very recommended for active programs). The reset program
always starts out in Paused Mode. The following commands are available:
• Reset Program – “Run > Reset Program” menu item, Ctrl-F2 hotkey or <Reset
Program> toolbar button
The simulated processor is reset to its initial state. All registers are reset to 0, except the
Supervisor Stack Pointer (loaded with $01000000 – just above the highest addressable

Peter Csaszar – Lawrence Technological University, ECE Department 10

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

memory position; recall that the “PUSH” stack operation is implemented with the
Address Register Indirect with Predecrement addressing mode), the Status Register
(loaded with $2000 – Trace Mode off, Supervisor Mode on, all interrupts enabled) and
the Program Counter (initialized to the address of the label in the loaded program’s END
directive). The program is ready to execute from the beginning; however, this command
has no effect on the memory contents whatsoever.
• Reload Program – “Run > Reload Program” menu item, Ctrl-F3 hotkey or <Reload
Program> toolbar button
Same as Reset Program, but the memory areas defined by a DC or DCB directive are also
reinitialized. This command must be used when a program contains any of these
directives to define memory contents that will be subsequently overwritten.
Note: The Reload Program command will close any execution logging or output logging (see
Section 3.2.8) in progress.

3.2.7. View windows

The Sim68K simulator’s status can be monitored through the following views:
• Main window. The top of this window shows the contents of every data and address
register (including the User Stack Pointer [USP] and Supervisory Stack Pointer [SSP]),
the Program Counter [PC] and the Status Register [SR]. Another very useful feature is
the Cycle Counter that shows the number of clock cycles executed during the most recent
simulation of the given program.
Note: A clock cycle represents a full period of square wave on the processors external
CLK input. The cycle time can be calculated as T = 1/f, where f is the clock frequency.
Therefore, from the clock frequency and the Cycle Counter’s value, a programs running
time on a real-life system, can be estimated.
Tip: The Cycle Counter can be queried and reset from an assembly program using the
appropriate TASK #15 function calls (task codes 31 and 30 respectively, see the
EASy68K Online Help [4], under “Simulator I/O > Simulator”).
Warning! The Cycle Counter wraps around after 232 (a tad more than 4 billion) cycles,
which takes approximately three minutes on a Pentium 4 processor running at 4 GHz; for
long-running programs, the Cycle Counter’s contents are meaningless.
• Memory View. This window shows the contents of the entire 16 MByte simulated
memory space. Use the navigation arrows or enter an address in the “Address” field to
reach the memory area to be monitored.
It is possible to change the contents of individual memory bytes run-time, for different
debugging purposes. Data can be given as hexadecimal digits (left pane) or as printable
ASCII characters (right pane).
It is also possible in this window to manipulate entire blocks of memory. The following
parameters are required in the text fields:
o Copy – Copies “Bytes:” number of bytes from address “From:” to address “To:”.
If the two blocks overlap, the destination block must begin at a lower address.
o Fill – Fills up the memory area from address “From:” to address “To:”
(inclusive) with the 4-byte pattern specified in “Bytes:”.
• Stack View. The contents of the stack are shown, broken down as longword values. The
current location of the ruling stack pointer (USP vs. SSP) is marked with a different
background color. Another marker can be associated with any of the address registers;
this feature is very helpful to verify the contents of a stack frame arrangement.

Peter Csaszar – Lawrence Technological University, ECE Department 11

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

• Hardware View. A great addition to the views of Sim68K from version 3.0 is the
Hardware View window that implements the simulation of certain common hardware
features. These are:
o Input-output devices. Associated with a unique memory peripheral address
beginning at $E00000, these devices implement 8 pushbutton inputs, toggle
switch inputs, LED outputs (8 bits in a byte), plus an 8-digit 7-segment display
output (8 bytes, with bitmapped segment data in each byte).
o Interrupt buttons. These 7 pushbuttons can simulate an autovector hardware
interrupt event. It is also possible to associate one of these interrupt signals with
the Auto-Interrupt Timer, with a firing period defined as a multiple of 100
milliseconds. This latter feature provides a way to simulate timer-triggered
interrupts, a very common technique in microcontroller environments.
o Reset button. This button simulates a processor Hardware Reset event.
Note: This simulated hardware reset must not be confused with the Reset
Program simulator command. When a Hardware Reset event occurs, the SSP and
PC registers are loaded from the first two entries of the processor’s simulated
Exception Vector Table respectively, and the SR is loaded with the value $2700
(only the non-maskable interrupt is enabled); this is the exact procedure a real
68000 processor follows as a response to a hardware reset.
Warning! At the time of this writing, the Simulator (v3.4) responds to the
Interrupt and Reset buttons, even if the simulation of exceptions is not enabled
(see Section 3.2.9). Avoid tampering with these buttons if the corresponding
Exception Vector Table entries have not been set up properly.
More information about the Hardware View Window can be found in the EASy68K
Online Help [4], under the “Simulator Operation > Hardware Window” entry.

3.2.8. Logging
The Simulator provides two different logging facilities.
1. Execution logging. It is possible to save the status of the Simulator into a logfile during
execution, by selecting one of the Execution Log type options from the dialog accessed
through the “Options > Log Output…” menu item. This information includes the
executed instruction, the contents of all 68000 registers, and since version 2.2 – thank to
the suggestion from the author of this document – also the contents of a selected memory
area, after an instruction was stepped through with one of the single step execution
commands in Paused Mode (see Section 3.2.4).
Note: Remember that when memory logging is also requested as part of the Execution
Log, the starting address and number of logged bytes must be provided in hexadecimal.
Warning! As it has been mentioned previously, the running commands of Section 3.2.3
produce no Execution Log. Zooming through the entire program containing no
breakpoints with the Run command will write nothing in the Execution Logfile!
2. Output logging. By turning on the output logging feature of the Simulator from the
“Options > Log Output…” menu item’s dialog, all characters displayed in the output
window will be saved in the output logfile. This also includes the characters entered
through user input (unlike the “>” redirection operator in Unix and DOS), which makes
this facility perfect for recording the input/output events of a simulation session.
The default logfile names are derived from the name of the assembly source file, but can be
changed freely. The logging features are generally very intuitive. However, further information is
provided in the EASy68K Online Help [4], under the “Simulator Operation > Options” entry.

Peter Csaszar – Lawrence Technological University, ECE Department 12

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

3.2.9. Simulating exceptions

As one of the very exquisite features of the Simulator, it implements the simulation of almost all
exceptions existing on a real 68000 processor; this also includes hardware exceptions, courtesy of
the features provided by the Hardware View window. In order for the Simulator to simulate all
exceptions exactly the way a 68000 does, the simulation of exceptions must be enabled through
the “Options > Enable Exceptions” menu item. (A checkmark next to the menu item indicates
enabled exception simulation.)
Tip: When the simulation of exceptions is enabled, the Simulator responds to an exception event
by saving the processor’s execution context on the stack (see [3], chapter 4), and fetching the
address of the execution handler from the appropriate entry of the Exception Vector Table.
Obviously, in order for this to work, the vector table entry needs to have been set up properly,
otherwise the simulation goes haywire. This would be very confusing for beginners, who know
little about exception handling, and the Simulator’s strange response to uninitialized exception
vectors would leave them puzzled. This is why it is possible to disable exception simulation in
Sim68K; in this case the occurrence of an exception immediately stops the simulation, with the
given exception printed in the status field (bottom portion) of the Simulator’s Main window.

3.2.10. Using the TRAP #15 Simulator Function Calls

In many computer systems, designers utilize the software exception (a.k.a. software interrupt)
feature—available on many microprocessors—for accessing services provided by the computer’s
operating system. On the 68000, the TRAP #<n> software exception instruction is particularly
suitable for this purpose, as it also switches the processor to Supervisor Mode (see [3], chapter 4),
which is in line with the philosophy promoting the separation of operating system code from user
code through privilege levels.
The design of the EASy68K simulator follows this paradigm, and dedicates the TRAP #15
instruction for a special purpose: instead of passing it through the usual exception handling
simulation procedure (see Section 3.2.9), it hijacks this instruction, and uses it to access the
simulated computer’s “operating system.” This pretended operating system turns the host
computer’s peripherals into the simulated computer’s peripherals, and implements a variety of
commands (referred to as function calls) including text input/output, file handling, graphics and
even sound. These function calls, all “hooked up” to the confiscated TRAP #15 software
exception, share a common structure shown below. (Not all steps occur for every function call.)
1. Input parameters are required in one or more of registers A1 (string parameter), or D1,
D2, D3 and D4 (numeric or character parameter, with the appropriate data type).
2. The unique task code of the function call is required in register D0.L.
Tip: At the time of this writing, all task codes supported by the Simulator (v3.4) fall
within the range of positive signed bytes (0…+127); therefore the MOVEQ instruction is
particularly suitable for loading the task code into D0.L.
3. The function call is invoked using the TRAP #15 instruction.
4. Result (numeric or character) is returned in register D1 (standard) or D2 (typically if the
function call required an input parameter in D1).
Warning! Recognize that even for the string input function call (task code: 2), register
A1 is not an output parameter, but an input parameter instead. This is due to the fact that
this function call requires a sufficiently large buffer preallocated, whose starting address
is passed in register A1; the input string will be placed into this buffer. Since the function
call terminates input after 80 characters, the size of the buffer must be set to least 81
bytes (due to the string-terminating 0-character that is automatically appended to the end
of the string).

Peter Csaszar – Lawrence Technological University, ECE Department 13

EEE3231 – Microprocessors Lab EASy68K Beginner’s Guide

Tip: The most frequently used function calls belong to the group called “Text I/O”; the majority
of these use registers D1 and/or A1 for passing parameters, and only a few uses D2 as well.
Therefore it is recommended to reserve D0, D1 and A1, and refrain from using them for any other
purpose than the function calls (except maybe for very short-term temporary data storage), so that
no bad surprises or inexplicable bugs will occur during program development.
Warning: On a similar note: register A7 is the system stack pointer, therefore must be fully
reserved in all programs using subroutines and/or exceptions.
Note: Keep in mind that the numeric input/output function calls of the Text I/O group use the
entire 32 bits of the D1 register for data transfer, and regard its contents as a signed longword
(with range –2,147,483,648…+2,147,483,647). If the value to be input/output has a different data
type, conversion overflow testing or sign extension is required respectively.
The complete list and specification of the TRAP #15 function calls can be found in the EASy68K
Online Help [4], under the “Simulator I/O” entry. The Text I/O group’s function calls are listed
in the “Text/Time/Terminate” subentry.

4. CONCLUSIONS
This document introduced the EASy68K Assembly Language Tool, a premium environment for
developing and simulating 68000 assembly code on a PC running Microsoft Windows.
The author would like to express his appreciation to Professor Charles Kelly at Monroe County
Community College (Monroe, Michigan) for the development and maintenance of the EASy68K
suite, a truly remarkable software toolkit for the 68000 microprocessor.

REFERENCES
[1] Motorola, Inc.: M68000 8-/16-/32-bit Microprocessors Users Manual. (Reprinted by multiple
publishers, e.g. Prentice Hall, 1989; Barnes & Noble, 1991.)
[2] Peter Csaszar: 68000 Quick Start Guide. (Microprocessors Lab supplementary material.)
Lawrence Technological University, 2006.
[3] James L. Antonakos: The 68000 Microprocessor. Fifth Edition. Pearson Prentice Hall, 2004.
[4] Charles Kelly: EASy68K Assembly Language Tool Online Help. (Edit68K “Help > Help”
menu item or Sim68K “Help > Sim68K Help” menu item.)

Peter Csaszar – Lawrence Technological University, ECE Department 14