0% found this document useful (0 votes)
96 views9 pages

CEG 3136 Lab1 PDF

Lab 1 Report for CEG3136 UNIVERSITY OF OTTAWA

Uploaded by

Lola Omowa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
96 views9 pages

CEG 3136 Lab1 PDF

Lab 1 Report for CEG3136 UNIVERSITY OF OTTAWA

Uploaded by

Lola Omowa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

CEG 3136 Lab1

Alarm Simulation
Design

James Lee (8862411)


Ziming Wang (8843923)
Sept, 30 2018
Objectives:

The objective of this lab is to introduce assembler programming by using Debug-12 Monitor.
Using assembler programming gave a grasp of assembling and running assembler code and
learning basic principles of debugging. Using the Dragon 12, we implemented an alarm system
simulation in assembler. The design is based on modular and structure programming. The alarm
system has been designed with configuration of master code, addition of secondary codes,
arming the alarm systems, trigger alarm and disarming the alarm system.

Equipment :
Windows PC
Dragon 12 Plus Trainer
MiniIDE
Visual Studio

Part 1 - Using the D-Bug 12 Monitor


The purpose of this section was to compile the code using the recommended IDE software and
running the code on Dragon board. Using the D-Big 12 Monitor, we assembled the program at
address $2000. As we entered the instructions, we tried to predict the machine code before
assembling it. Table 1.1 shows the breakdown of the machine instructions into the opcode and
operand for the following instructions. The inputs was an ASCII character and during the
runtime, the program would prompt us for the character and the output is the character being
printed on the console three times. By the end of the compilation, the code was modified to
execute fifteen times.

Using C-code to illustrate:


Address Content Instruction

2000 CC003A LDD #$3A

2003 FEEE86 LDX $EE86

2006 1500 JSR 0,X

2008 FEEE84 LDX $EE84

200B 1500 JSR 0,X

200D 8603 LDAA #3

200F 36 PSHA

2010 37 PSHB

2011 CC0020 LDD #$20

2014 FEEE86 LDX $EE86

2017 1500 JSR 0,X

2019 33 PLUB

201A FEEE86 LDX $EE86

201D 1500 JSR 0,X

202F 32 PULA

2020 43 DECA

2021 26EC BNE $200F

2023 3F SW1
Table 1.1: Original assembly code with address
Address Content Instruction Comment

2000 CC003E LDD #$3E Change prompt to


ascii ‘>’

2003 FEEE86 LDX $EE86

2006 1500 JSR 0,X

2008 FEEE84 LDX $EE84

200B 1500 JSR 0,X

200D 860F LDAA #15 Change counter to 15

200F 36 PUSHA

2010 37 PUSHB

2011 CC002C LDD #$2C Change separator to


ascii ‘,’
Table 1.2 Modified assembly code with address

Instruction Code Machine Code OP Code Operand Addressing


Mode

LDX $EE86 FEEE86 FE EE86 Extended


Addressing

JSR 0,X 1500 15 00 Indexed


Addressing

BNE $200F 26EC 26 EC Relative


Addressing
Table1.3 instruction in 1.b

First instruction is using a extended addressing mode, which uses 16-bit address to address all
64K addresses.
Second instruction is using indexed addressing mode, the base address is at register X with
offset address which is 0 in the instruction, so the effective address is X+$0= X.
Third instruction is using relative addressing mode with a 9-bit offsets whose range is between
-256 to 255.
Figure 1.1 machine code for part 1

Conclusion
After executing our code instructions to the assembler, our prediction of the machine code were
accurate and the results were demonstrated correctly.

Part 2 - Assembler
The objective of this section is to familiarize ourselves with MiniIDE and the process of
assembling the program. In this part, we assembled a program that has been coded in
alarmSimul.asm ​and other assembler files which simulate the alarm system using the Dragon-12.
Since, the delay module is non-existent, the program currently accepts any code as valid for
arming and disarming the alarm.

Addressing Mode
In table 2.1, the highlights demonstrates the cause of the “BCLR Clksel,x, %10000000.”
Underneath the highlights, there are two MOVW instructions. MOVW makes a copy of one
register pair into another register pair. In this example the ​MOVW #0, alarmCode,​ it is immediate
followed by extended-direct for the alarmCode while ​MOVW #1000, mult,​ it is immediate
followed by extended-direct.
A B X Y SP PC CCR

00 00 0000 0000 3C00 0400 90

00 00 0000 0000 2000 0403 90

00 00 0000 0000 1FFE 0427 90

00 00 0000 0000 1FFE 0429 90

00 00 0000 0000 1FFE 042C 90

0C 9C 0000 0000 1FFE 0450 90

0C 9C 0000 0000 1FFE 0456 90

0C 9C 0000 0000 1FFE 045C 90

0c 9c 0000 0000 2000 0405 90


Table 2.1 recorded register values

RTS
RTS (Return to subroutine) is an instruction which ​ returns the CPU from a subroutine to the part
of the program which initially called the subroutine. In this section, it is the last line of the
instruction that the registers that change are SP register and PC register. The RTS instruction will
pull the return address pointed by the SP register and then decrement by 2 as addresses are stored
as 2 bytes.

Debugging
After debugging the program by setting a breakpooint at the beginning of the subroutine and
using G 0400 to start the program, we found the bug that was initially “beq CDE_endif.” BEQ
instruction branches the PC if the first source register contents and the second source register
contents are equal. In this section, if the given code does not match with the actual code, it will
mark as valid even though it is not true. In order to fix this problem, the line was modified to
“bne CDE_endif” so that if the code does not match with the actual code, it does not interrupt
and continue to execute the code.

Conclusion
After debugging to observe and fix bugs from the code, we checked to see if the program
accepted any code as valid. Inputting different variations of code, we concluded that there was
no longer a bug and successfully debugged the system.
Part 3 -Developing the Delay Module
In part 2, we didn't have a delay module so it accepted any code as valid for arming and
disarming. The purpose of the delay module is to create delay in multiples of 1ms. This module
has multiple subroutines that needs to be implemented.

Design of the overall module


The overall module consists of six module and one of the being the main:

Alarm System Module:​ ​This module is the main routine that controls the overall software using
using subroutines provided in different modules.
Configure Module: This module provides a subroutine to configure codes.
Armed Module: This module provides subroutines to arm and disarm the alarm system.
Delay Module: This module provides subroutines to create delays in multiples of 1 ms. This is
the module that we implemented.
Debug 12 Module: This module is provided by firmware existing on the Dragon 12 Trainer. A
number of subroutines exist for accessing the terminal, setting breakpoints, and more.
Utilities Module: This module contains some general subroutines that can be used by any of the
other modules.

Design of setDelay/pollDelay
Figure 3 .1 Asm code for delay module

The structure of polldelay is that each time polldelay is called, it would delay for 1ms and
decrease the delaycount. When the delaycount reaches zero, polldelay would return True.
Conclusion
After implemented the delay module, we tested the assembly code and set the delayCount to a
random value. The output came out as a valid value which was the expected delay.

You might also like