Deliverable 3

 
 
 

Section 1: Introduction

This report is the culmination of the project work this semester. The aim of this document is to report the continuing work, and to identify blocks of the final program so that work can begin immediately at the start of semester 2.
 

Structure of this Report

This report is divided into three sections. Firstly two commercially available M6800 simulators are critically appraised, and suggestions drawn from this appraisal. Secondly these ideas, in conjunction with other ideas, as discussed in deliverables one and two will be applied to this project. Finally a further insight into the development of the questionnaire is given.
 

 Section 2: Other M6800 Simulators

Since the literature review (week 7) further research has been carried out into all aspects of the project. Two Internet sites were found who offered 6800 simulators. As these people have already undertaken a similar project it is important to examine their solutions, and draw conclusions on their good and bad points.
 

(i) Motorola M6800 Microprocessor Graphical Simulator (V 2.0) by Steve Scott

In order to give a fair appraisal it is necessary to understand both why the simulator was written, and who its target audience are. Steve Scotts program is aimed to be used as an “educational tool to help the user understand the cycle by cycle operation of the M6800 Microprocessor.” It is implemented as a DOS program and gives a good illustration of
the microprocessor blocks, all connected by single line busses as shown below.

As can be seen there are several control windows at the top allowing all the available options to be set. The main window is called “MPU-CONTROL” from which all other windows can be accessed via keystrokes.

Other windows are listed, including a brief description of their function: -
 

This is a good graphical program that achieves what has been set out in its original specification. It could have been made much more user friendly, but it could still be a useful tool as it is. Below are listed a few points which may be taken into consideration in this project:
 

     Good Features
 

      Bad Features
  This program is good for people who know machine code, and need to see it executing. Given its complexity it is no good for a student to use – it is too difficult to operate and its disadvantages outweigh its advantages.

For the duration of this project it will be good to have this as a reference tool.

This will be useful in testing the evolving solution to ensure that the outputs are right for given inputs. Further information including a free copy can be obtained from http://www.engr.uark.edu/~sss/sim6800.html.
 
 
 

(ii) Sim6800 – Motorola 6800 Simulator

This is a windows based program aimed at a commercial market for educational institutions to aid teaching how to program in machine code. It is suggested in the documentation that it can be used by lecturers “to easily verify students programs” submitted via email or floppy disk.

As this is a windows application there are several options not displayed on screen, but they  can be called up in separate windows. The main window (as shown below) is a spreadsheet like area that shows the current address in HEX, the value of that location, the instruction, and the comment against the associated instruction.
 

 

Below this several other areas of the screen are dedicated to providing information, which include:

Register Display: Shows accumulators A and B, the index register, stack pointer, and    code condition register, all in HEX values
CCR:   Displays the current contents of the code Condition Register as     individual flags
Instruction Information: Shows the current instruction, size, current address, and the     addressing mode
I/O port: Allows specific memory addresses to be used as input/output ports, receiving information from eight switches, and giving a visual output using eight LED’s
Watch Window: Allows user definable watches to be section memory addresses
Run Delay  Sets the length of time that will elapse between the execution of     each instruction

This is a good program, and certainly excellent at the task it was written to perform, although it would be better at serving the lecturers needs than that of the students.

The main points to note are:

     Good Features
 

     Bad Features
  This would have been an excellent solution to this project if it had shown the CPU internal blocks, and their interactions as graphical blocks. However the trace option will be very useful in the construction of this project to check the correct operation of the internal blocks of the microprocessor. This shows all changes in internal values, and a screenshot is included below.
 

One major disadvantage of this software is that it costs $60 per copy, whereas the solution in part (i) is free. For more information on this product including an evaluation copy visit http://www.iinet.net.au/~circuit/sim6800/sim6800.html.
 

All these points will be taken into consideration in this project, learning from the faults in other software, and adding other useful features.
 

 Section 3: Display Layout

There are two vital aspects to the success of this software project: --
 
  1.  The operation and functionality of the program
  2.  The usability of the software and ease of interaction
In semester two the programming will be started, and completed, to satisfy the first point. Before this can be attempted, it is necessary to design a highly usable interface.

Having thoroughly researched the subject of GUI design in deliverable two (section 4) it is now time to apply the theory to this project.
 

3.1: Specification

Before the actual implementation is discussed the specification of what is required must be clarified. This is completed in several components below.
 

Screen Size

Before any actual design begins it should be remembered that this program should operate any commonly used screen resolution. For this reason 640x480 resolution will be targeted, as this is the minimum general size. If a user was using this size of screen the browser window would have to allow as much area as possible to the program (Netscape running in ‘Kiosk’ mode for example). For a user with an 800x600 or 1024x768 resolution screen, the applet should load well within their browser window. Most importantly, the room in which the program is designed to be used uses 800x600 resolution, so this will be a good size to optimize for.

The program will be designed using vector graphics where possible so that it is resizable, but it is still necessary to ensure that it will resize to a comfortable viewing area. Using vector graphics will also yield the advantage that screen redraws are much faster than using bitmap graphics.

The next design step is to decide which components will be displayed on the screen, and where they should go.
 

