Contents

Introduction

This paper is a review of my research to date into all areas relevant to my project. I have decided to look at all aspects topically as you can see above.
Since Deliverable 1 a few changes have been made following further research and discussion about the target audience for the software. It has been decided to change the direction of the project towards the 6800 microprocessor rather than the M68000. This is because only one class uses the M68000, but more classes use the 6800 as a learning tool, and therefore if a 6800 program could be produced it would be of greater use.
The timetable suggested has been adhered to quite successfully, only the non-functional GUI and questionnaire research has slipped due to unforeseen complexities. The revised timetable at the end of this document considers these facts, and provides a fresh, realistic set of targets to be met.

From the research so far it is becoming clear that the task in hand is a large one. The implications of this are just to reinforce what was outlined in Deliverable 1, which is to fully document all work done so that it is easy for all involved to understand. Another factor that is becoming more important is getting more input from a wide range of people about the functionality of the program. A software project is destined to fail if the programmer does not constantly revise his goals to ensure that they are the same goals that the user would set.

Section 1: von Neumann Architecture

The simplified layout of this computer is as shown:
 
 

 

The computer consists of four basic components; memory, a control unit, CPU (Central Processing Unit) and an I/O system. All these components are connected together by what are referred to as busses; a collection of wires connecting one component in the system to another.

(i) CPU

The central processing unit consists of an ALU (arithmetic logic unit) which carries out all logical and arithmetic computations, and a set of registers for the high-speed storage of temporary results.
This part of the computer is sometimes referred to as a register arithmetic logic unit.

(ii) Memory

The memory is used to store the program and all the data that may be required for the executing of the program, or generated by it. Memory can be thought of as a set of ‘n’ numbered registers indexed from 0 to n-1. Each index is referred to as an address.
Usually the program to be executed and the data are stored in different areas of memory.
The program is loaded in contiguous memory registers.

(iii) Control Unit

The control unit (CU) coordinates the CPU and the data flow to and from memory.
To give an illustration of the CU’s typical function:
In a running program the CU would go to memory and fetch the next instruction to be executed. It would then identify what the instruction was to do and set up the CPU to perform this function.
For example, say the instruction indicated that the number at the address indexed by address 30AAh was to be added to the number in a register within the CPU. The CU would set up the CPU’s adder so that the sources of the two arguments needed for addition were the CPU register, and the output of memory. Then the CU gives the memory the address of the required byte (30AAh) and waits for it to appear at the memory’s output.
The CU would then have the adder perform the operation on the two arguments and place the result in the desired output location.

(iv) I/O section

The input / output (I/O) is the section of the architecture which allows human interaction with the computer. Humans can enter data or operations and receive the results of computations through devices such as a keyboard, monitor and disk. Since the computer must know which devices it is to get information from and send information to each must have an associated address, just as each register in memory must have a separate address.

There is no reason why I/O must be thought of as separate from memory, as to the processor it looks like memory, which can be selectively read from and written to. Conceptually this is referred to as memory mapped I/O. The Von Neumann architecture modified to the memory-mapped version is shown in figure 2.
 
 

 

Section 2: M6800 Microprocessor

The microprocessor can be easily understood by breaking it down into sections.

(i) Accumulators A & B
These two separate registers store or manipulate one 8-bit (one-byte) word under program control.
(ii) Index Register
This is a 16-bit register that holds a memory address when using indexed addressing modes. The register can be either loaded, its contents manipulated, or it may be stored using the appropriate instructions.
(iii) Program Counter
The program counter is a 16-bit register that contains the address of the next byte of the instruction to be fetched from memory. When the current value of the program counter is placed on the address bus the program counter is updated.
(iv) Stack Pointer
The stack pointer is a 16-bit register that holds the starting address of sequential memory locations in RAM where the contents of the microprocessor’s registers may be stored or retrieved.
The contents of the registers are stored as follows:

SP Address Contents of PCL
SP Address -1 Contents of PCH
SP Address -2 Contents of IRL
SP Address -3 Contents of IRH
SP Address -4 Contents of A
SP Address -5 Contents of B
SP Address -6 Contents of CCR

This area of RAM is referred to as the ‘stack’. After the content of each register is stored on the stack, the SP is decremented. When the stack is unloaded the last register to go on the stack will be the first restored (last in, first out).

(v) Code Condition Register
This is an 8-bit register in which individual bits are set (to logic 1) or reset (to logic 0) as the result of executing an instruction as explained below.

 

Bit 0 – Carry/Borrow
For an arithmetic addition operation the Carry/Borrow condition code represents a carry, C=1 indicates that there is a carry and C-0 indicates no carry.
Bit 1 – Overflow
This bit is set when a two’s complement overflow results from an arithmetic operation.
Bit 2 – Zero
This bit is set if the result of any operation is zero.
Bit 3 – Negative
The negative bit is set if bit 7 of any operation is set to 1.
Bit 4 – Interrupt Mask
If this bit is set to 1 then IRQ interrupts are inhibited. This bit is set by an SEI instruction or by an interrupt occurring (NMI, IRQ or SWI) and is cleared with RIT or CCI instructions.
Bit 5 – Half Carry
The half carry bit is set during the execution of any of the instructions ABA, ADC, ADD if there is a carry bit from bit position 3 to bit position 4.
Bit 6 & Bit 7 – Permanently set to 1

