Easy68k Beginners Guide

EASy68K Beginners 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
TABLE OF CONTENTS
1. 2. INTRODUCTION ............................................................................................................................... 3 PROGRAMMING IN 68000 ASSEMBLY........................................................................................ 3 2.1. 2.2. 2.3. 2.4. 3. THE CLASSIC ASSEMBLY PROCEDURE ........................................................................................... 3 DEVELOPMENT OF 68000 CODE ON A PC....................................................................................... 4 ASSEMBLY PROCEDURE USING THE EASY68K ............................................................................. 4 ADVANCED TOPICS ........................................................................................................................ 5
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
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 writings 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 processors environment) and the microprocessors 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 computers 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 units 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 code Source 2: 68000 code Source 3: Pascal code
C compiler
Object 1
68000 assembler
Object 2
Linker
Executable
Pascal compiler
Object 3
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.
2.2.
Development of 68000 Code on a PC
The Motorola 68000, now replaced by more advanced devices in industry, is the microprocessorof-choice in many introductory microprocessor courses for several reasons. 1. The 68000s 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 68000s 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 assemblys 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 computers 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 tools 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 suites 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 assemblers point of view this is considered as a single source.)
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. EASy68Ks 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 sourcelevel 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 File [.L68]
Source-level Debugging
Sim68K Simulator
68000 Source Code [.X68]
Edit68K Assembler
68000 Machine Code [.S68]
68000 Machine Code [.BIN]
Processor Board 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
assembly code and machine code, disassembly sessions can be quite successful. (Dont 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 [platformindependent] 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 ones 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 dont prevent the assembler from generating machine code, they should be eliminated by all means.)
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 ones 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. o
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
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 suites 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 Edit68Ks 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.
Run (F9) Auto Trace (F10) Trace Into (F7) Reset Program (^F2)
Open
Run To Cursor (^F9)
Step Over (F8)
Pause (F6)
Reload Program (^F3)
Figure 3 - Toolbar of Sim68K These buttons will be referenced in the following discussions.
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 environments 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 Simulators 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 breakpoints 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.
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 steppedthrough 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 nontrivial 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
10
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 programs 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 simulators 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 Counters 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 Counters 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.
11
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 processors 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 items 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.
12
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 processors 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 Simulators 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 Simulators 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) featureavailable on many microprocessorsfor accessing services provided by the computers 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 computers operating system. This pretended operating system turns the host computers peripherals into the simulated computers 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).
13
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 groups 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.)
14

Easy68k Beginners Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Easy68k Beginners Guide

Enviado por

Direitos autorais:

Formatos disponíveis

EASy68K Beginners Guide

EEE3231 Microprocessors Lab Supplementary Material

HANDY HANDOUTS COLLECTION

EEE3231 Microprocessors Lab