Austin's Blog

As the term is winding down, I’d like to discuss the most difficult challenge of my team’s NES Emulator project. For me, the most difficult part was managing the time I spent on the project. Some weeks, I spent too much time on the project — many times the ten-hour minimum requirement. Other weeks, I struggled to meet the ten-hour requirement.

While time management was an issue, luckily I had a great team to work with. We held each other accountable, while also encouraging each other. As teammates, we kept each other on track. While we did have some challenges, we were able to overcome them. Assigning specific tasks on our kanban board was very helpful.

My favorite technology that we have used on our project is GitHub Actions. Utilizing GitHub Actions has been very useful, and has become an essential part of our workflow that we all interact with. Without these tools, our code quality standards would be much harder to enforce.

For our team, one of the most important features provided by GitHub Actions is the ability to run specific workflows on a pull request. We have specific and strict code formatting and linting guidelines, and utilize GitHub Actions to ensure a PR meets all of these requirements. The workflow checks for any changes to source code files, and if any exist runs our linting and formatting tools. If the guidelines aren’t met, the pull request is rejected. These all run utilizing a custom Docker container we built.

Initially, we used a bot to make linting and formatting recommendations, but when a developer accepted the changes, it would kick off a new workflow run for every change accepted. This was inefficient and could be costly, so we removed this feature. You can instead perform linting and formatting locally automatically (for most changes) using a Docker container. This was implemented to reduce the number of billable minutes used by our project in GitHub Actions.

Our Actions workflow also builds the project, to ensure that the code actually compiles and builds. While developers should build locally, mistakes happen and this tool has caught issues that may have been missed otherwise. I have recently implemented automated runs of a test ROM as well, which will be useful for catching any CPU opcode regressions.

For this blog post assignment, I’ve read two articles — one which discusses clean code, and another that discusses common “code smells.”

Both articles were excellent. The article on common code smells from Pragmatic Ways seemed to be heavily inspired by the book The Pragmatic Programmer, which I also found to be very informative. While some ideas presented by these articles were review, others were new to me. In this post, I’ll discuss a couple of the concepts I’d like to apply in my code in the future.

One thing I’d like to do more often that was mentioned in both articles was limiting the number of parameters defined for a function. I sometimes find myself with unwieldy functions that, while only serving one person, accept 4 or more arguments. Instead, related arguments could be grouped together into an object to be passed in. See the following function signatures for examples:

def register_user(first_name: str, last_name: str, employment_date: datetime.date) -> None

vs.

def register_user(user_information: dict) -> None

The second example is easier to understand, less complex, and is also expandable in the future — what if the user’s position in the company needs to be added later? In the first case, the function signature and possibly any calls to it will need to be modified, but in the second only the data only needs to be added to the user_information dictionary.

One thing that I’d like to avoid are useless comments. I regularly find myself writing comments about “how” something works instead of “why” it exists. Clean code with clearly named variables, functions, classes, and methods will describe the “how” on their own. In the future, I’d like to avoid writing comments like this.

This term, our team completed the CPU and memory bus portions of our NES emulator. We also have approximately 10,000 tests per instruction running and passing! We even had time to start working on a display — right now just a window opens, but that’s progress!

Much of my contributions were related to our development environment. I recreated our Docker container, which uses Alpine now. All of our build and testing tools are present in the container, and the image lives in the GitHub repository. The Docker container was generalized such that it can be used for building, testing, or linting/formatting either locally or in CI. This standardized our linting/formatting checks, and allowed automatic application of standards when run locally. I also implemented a few instructions, namely the stack and shift instruction set.

For future work, I intend to implement automated testing in the repo and to automate build releases. I’m also really looking forward to working on the PPU. This has been a fun project so far, and I’m lucky to have such a great team to work on it with.

See our repo here: https://github.com/coopeaus/NES-Emulator

For our senior design project, my team is building an NES emulator. Our GitHub repo can be found here. So far, the journey has been great — I’ve learned so much, and further cemented my understanding of the interaction between low-level components that began when I completed nand2Tetris. After getting a solid understanding of the steps to take, we decided to begin with the CPU. All other components rely on the CPU and its opcodes.

At this point, we have set up our development environment. I have been able to employ some of the skills I have developed in my career to employ CI checks through GitHub Actions, and now our repo will automatically check linting and formatting on pull request. The action also comments its suggestions on as a review on the pull request. One teammate set up bash files for easier building, and the CMakeLists.txt file we will use for compiling the project. We also have a Dockerfile set up for linting/formatting checks locally, for teammates without clang-format and clang-tidy installed.

We’re making great progress, and I’m looking forward to seeing this project through!

Welcome to my blog! My name is Austin Cooper, and I’m a senior studying computer science at Oregon State University. This blog will track my progress through my capstone project.

I live in Ohio with my wife, 3 dogs, and 2 cats. In my free time I like hunting, camping, and working on my project vehicles (a 1977 Volkswagen bus and a 1990 Volkswagen Cabriolet). Previously I was an automotive technician, but in January 2024 I started as a co-op in firmware verification. In September 2024 I was offered, accepted, and started a new role in test engineering.

I enjoy working with embedded devices, and have completed a few projects using platforms like Raspberry Pi, Arduino, and the ESP32. I have even designed my own board for processing analog audio using an ESP32 and a PCM1862 ADC.