The information in the CCR is the result of the last instruction that last modified it.
 

The 6800 addresses the system devices  (RAM, ROM, I/O) via its 16-bit address bus, and is therefore capable of addressing 216 unique memory locations in the range 0000h to FFFFh. The data bus in the 6800 is 8-bits wide.

System Timing

The control of the 6800 is achieved by using a symmetrical two-phase non-overlapping clock in conjunction with the control logic contained within the CPU.
 

The fetch and execute cycle

The first byte of a stored instruction is fetched from memory and loaded into the instruction register where it is decoded to select the operation to be executed.
An additional one or two bytes of the program may be required to be read into the MPU as determined by the decoded first byte, which is the case for two and three byte instructions. This fully retrieved instruction is then executed.

First cycle of operation
(i) On the first rising edge of ?1 (a) the contents of the program counter, e.g. 0100 is latched onto the address bus.
(ii) On the first falling edge of ?1 (b) the program counter will be incremented by one.
(iii) On the first rising edge of ?2 (c) the op code is placed on the data bus
(iv) On the following falling edge ?2 (d) the op code will be latched into the instruction register where it is decoded.

Second Cycle of operation
(i) At point (e) the content of the program counter (0101) is latched to the address bus
(ii) At point (f) the program counter will be incremented again (PC=0102)
(iii) At point (g) on ?2 the data (8Bh) is placed on the data bus
(iv) At point (h) on ?2 the data will have been latched into Accumulator A
 
 

Section 3: Java

“Java: A simple, object-oriented, distributed, interpreted, robust, secure, architecture neural, portable, high-performance, multithreaded, and dynamic language” (Sun Microsystems). This string of buzzwords is how Sun Microsystems aptly describe the language of Java.

Java was developed to be a simple language that was easy to learn. It borrows many constructs from C and C++ and therefore looks familiar to most programmers for ease of migration. At the same time many of C’s more bug prone aspects and features which lead to poor programming practices have been removed. Its object-oriented nature lets the programmer focus on the data in the application, and methods that manipulate that data, rather than thinking strictly in terms of functions or procedures. With Java’s distributed nature it is as easy to access remote objects on the Internet as it is to open local files.
The Java compiler generates “byte-codes” rather than native machine code. This architecture-neural object file format can be executed on any Java virtual machine. A Java virtual machine is the platform specific interpreter, which converts the byte-codes into native machine code for the specific platform and runs the program.

Java Abstract Windowing Toolkit (AWT)

Over and above these features and advantages Java offers the programmer a rich AWT (Abstract Windowing Toolkit) to produce high quality, platform independent graphical user interfaces. As it is designed to run on multiple platforms it cannot include all the features of a particular platform, but it has a common set of features that can be supported on most platforms. To cope with the need for additional features the AWT is extensible where the programmer can build custom GUI controls in Java and therefore be assured that they can be run on all platforms.

A layout manager is also available which controls how components look in a certain area on screen. If the programmer decided on absolute positions for all the objects on the screen the program may look fine under Windows and MacOS, but be unacceptable under UNIX. Furthermore, if the user resizes the container, or different system fonts are in use then the program may appear completely dissimilar to how the programmer intended.

For this reason a layout manager should be used if at all possible. Layout managers make it easier to adjust to platform dependant component appearances and different font appearances.

“Java offers the promise that the network will become the computer. If the Internet breaks down barriers, Java removes the last and most difficult of these: the barrier that prevents you from taking software from some random site and executing it on any platform.” (David Flanagan)
 
 

Section 4: GUI Development

4.1 Interactive System Design
(i) What are interactive systems?

Interactive systems are systems that support communication in both directions, i.e. user to computer, and automatic feedback from the computer to the user. The system should follow the users pace and direction. A good design should enable the user to do things faster, with fewer errors, with less prior learning, with greater resultant quality or perhaps just greater user satisfaction or fun.

(ii) Why design an interactive system?

Most interactive systems are commissioned in order to replace of enhance an obsolete or inadequate system. Another scenario is creating a system in order to solve a human problem or simply an opportunity for financial gain.
Throughout the development it is critical not to loose sight of the target application and/or users.

(iii) How can design success/failure be gauged?

Obviously, the best measure is how well the solution solves the original problem. To evaluate this the system must be graded on how well it supports people in their activities. If it enables people to perform better to a degree that justifies the cost then it is a success.
However, there is always a risk in designing a solution for a problem that the solution may partly fail users. Some failures can go unnoticed; an interactive system may have serious design flaws that undermine its usability, but its users will still manage to steer around these flaws and get their work done. Users will often gain satisfaction from their ability to devise workarounds for problems. On the other hand, if they cannot make a system work they are quite likely to attribute this to their own stupidity. A measure of this is how often phrases such as ‘its giving trouble today’, or ‘the system is down at present’ are heard among users of the system.

4.2 Graphical Design Points

