Assignment:
A popular screensaver from the past used to plot an animated "worm" on the
the screen. If you constrain yourself to the ASCII display of the Hawk, this
such a worm might look like the following:
* * *
* *
* *
* * *
You should recognize this assignment. The worm is the exact same worm
that was assigned for MP4. The behavior of the worm should be exactly
the same, including all elements of worm length, randomness and worm
termination.
The difference in this assignment is that the worm implementation may not
use the Hawk monitor to draw on the screen. Specifically, use of PUTAT
and PUTCHAR are forbidden. As a result, you will need to write
your own code to directly access the Hawk's video RAM in order to plot your
worm on the screen.
Since you have direct access to the video RAM, the collision detection logic
in the worm can be greatly simplified. In the old worm, detecting collisions
with itself required making 10 sets of coordinate comparisons -- with every
cell in the worm. Now, with direct access to the video RAM, you can simply
inspect a cell of the video RAM to see if it contains a blank or an asterisk.
Requirements:
-
Your source file must be titled with mp5.a and your name.
Failure to follow this requirement will result in your assignment being
ignored. We, the instructor and teaching assistants, will not engage in
detective work to determine who to credit with an assignment.
-
If you opt to base your code on someone else's solution to MP4, you may
do so on the condition that the comments immediately after the TITLE
directive give credit to the original author.
-
You must use the on-line coursework submission tools, as you did form MP1,
submitting the file mp3.a
for the course c_060 in the submission directory mp4.
-
When we test your code, we will do so
with a modified version of the Hawk monitor that includes multiply and
divide support but has no support for output to the screen. That means that
you may not use PUTCHAR, PUTS or any of the other output
routines in the Hawk monitor.
-
Your code must be well formatted and readable. This means approprite use
of tabs and other forms of whitespace andappropriate names for labels that
are suggestive of the program structure. Use subtitles to divide up the major
subsystems of your solution within your source file.
-
Your code must be well commented. This is not merely a matter of writing lots
of comments, but a matter of comments that motivate and explain the code.
Comments that merely restate what each instruction does are bad.
-
Your code must make appropriate use of subroutines, where any and all
activation records and parameters must be clearly documented, and where
subroutines should be clearly set off from each other by appropriate
comments and or subtitles.
-
For full credit, your collision detection logic must be based on directly
inspecting the video RAM.
Grading
As mentioned above,
the assignment number mp5 and your name must appear on the title
of the listing. In addition, the file name of the file you submit must
be mp4.a. No upper case, no alternatives.
-
If your output is correct and your program runs without error and terminates
norally, you will earn 2.5 points.
-
An additional 2.5 points depend on the structure of your code.
Demerits of up to 1/2 point will be assessed for
irregular or nonstandard indenting, for excessive or inadequate white
space, for poor choice of identifiers (such things as labels), inappropriate
use of subroutines, and for disorderly code.
Notes
If you ask for help debugging your code, your code must be well commented.
We will not look at "naked" assembly code with no comments to suggest what
it is intended to do, and when we find poor comments or discrepancies between
the comments and the code, we may ask you to fix those before we look at the
code in any detail.
Of course, if you ask for help with the comments themselves, we will be glad
to offer suggestions.