CSCE 313 - Programming Assignment Deliverables Page

Instructions for what you and your team are required to turn in for programming assignments

Dr. James P. Davis -- Updated 26 March 2005
 

In CSCE 313, we carry out a number of lab assignments involving writing 68000 assembler code.  As part of this coding process, there is some amount of algorithm design and conceptualization that is done first (that is, if you are following a methodical process for creating a program).  Usually, we either write pseudo-code or we use flowcharts.  I prefer to use flowcharts, as these convey much more information than textual pseudo-code; also, there's research published in IEEE Computer back in the 1990s that reported the productivity advantages of using flowcharts over pseudo-code.

In our lab work, we'll use the Windows Notepad(R) (the easiest solution) to edit our software programs, and then either WISM68 or the M68KMB tools to assemble, link/load and execute the programs. You'll use the Debugging Form in this lab to work each of the problems out by hand, then enter them. You'll turn in the Debugging sheets, as well as screen shots of the Registers and Memory locations--before and after execution.

The deliverables for this assignment include the following:

(1) Analysis flowchart of the program's algorithm, indicating pseudo-code for the program's computing operations. If you have access to a drawing package, just create the flowchart and copy/paste it into the Word file along with your report (screen shots, debugging steps for the particular Lab, etc.)  If you don't have access to a drawing package such as Visio (which should be available on the PCs in 1D11, 1D15, and 1D25), then neatly draw out the flowchart by hand and turn in on a separate piece of paper.  Why do I ask you to do this?  Because, I want you to follow a methodical and thoughtful process for constructing your programs!  Please, don't just slap a bunch of code together; you won't get the insights into the process of constructing software in the same manner as when you fully conceptualize your algorithm and subject it to "thought experiments" before actually writing the assembler code; plus, you'll find many of your "dumb bugs" in your algorithm earlier in the process.  Construct the flowchart first before writing the code!  Believe me, it will save you time!

(2) 68K source file (.asm for WISM68, or .h68 for 68KMB);

(3) 68K assembled listing file (.lst), only if you are using WISM68 (not required for 68KMB-based labs);

(4) Test Planning Worksheet or Program Debugging Worksheet: the first worksheet is used to define your testing plan by enumerating all of the test cases you will use to test your program.  Each sheet has place for 4 test scenarios.  You should plan on at least running 4 such scenarios.  I will give extra points if you subject your program to a higher level of testing than this minimum standard.  I will award points for creativity in coming up with test data sets, and in how reasonable the test plan is (in terms of representative test coverage).

Test Planning Worksheet:  PDF version, MS-Word version.   Note that in CSCE 313, we use the "Elapsed Cycle Time" field to indicate how many CPU instructions into the execution of the 68K assembler program that we expect to see the expected result of our test case (whether in terms of WISM68 register or memory results, or 68KMB add-on board LEDs).  When testing a program (or a hardware design), the timing of execution is just as important, if not more so, as correct functionality.  In real-time embedded systems, it is more critical, because programs that execute and deliver results too slowly can cause system failure!  Why do I ask you to do this?  Because, I want you to understand the importance of methodical and rigorous testing your programs! Program testing typically consumes 60% of the development lifecycle on most projects in industry.  Good testing skills are critical to your success as a computer/software engineer.

Program Debugging Worksheet: PDF version, MS-Word version.  We used the Debugging Worksheet in MacKenzie's Lab #5, and we use it again on one of the later labs.  If you are working a lab that requires using the MacKenzie worksheet, then you don't have to turn in test case designs on my Test Planning Worksheet (unless you want to impress me). 

By making extensive use (i.e., more than minimal required use) of the Test Planning Worksheet, you are eligible obtain up to 15 extra points in overall lab scoring.  You go the "extra mile" in this learning experience, I'll give you the points as reward and incentive to get everything you can out of this learning opportunity!  But note, you have to use the testing tools and methods correctly to get the extra points.

(5) Execution screen shots embedded (copy/pasted) into a MS-Word document, showing before and after for the Registers window and the Memory window for the WISM68 simulator program, when you are using WISM68; and,

(6) Any lab materials that are required for submission on the MacKenzie Lab on which your team is working.

NOTE: Currently, as of this version of the Assignment Deliverables page, there is no printer connected in the 2A16 lab.  So, bring your USB thumb drive or floppy disk, so that you can copy and print from the main 1Dxx lab printers on the ENGR network.

*** Notepad is a registered trademark of Microsoft Corporation.