The Microprocessor

In deliverable two the block diagram of the microprocessor was presented (Page 7, Figure 3). Given the constraints set out above concerning available screen size, certain components must be displayed and to others omitted.

The most important components are the Program Counter, Accumulators A and B, and the Instruction Register. The contents of the Code Condition Register (CCR) should also be displayed.

     The Program Counter will allow the user to see it being loaded with the value of the next memory location to be addressed, whether it is a simple increment, or a more complex branch instruction.
     Accumulators A and B will allow the user to see the data operations as specified in the program being carried out.
     The Instruction Register will show the current instruction allowing easy reading of the microprocessors contents and status.
The CCR will also be shown to allow the user to see which flags have been changed as the instructions are executed.

Although for basic programs these are the most important components, it may also be viable to show the Stack Pointer and Index Register for the users convenience. Space will be left for these in the design, but depending on how timescales progress there may not be time to implement them.

The Address and Data buffers will also be shown as they are an integral part of the fetch and execute cycle.
 

Menu Options/Control Panel

As the final program is to be implemented as a Java Applet, rather than an application a standard application menu bar cannot be used. This means that there must be a section of screen set aside for start/stop commands etc. These should be clear and easy to use. They may also include controls to set options, such as run speed.
 

Program Display

As the user steps through, or runs the program the current source code line being executed should be shown with a few lines before and after it to allow the context to be ascertained.
 

Memory Viewer

As the object of this project is to show the user the details of the fetch and execute cycle, it is imperative to have a good view of the memory currently being accessed. I could propose that this area should show at least three memory locations in detail, which will allow the longest instruction (three locations) to be completely displayed at one time. I will propose that, if possible, this will show at least seven memory locations to allow at least two full instructions and the next memory location.
 

3.2: Implementation Details

Now that I have looked at what I think is necessary, I will specify ideas for the implementation of each block of the display.
 

The Microprocessor

Each block of the microprocessor should be clearly marked so that at a glance the user can see exactly the information required. An example of this is shown below (a).
 
 
 
 
 
 A further idea is to show the previous value of the block contents, and also to highlight all data that has changed within the last step by changing its colour. This is shown in part (b) above.

Each of the blocks specified should be designed with this approach to maintain consistency throughout the program.

There are several possible implementations of the interconnections between the blocks. These should be ‘animated’ in some form to indicate activity. One option is to have a single thick line between the blocks. This suggestion could be animated in two ways:

It would be possible to simply change the colour of the area of the bus along which the data was travelling. This is shown below

This would be an easy solution. A more effective solution, but harder to program would be to show an animation of a colored block travelling along the bus. A snapshot of such a solution is given below.

 
The other is to show each wire in each buss as pixel wide lines. As data is transferred, the same animation methods could be employed. Rather than all the lines, bright only ones with logic ‘1’ or ‘0’ will be active. For example, all unused areas of the bus system could be coloured gray, and the lines at logic ‘1’ would be white, and the lines at logic ‘0’ would be black.
 

Program Display

There should be enough of the currently running programs’ source code displayed to show the user clearly where the execution of the program has reached. This will involve a quite sophisticated assembly process, although if the structure is thought out carefully enough then it could be relatively simple.
 
  1. Several steps must be completed during the assembly of the users input file:
  2.  A first pass must be made to record symbols and their position within the program
  3.  A syntax check (probably in the first pass) will insure that no illegal or unimplemented commands have been used
  4.  During the second pass machine code will not be produced, as in a normal assembler, but a data structure containing several ields for each line of source code will be constructed. This will be exactly specified next semester, as it depends heavily on the actual structure and operation of the program. However certain generic fields will be necessary, for example:
  5.  Instruction -hold the instruction for processing
  6.  Comment -store the comment for display upon ‘execution’
  7.  Memory address –remember how far the program has got so far
This data will then be ‘executed’ on the simulator, being loaded into the Current Program window, and simulated on the machine.
 

Program Control Options

This is a component that will depend heavily on how complex the operations that the program offers become. For now it should include options such as:
  There may be many more options such as ‘help’ required, but currently the above are the necessary ones, others can be added later.
 

Memory View Implementation

The original proposed solution to this is to show memory in a line as one location after another, as shown below:
 
 

As the program progresses this area will be animated to scroll along, moving quite slowly between locations, but moving quickly to change from data to program memory.

This solution is fine if the user knows what to expect, but because the user level at whom this project is aimed is beginners this method may dazzle and confuse them. As was noted in deliverable two if too much happens too quickly on the screen the user will simply be baffled as to what has just happened. For this reason it may be practical to implement two views of memory- one showing program memory, and the other data memory. The benefit of this would be that less movement would be required.

It will be necessary to show the data and address buffers receiving information form memory. This will be achieved using whatever bus linkage method is chosen for internal microprocessor movement. It will therefore be required to have the data and address buffers adjacent to the memory area.
 

Overall Implementation

Now that each basic suggested block has been discussed in detail it is necessary to decide where it will be positioned on the screen.

