To immerse yourself in relevant and important aspects the nature of the CPU, the C-assembly-machine code connection, and getting to play with all of it under the guise of a simple system.

Each week, throughout the semester, the aim will be to focus on various activities related to implementing some functionality for NES ROMs (to be run in an emulator):

• reading through a tutorial, web page, howto, or other technical documentation
• discussing the content (in the class discord)
• experimenting/playing with the content in your own code
• no warnings, syntax errors, logical errors, or runtime errors (if there are assembler/compiler flags to issue, they should be clearly documented in the code/utilized in Makefile)

The overall aim is to enable you to challenge yourself, explore areas and concepts you are not familiar with, and grow as a programmer and problem solver. I don't want to see you just doing things the way you are familiar with (simply because you've always done them that way).

The outline of semester progress:

Also be sure to peruse the other posts at: https://timcheeseman.com/nesdev/

Now that we have established a level of functionality using the existing set of tools, we have a choice to make. And this choice can be made individually:

• learn 6502 assembly and recreate the ROMs made so far by writing them in assembly (do NOT just use compiler output)
• start work on a larger, more involved NES game

The cadence for the assembly approach is pretty straightforward: we've pretty much implemented a thing a week. You'd pursue the same for that sequence of accomplishments.

As for the NES game effort, clearly you wouldn't be expected to produce something complete in the course of a week, so instead, I would like a snapshot:

• what have you done, what is working, what isn't
• custom tiles for character ROM
• any working/semi-working ROMs showcasing accomplished functionality (even if later broken)

We'll cap off the semester with a more involved NES game, which could be a further modification/evolution of whatever work you've done already, or an opportunity to start anew. We'll do this through to the end.

I will also open things up to the possibility of working in groups (no more than 3!), provided each person has an awareness of all aspects of the code, and equally participates in the development effort. Documentation/comments/snapshots will be important, demonstrating you are keeping at the task.

TOTAL:nesX:final tally of results (TOTAL/TOTAL)
*:nesX:assimilate indicated and related content [PTS/PTS]
*:nesX:asked, responded, worked through any questions [PTS/PTS]
*:nesX:reveal of interesting insight, knowledge gained [PTS/PTS]
*:nesX:discussion regarding content, related resources [PTS/PTS]
*:nesX:experimentation, playing, reporting insights gained [PTS/PTS]
*:nesX:state what your code is going to do [PTS/PTS]
*:nesX:implementation of example or your own variant [PTS/PTS]
*:nesX:contribute content to class notes page [PTS/PTS]
*:nesX:no warnings, compiler notes for code [PTS/PTS]
*:nesX:no syntax errors in code [PTS/PTS]
*:nesX:no logical errors in code [PTS/PTS]
*:nesX:no runtime errors for code [PTS/PTS]
*:nesX:submitted code aligns with intent, author statement [PTS/PTS]

Additionally:

• Solutions not abiding by spirit of project will be subject to a 25% overall deduction
• Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
• Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction
• Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction