The fourth assignment is all about hacking 6502 assembly code using the excellent Easy6502 simulator. For most problems we give you a bunch of starter code on Piazza already, so all you have to do is fill in one or two subroutines in the way described below (and in the code itself, be sure to read it for all the gory details). Still, working in 6502 assembly is bound to bend your mind, so enjoy! And don’t wait too long to start, you’ll have to master a new language and that’ll take time!
The 6502 is an 8-bit processor (albeit with a 16-bit address space) so it can only do arithmetic on 8-bit quantities. For this problem you need to write two subroutines that can perform 32-bit addition and subtraction.
Once you understand how the
SBC instructions work that’s
actually not too complicated, essentially you just need to do four
“small” 8-bit operations to get the desired 32-bit operation. Of course
the proverbial devil is in the details, specifically the carry (or
“borrow”) flag. Make sure you take the time to understand how that flag
influences the execution of the basic
Your job? Add the necessary subroutines to the file
README should probably discuss the
instructions and what the implication of those instructions for subroutines
like these is.
The Easy6502 simulator comes with limited graphics capabilities. However, you cannot simply set a pixel at a certain (x, y) coordinate to a certain color, instead you have to figure out where in memory that pixel actually lives. That’s tedious!
So for this problem you’ll write a subroutine that performs the tedious calculations automatically. The details are in the starter code, but essentially you’ll have to figure out how you can translate a certain (x, y) coordinate into the correct memory address to get the nice animation we showed you in lecture. And just to be clear: (0, 0) is the pixel in the top-left corner whereas (31, 31) is the pixel in the bottom-right corner.
Your job? Add the necessary subroutine to the file
plot.s of course!
BTW, Peter’s best solution takes about 40 cycles to plot a point; how
many cycles do you need?
Sorting is always a popular programming problem, and now it’s time to hack a sorting algorithm in 6502 assembly. But don’t worry, this is not going to be boring at all! The starter code for this problem has everything you need to animate the sorting process!
All you have to do is decide on a simple sorting algorithm based on swapping array elements and then implement it for the 6502. We recommend bubble sort or selection sort, but you’re of course welcome to try insertion sort as well; your choice!
Note that you may get a little tired of just how slow the animation is (especially while you debug your code). There’s a comment in the starter code that gives a hint as to why it’s so slow. If you’re excited about 6502 assembly, why not go ahead and fix that inefficiency? (Warning: That’s a good bit harder than just writing the sorting algorithm.)
Your job? Add the necessary subroutine to the file
course! (If you choose to improve the animation code as well, please
clearly note that in your
README file and describe how you did it.)
Important: Your code must sort the array in ascending order! For
example, if the original array is
[7 2 9 1] (from the lowest to the
highest memory address) then the sorted array should be
[1 2 7 9].
This is the challenge problem for the assignment. Note that it’s worth exactly nothing in terms of your grade, but it’s a lot of work. (Doing the problem is extremely rewarding, but since it’s way out there in terms of complexity we didn’t want to force everybody to do it.)
Your job? Implement a graphical (that is animated!) version of Conway’s Game of Life! It’s up to you whether you start with a random configuration or a specific “famous” pattern, but the entire 32 x 32 pixel screen should be used.
Please note that we are well aware of this version and several other published versions for the 6502, so if you’re thinking of copying it, think again. (If you’re handing in code that’s ripped off from elsewhere, you’re cheating regardless of whether you get credit or not. Please don’t cheat?)
Please follow the submission instructions as detailed on
Make sure that your tarball
contains no derived files whatsoever (i.e. no executable files), but
allows building all required derived files.
Also, be sure to include a Makefile that sets the appropriate
compiler flags and builds all programs by default.
Include a plain text
README file that briefly explains what your programs
do and contains any other notes you want us to check out before grading;
your answers to written problems should be in this file as well.
Finally, make sure to include your name and email address in every file
you turn in (well, in every file for which it makes sense to do so anyway)!
For reference, here is a short explanation of the grading criteria; some of the criteria don’t apply to all problems, and not all of the criteria are used on all assignments.
Packaging refers to the proper organization of the stuff you hand in, following both the guidelines for Deliverables above as well as the general submission instructions for assignments on Piazza.
Style refers to C programming style, including things like consistent indentation, appropriate identifier names, useful comments, suitable documentation, etc. Simple, clean, readable code is what you should be aiming for. Make sure you follow the style guide posted on Piazza!
Design refers to proper modularization (functions, modules, etc.) and an appropriate choice of algorithms and data structures.
Performance refers to how fast/with how little memory your programs can produce the required results compared to other submissions.
Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous, ask for clarification! (It also refers to you simply doing the required work, which may not be programming alone.)
If your programs cannot be built you will get no points whatsoever.
If your programs cannot be built without warnings using the required
compiler options given on Piazza we will take off 10%
(except if you document a very good reason).
If your programs cannot be built using
make we will take off 10%.
valgrind detects memory errors in your programs, we will take off 10%.
If your programs fail miserably even once, i.e. terminate with an
exception of any kind or dump core, we will take off 10% (for each such