(i) Layout
Before beginning a design, it is important to analyse the information that is to be conveyed, and to decide on the best communication method.

(ii) Structure of Information

In order to lay out elements effectively on screen you must first understand the structure of the information. Points to identify are as follows:
 

• Which items are of the same kind
• Which items are functionally related
• The order in which elements should be identified
• Hierarchy of importance; i.e. order items from most important to least important

(iii) Organising the Display

The basic idea is the visual organisation of the display will match the structure of the content.
Visual design involves deciding on many different factors such as object colour, size, shape, spacing, alignment and direction.
It is also important to separate different kinds of information, particularly active and inactive components. The most important items on the display should be visually emphasised in order to direct the attention of the viewer towards what matters most. It is also necessary to ensure that emphasis is not overdone. Only the most important items should be selected for this treatment. If too much is emphasised then the user will simply be baffled.

(iv) Colour

Although the use of colour is very effective, it should be used with care. Colour should complement a good layout, rather than compensate for a bad one. Colours should not be used in ways that contradict their traditional meaning, i.e. use red for danger, not to represent cold etc.

(v) Skeleton Layout

Before actually creating the screen layout it is useful to draught a skeleton layout. This drawing will be used for several different purposes.
This process can speed up the design process; time spent on a skeleton will be repaid later. Instead of having to make numerous individual decisions for each view, many of the components can be placed in predetermined areas.
The skeleton should include permanent features that remain on the screen for the duration of the program.

(vi) Animation

It is often a good idea to animate a small part of an otherwise static display. This clearly focuses the user’s attention on that part of the display, making it easy to gauge the program’s progress.

Section 5: Other Research

It is necessary to work with the user from the beginning to ensure that the final product satisfies real needs. The potential users must be probed for information and ideas that may not be obvious but will enhance the product. Ignoring this research may seem easier in the short term, but the final system will not be useful. This information will help apply some of the information gained on user interface design.

A questionnaire is “a device for securing answers to questions by using a form which the respondent fills in himself”.

This method of information gathering assumes that the respondent will give truthful answers. This requires the user to be both willing to complete the form, and they also need the ability to answer the questions. A questionnaire should be limited to asking for information that is not already available from other sources. Before even considering the format or questions it is necessary to define the exact information which the questionnaire is required to provide.

In designing a questionnaire a great deal of time must be spent in designing the questions. Each question should probe for specific information and be very clearly worded allowing no room for ambiguity. The designer should also try to think of sample responses to questions in order to think like the ‘customer’, and the final draught should be tested several times on people who are similar to those in the sample group, but not actually part of it.

Ideally the question sheet should be attractive to look at, brief, easy to understand and reasonably quick to complete. The upper limit for questions is suggested at 15-20. The designer should carefully avoid leading questions so as not to bias the received answers.
 

5.2 Other Simulators

During my research and reading I discovered a fellow student using a PIC simulator package – MPLAB. This is a windows based development system for PIC 16/17 microcontroller families. This product allows the user to:

• Debug source code
• Debug with breakpoints based on register values
• Watch the program flow with the simulator
• Measure timing
• View variables in watch windows

This system is obviously a highly commercial development tool that is above the level at which my project is intended to operate. However I feel that although there is not much I can learn from this program it will be useful to use as a reference throughout the development of my project.

Section 6: Timescale Revision

As mentioned in the introduction the timetable required some modifications. These have been completed as follows:
 
 

With these reviews, it should be possible to follow the timetable until the end of the semester, allowing the successful completion of the preparatory stage of the project. Progress will again be accessed in Deliverable 3, due in Week 12.
 

Section 7: Bibliography and Acknowledgements

The following are most of the books / material which I have referenced in my research so far. Titles, authors and library references are given.
 

Section 1: Von Neumann Architecture

Microprocessor System Design Fundamentals J Kenneth 004.16 BRE

Section 2: M6800 Microprocessor

Designing microprocessor Based Circuitry  SJ Cahill 621.38153 CAH
Introduction to 6800/6802 Microprocessor systems RJ Simpson & TS Terrell 4.165 DRI
The 6800 microprocessor    Jack Quinn 004.165 QUI
C for the Microprocessor Engineer   SJ Cahill  005.262 C CAH

Section 3: Java

Hooked on Java   Sun Microsystems  005.133 VAN
http://www.javasoft.com/  Sun Microsystems
The Java Tutorial   M Campoine & K Walrath 005.133 J CAM
Java with Borland C++  CH Pappas / WH Murray 005.133 J PAP
Java in a Nutshell   David Flanagan  005.133 J FLA

Section 4: GUI Development

Human computer interaction   Chartwell-Bratt  004.019 KIR

Section 5: Research

201 Principles of Software Development  Davis  005.1 DAV
Questionnaire Design Manual      1.4222 SOC
Using Questionnaires in small Scale Research P Munn  1.4222 MUN
MPLAB User’s Guide     MPLAB
 

Thanks

Many thanks to all those who have helped me out so far, from lending me books, to explaining abstract concepts, to giving me advise. I appreciate encouragement and criticism where appropriate, and hope all that have contributed so far will continue to do so.