Projects are designed to test your mastery of course material as well as your programming skills; think of them as “take-home exams” and don’t communicate with anyone about possible solutions. This project focuses on hacking 6502 assembly code using the excellent Easy6502 simulator.
For most problems we provide starter code on Piazza that you are expected to use. Do not modify the starter code too much, you’ll run the risk of failing our test cases that way! Just focus on the subroutine you need to write for a given problem, make all of your changes there.
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 very 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
Make sure you take the time to understand how that flag influences the
execution of the basic
(If reading the manuals doesn’t help you figure it out, just write some simple
example code and try it out using the simulator!)
Add the necessary subroutines to the file
thirtytwo.s of course!
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 those 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.
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! How cool is that?
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 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.)
Add the necessary subroutine to the file
sorting.s of course!
(If you choose to improve the animation code as well, please clearly note that
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] and
[9 7 2 1]!
This is a challenge problem only! It’s worth exactly nothing in terms of your grade and it’s a lot of work. So you probably don’t want to do it and that’s perfectly fine. (Having said that, doing the problem is a lot of fun and it’s extremely rewarding to finally see it run! 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 and several other published versions for the 6502, so if you’re thinking of simply copying it, please 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 Piazza. Make sure that your tarball contains no derived files whatsoever (i.e. no object files, no executable files, etc.), but allows building all required derived files. Make sure to include a Makefile that sets the appropriate compiler flags as detailed on Piazza and builds all programs by default.
Include a plain text
README.docx or whatnot) that briefly explains what
your programs do and contains any other notes you want us to check out before
Your answers to written problems should be in your
README file as well!
Make sure to include explanatory notes and detailed derivations that
tell us how you solved the problem in question (and convince us that you really
did the work).
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 projects.
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 projects on Piazza.
Style refers to both programming and presentation style.
Programming style includes things like consistent indentation, appropriate
identifier names, useful comments, suitable documentation, etc.
Style also includes proper modularization of your code (into functions,
modules, etc.), proper use of
Simple, clean, readable code is what you should be aiming for.
For C (and, if allowed, C++) programs, make sure you follow the style guide
posted on Piazza!
Presentation style refers to your
README file and (possibly!) your PDF files
Your presentation should be clear, structured problem-by-problem, broken into
sections (and paragraphs!) as appropriate.
Lines should be at most 80 characters in length, broken by UNIX linefeeds.
(You may use Markdown format if you so choose, but everything must still be
perfectly readable without rendering Markdown to another format.)
Diagrams should be clearly labeled, cleanly layed out, and generally a
pleasure to look at.
Performance refers to how fast/with how little memory your programs or circuits can produce the required results compared to other submissions.
Functionality refers to your programs or circuits 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, beyond programming or circuit design!)
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 case).