The microprocessor, being fundamental, should be in the centre or as close to the centre as possible to focus maximum attention on that area. On page x.x my original draft of the layout shows the menu at the side and the program at the bottom. The memory inspector is also given a prominent position at the top. On page x.x a computer model of this layout is shown.

Upon discussion of this model with my tutor, a few modifications were recommended, and these are drafted on page x.x. As the program display only used half of the area available it was suggested that this waste space be used for an extra component, giving a second view of memory. This view would be a less detailed view of a large area of memory. These two boxes were also moved to the top, emphasizing the view of the current source file being executed. The memory overview section will include a grid of up to twenty memory locations (4x5), or possibly even more, depending on available space, to allow the user to easily see what is in those locations. Another idea for an addition is to use a smaller grid, giving more locations in conjunction with a magnifying routine, so that when the user holds the mouse over this area it would be shown in greater detail. A demonstration of a possible implementation of this is shown below:
 

 

In the revised solution the number of memory locations shown in the memory inspector has been increased to allow a larger view.

To give an idea of the operation of the complete system an example of an instructions execution is described.

Let us assume that the current program is at 001B, and the Program Counter (PC) has just been incremented. The PC will be seen to change to 001C, and this address will be loaded into the address buffer. Simultaneously the line of execution in the program view window will move to the next instruction. The memory inspector will scroll along one position and lines will appear connecting the contents of the memory location 001C to the data buffer. Simultaneously to the scroll in the memory inspector the memory overview will also change to 001C. The data will then be transferred through the data buffer into the Instruction Register (IR). Let the instruction be to load the contents of memory location 0101 into Accumulator A. The address 0101 will be shown loading into the address buffer, and then the memory inspector, and the memory overview will scroll to the location 0101. The data will then travel from memory through the data buffer into Accumulator A.

This is a typical instruction execution.

These suggestions all comply with the suggestions in section 4.2 of deliverable two which relates to the theory of graphical design. It is important to refer to this section often to be reminded about the control that should be exercised over the use of colours and other design considerations that if applied incorrectly would make the project look incorrect.
 

Section 3: Questionnaire

As was the case in deliverable two the progress of the questionnaire has again run over time. There are several reasons for this, which will be outlined in the process of explaining the work so far.

In deliverable two, section 5.1 it was noted that questionnaires are an absolute waste of time unless properly constructed. It is necessary to spend a lot of time organizing the questions and ensuring that the data which is obtained is understandable and that it can be relatively easily analyzed. This is part of the reason as to why the questionnaire hasn’t been used yet.

The original idea for the questionnaire was to have a proposed solution to the problem; either a working model on a computer and ask questions based around that. As time moved on and iterations of the design process took longer and longer it became clear that a functional model would be too time consuming to justify itself. Having spent time doing this a layout has now been developed (Page xx) which allows the questionnaire to be constructed.

The format of the questionnaire would consist of several questions before the students see the solution, and then upon seeing it they would answer several more.

The real issue is that the questions required may need to be open-ended to allow flexibility in the answers. Students will be reluctant to spend time writing or drawing answers to open-ended questions, so to overcome this a simple computer program will be written to allow quick and easy answers to questions. Another spin-off might be that because of the novelty of doing a questionnaire on a computer the students may be more willing to participate. However one consideration is that new students may not be familiar with text boxes, or check boxes which will be used, so it would be necessary for the person conducting the questionnaire to give a short explanation of the method used. It may be useful to have an example question at the start to show that the user understands.
 

What Questions?

To determine what questions should be asked it is necessary to specify what information is required. The purpose of the questionnaire is to:
 
  1.  Ensure that the students believe that this software would be useful
  2.  Let the users choose their favorite one of several solutions presented to them.
It is also an opportunity for the student to give any suggestions which may be useful; it is possible that the students could suggest something that has been overlooked.

In order to ascertain useful information relating to these points the following question structure will be used:
 

  1.  The student would be asked about how well the feel that they understand the microprocessor architecture. This will help to gauge whether the student is weak or confident in the subject. More emphasis may be put on the opinions of weak students in order to help them gain an understanding of the subject, although suggestions would be welcomed from strong students
  2.  Next the student would be asked if they felt that is was easy to gain an understanding of the microprocessor using the current methods, e.g. textbooks, simulators etc.
  3.  The above question would be a lead in to another question asking if a graphical view of their programs executing on the microprocessor would help their understanding
On completion of this section a selection of two or three pictures of suggested layouts would come onto the screen.
 
  1.  The user would then be asked to identify different parts of the system to find out how easily understandable the solution is.
  2.  Next the student would be questioned as to the potential usefulness of such a tool
  3.  Finally another fully open question would ask for feedback on how the system could be improved
 

These questions are the proposal from which the draft questionnaire will be constructed, which will have to be asked to a small sample group, refined and then asked to the real group.

Obviously to write this questionnaire the proposed layout had to be completed, and unfortunately it was not possible to do this before week 11, which left an impractical amount of time to complete the questionnaire.

Bearing these things in mind the questionnaire will be used as a tool next semester so that feedback can be received during the first few weeks to ensure that pointless goals which are not pursued. If possible the class sampled will be used to give me feedback at several points during the project, as this is an important part of any software development.