Catchin' Up With Zach

Hello everyone!

I’m in the final couple weeks of the second term of my senior project. This term served as the development phase of the project. Last term, my group worked to establish a game plan for this development. We did a lot of research and created documents that detailed how a NES emulator functioned at a high level. This development phase was structured as two sprints that were four weeks each. It was up to our group to define the deadlines and goals for each sprint. The only official requirement set by the class itself was to have a Minimum Viable Product (MVP) completed by the end of the term. Working toward this goal has had its ups and downs. As somewhat inexperienced developers/software engineers, we did our best to plan as much as possible during the planning phase. However, there were some significant speed bumps toward the end of development. Conceptually, the NES emulation became a bit more complicated than we had expected. I’d like to talk about my experience with this project, so far, in this blog post.

For the first four weeks, during the first sprint, we decided to work on the emulation of the CPU. We figured that the CPU was the core component of the emulator, and so therefore, should take the most development time and would need to be correctly implemented for further development. With these two constraints in mind, we assigned all five of our group members to CPU development for the first sprint. This went well. We had a lot of brainpower working on understanding the technical complexities of the NES CPU’s architecture. By the end of the first sprint, we had an MVP-viable CPU implemented in our emulator. For the second sprint, we decided to split up the workload for the remaining components.

Remaining Components

In terms of my responsibilities, my only assigned component was the PPU. The PPU ended up being way more complex than the CPU and, conceptually, much more difficult to wrap our head around. While documentation for CPU development was very easy to find and very easy to understand, documentation for PPU development was slightly less abundant. Also, the documentation that was available took longer than I would like to admit to grasp. While NESDev Wiki forum posts on the CPU were easy to follow, NESDev Wiki forum posts on the PPU wracked my brain every time I went down a rabbit hole. It was clear that our research during the planning phase did not adequately cover the PPU. Admittedly, this was probably mostly my fault. During the first term, we split up the research for our documents based on which component each person wanted to work on. Since everyone had been assigned to the CPU, the other components were up for grabs. I chose the PPU because it sounded like the most interesting aspect of emulation. So, research for the PPU was my responsibility. I broke down PPU emulation into four main steps. In hindsight, I should have broken down these four steps into much smaller steps and done research on every little aspect individually. Essentially, to understand the PPU as a functional component of the NES, we needed to break down these four steps into much smaller steps and research them… during our second sprint. This slowed down development and complicated our trajectories. I let my group know as soon as possible that the scope of PPU development was way over my head as an individual. From there, we employed more brainpower toward its development. One group member in particular went above and beyond to help me understand this component and significantly contributed to PPU development.

Retrospective Evaluation

Looking back, there are a couple things that I could have done differently that would have made life a little easier for this project. First, I could have delved deeper into PPU research, as mentioned previously. However, there is one other thing that I would like to mention, as I think recognition of this is important for my personal growth as an engineer and team member. When researching the PPU, I stumbled across a post that detailed expected time spent on each component relative to the whole project. For example, the CPU was valued at about 25% development time of the project. The APU was valued at about 10%. The PPU was valued at about 50%. So, theoretically, the PPU required roughly twice the amount of time/effort than the CPU. I brought this up with my group when I found this out. The resolution was to assign another person to the PPU for the second sprint. While this was with good intentions, it still didn’t quite make the most sense to me. If we were assigning five people to the CPU for four weeks, why would we assign two people to a component that takes twice as long to implement, yet given the same time frame? I didn’t say much more after this about my concerns. I just went with the game plan. In future projects, I will voice my concerns louder and more vocally. Outside of university classes, things can be much less forgiving. Mistakes and inaction like this could have much more serious implications.

Final Thoughts

Overall, this senior project has been eye opening. I initially picked this project because of the enjoyment that I got from my class on Assembly languages. I loved the low-level architecture stuff. During the past two terms, I have learned so much about computer hardware, ranging from the history of processors to the technical reasoning for design choices made for hardware, both back then and today. I have worked as a part of a team for a substantial amount of time. I have (mostly) successfully communicated with my team. This project has been part of a significant amount of personal growth. I look forward to the next term and the finalization of our emulator. I have a few more terms of classes before I graduate. It feels like my entry into my career is right around the corner!

As always, thank you for reading my post! Catch ya next time.

Hello everyone!

This post is going to be dedicated to technologies used for my group’s development of an NES Emulator. Honestly, we have set up a very simple tech stack. On top of that, the components of the stack that I have had to develop or interact with have been somewhat familiar anyway.

First, I’d like to discuss the technologies that we use for our development. Our emulator is written in C++ and hosted in a repository on GitHub. My involvement with the project consists mostly of interacting with this repository and adding/removing/editing C++ code. Our project utilizes makefiles, but I was not the one who ended up implementing this. Our project also utilizes some C++ GUI libraries, but again, I was not the one who ended up using these. My workflow consists mostly of fetching the most recent state of the repository into a feature branch, contributing my content, and then pushing my updates to the feature branch and submitting a pull request. This is a workflow with both familiar and unfamiliar aspects.

Regarding the familiar aspects, I have some experience with Git, mostly through previous classes though. I’ve only experimented with Git outside of OSU on a few occasions. Regardless, most of the core of Git and GitHub is recognizable from past experiences. However, there are multiple unfamiliar aspects as well. First, I had never written any C++ code before this project. My most comfortable languages are interpreted ones like Python, so working with a compiled language came with a small learning curve. However, thanks to a teammate who designed a makefile for our project, compiling the code is as simple as typing “make” into the terminal. On top of this, this project has required much more interaction with Git and GitHub than previous assignments have. I’ve learned many new functionalities of this version control. Most importantly, through group conversation, I have learned how to “rebase” branches which makes submitting pull requests and merging much simpler. Along with learning a better understanding of Git, I have also learned how to utilize the built-in functionality of Git with my IDE of choice, VS Code. VS Code has a source control section that can allow a user to sign into their GitHub account and work on repositories using an easy to navigate UI. This UI allows for pulling/fetching, rebasing, committing, pushing, etc. I have heavily used this VS Code feature for my development.

Overall, C++ has been a fun language to work with and GitHub has been an interesting learning experience, but important, nonetheless. I feel that I have greatly improved my abilities to work in a group and my abilities to work in unfamiliar environments. Our first sprint went very smoothly. We have a successful MVP implementation of the NES CPU. Next sprint, I will be working with a group member on the PPU. I am very excited and look forward to future development!

Thank you for reading my post! Catch ya next time.

Hello everyone!

This blog post will be dedicated to the concepts of clean code and code smells. Inherently, clean code does not smell or at the least does not smell as bad as other code. As code becomes smellier, the codebases become harder to work with, maintain, and improve. This makes the process of working in these scenarios harder and more expensive. There are many instances of mistakes that can make your code smelly. There are also extensive resources out there to help ensure that your code is as clean as possible. In this blog post, I would like to delve into an aspect of clean code that I am consciously trying to improve as well as a code smell that I will consciously try to avoid.

Clean Code Example

According to Minu Kumari in their Medium article titled “The Craft of Clean Code: Essential Principles of Software Developers,” functions are a main target of implementing clean code. The aspect of functions that I am consciously trying to improve involves conciseness. According to Kumari, developers should try to keep functions short and concise, using less than 20 lines per function (Kumari 2024). It is stated that functions surpassing this line length should be evaluated and attempts should be made to break them down (Kumari 2024). This is a large task for beginners like myself. I’ve been told in previous classes, working on previous assignments, to work toward this goal. It adds a layer of complexity to your planning that must be accounted for. Sometimes, time becomes an issue. I would love to employ this behavior though. Short and concise functions make sense to use. Having specialized units that do specific things would be much more adaptable than jack-of-all-trades functions that do too much.

Code Smell Example

For my research regarding code smells, I discovered a site called Refactoring Guru. This site defines the main types of code smells, breaking them down into general categories, and then breaking those categories down into specific examples. The category that I was interested in is called “Dispensables.” According to Refactoring Guru, dispensables are additions to the code that are pointless and could be removed to make the code cleaner (Refactoring Guru). The specific example of a dispensable that I am interested in trying to avoid involves comments. The page regarding comments goes into detail by establishing that code should be understandable without comments and that comments are not meant to be used “like a deodorant masking the smell of fishy code that could be improved” (Refactoring Guru). I am absolutely guilty of using too many comments, especially ones that do not serve a justifiable purpose. I have been working on this over the past few years and have improved significantly in my comment utilization, but I recognize that I still need to develop this habit. Put in this way, if I can avoid useless comments, that should mean that my code is becoming more readable and understandable, which is desirable regardless.

Overall, as a junior developer with very little experience, there are many aspects of development that I need to learn or need to improve on. Prompts like this that lead to research into clean code and code smells are a step in the right direction. One of the most important things to actually reducing code smell is to constantly remind myself that code can smell in the first place. As a novice, it’s easy to forget, but important to consider.

Thank you for reading my post! Catch ya next time.

Works Cited

Comments. Refactoring.Guru. (n.d.). https://refactoring.guru/smells/comments

Kumari, M. (2024, February 9). The craft of Clean Code: Essential Principles for Software developers. Medium. https://medium.com/@minuray10/the-craft-of-clean-code-essential-principles-for-software-developers-bcfb9ab6fc2f

Hello again, world!

Where should I start? We’re wrapping up the first term of work on our capstone project. This term has mostly consisted of research and planning. In fact, we just submitted the v0.0.2 assignment. This was a slightly confusing assignment. We haven’t done much development yet. The real development starts next term. However, we were asked to set up a “Hello World” type of repository for our project. As a group, we weren’t entirely sure what to include in this repository. Since I’m in charge of the PPU implementation, I was in charge of setting up a PPU test file for all intents and purposes of the v0.0.2 assignment.

For this assignment, I decided to do something simple and straightforward. I created a very basic C struct that contains four members. The four members correspond to the four components of the NES PPU’s OAM. OAM stands for Object Attribute Memory. Basically, each graphical sprite can be represented by four bytes of data in the OAM, one byte designated for each component. The four components are as follows: Y position, tile index number, attribute information, and X position. With the struct that I added, we can create OAM structures that contain these four bytes of information as their components. So, I did exactly that in the test file. I created a Sprite OAM struct, assigned some values, and printed the Sprite OAM struct’s data to show that the structure was fully useable.

I’m looking forward to future development. This project still has my interest peaked. I can’t wait to get into the late-night coding sessions. This class has offered me an opportunity to do something truly awesome and my group seems very reliable, so I think the journey will be a positive experience. Our Discord server is quite active. All members of the group seem to respond quickly and appropriately. Things are going much smoother than I thought they would. Hopefully the next term and future progress on the project goes as smoothly as the researching and planning has gone. I’m hopeful and confident that things will be perfectly fine, regardless.

Thank you for reading my post! Catch ya next time.

Hey everyone!

So, I got assigned the NES Emulator as my senior project. Honestly, this project is much different than what I expected, but I could not be more excited to work on this.

I knew the project would involve low-level architecture. I figured our group would be programming in a language like C or C++ and we are. However, I did not fully understand the idea of emulating another hardware. It takes so much more knowledge of the original hardware than I originally thought. I spent the first few weeks reading about NES architecture and watching videos on NES emulation. Funnily enough, many of these videos were simply there to teach you about NES architecture. Understanding the fundamental hardware components that make up a system is super important to being able to emulate the system, so I’ve learned.

For my project, I have mostly spent my time researching two major components of the NES, the CPU and the PPU. The CPU, an abbreviation for the Central Processing Unit, is a component that is responsible for processing commands and coordinating with other components. The PPU, an abbreviation for the Picture Processing Unit, is a component that is responsible for processing sprites and background images and displaying them to the screen. They’re both very complex components and I can’t say that I fully understand them, but I am beginning to see how they work. At first, everything was overwhelming. At this point, things are starting to make sense. My group is very supportive, and every individual seems committed to the task of building a NES emulator. Our group started off with a solid level of excitement and I feel like the group, going into the end of the first quarter, is still quite excited. This probably has a lot to do with the structure of the course that is guiding us.

Overall, the course has been great. At the end of the day, this class is more about the project and the experience gained from working in a team, rather than a grade. There is a lot of work to do, but I don’t ever feel stressed to get it done. This is partially because I’m excited to work on the project and learn the material, but also partially because of the structure of the course. Assignment deadlines are very helpful in keeping us on track but forgiving enough to not cause any problems within the group. I look forward to the next two terms of this course, with this project and my specific group.

I’m very excited to continue learning about the NES and emulation in general. I’m very excited to begin development of the emulator itself. I’m confident that we’ll get it done. This has been a majorly positive experience, and I can’t wait to see where it leads.

Thank you for reading my post! Catch ya next time.

Hello, World! Welcome. My name is Zachary Adkins, but I often go by just Zach. I live in Pennsylvania so I’m 3 hours ahead of OSU’s time zone. I am a full-time student and have been for about 3.5 years now. Coming to OSU was my first experience with higher-level education. Life happened after high school, and I took several years off. So, currently I am 28 years old and should be graduating within the next year and a half! Woo! I am very excited.

My time consists mostly of schoolwork, but I do have a few hobbies. I mostly enjoy playing video games. I used to play a lot of Call of Duty and Counter-Strike but have moved on to less competitive games. I mostly play Path of Exile and Runescape nowadays.

Runescape is surprisingly the game that got me into computers. I started playing when I was about 12 years old and learned to type quickly on this game. I became interested in programming when I started to think about how Runescape was made. This simple game really was the beginning of a long journey that has brought me to where I am today. What started as a small curiosity in game development has flourished into a huge passion for programming and the Software Industry. For the two years leading up to the pandemic, I was researching game development and general programming stuff and found a Python course on Udemy that I followed, teaching me some very basic practices and general Python knowledge. My best friend from high school was graduating from university at this time as well, and ended up in the Software Industry, which allowed some insight into what the career would be like. Covid rolled around and everything went remote, so I entertained obtaining an online degree. By the end of 2020, I was enrolled here at OSU and by January of 2021, I was taking my first college class.

I feel like I have learned so much from the classes I’ve taken. Even some of the core general education courses have been enlightening. I have 5 quarters left before graduating, which are all very CS heavy workloads and I can’t wait to see what else I will learn.

This Senior Project class seems to be one of the most interesting ones in the program. Having looked over the project repository, I think I’m going to greatly enjoy this one. I’m going to list the projects that I applied for and a little blurb about each one below.

1. NES Emulator – This project seems to be all about low-level programming. Honestly, I loved Assembly language. That class was one of the most enjoyable classes I’ve taken so far. If I get assigned to this project, I’m eager to see how more advanced low-level programming feels. I’m not sure about which specialization/field to target after graduation so this project could be eye opening.
2. Artificial Life Simulation – This project just sounds and looks incredible. The potential for this project seems to be through the roof and it is the most “awesome” project in my opinion. I have zero clue how to develop something like this but I would be excited to figure it out.
3. Top-N Music Genre Classification – I’ve heard about Keras and Tensorflow. I’m quite experienced with Python. I’ve watched videos of incredible programmers and mathematicians developing neural networks from scratch. I also LOVE music. This project looks to be pretty awesome.
4. Engineering Simulations with Game Development Tools – This project appeals to the physics lover in me. I am currently taking General Physics with Calculus (PH 211) and am taking PH 212 next quarter. I’ve been a huge physics nerd for a long time but never formally educated until now. I’m excited to see what these classes have to offer, and I would love to contribute to the physics aspects of this project if these classes teach the relevant information (or not. I love learning so I would be willing to learn more physics!).
5. Travel Planner Website – I have always entertained becoming a full-stack web developer. It’s sort of my safety net specialization. The work seems to be pretty enjoyable to me given what I’ve experienced so far in classes here at OSU. I’m much more interested in fields like AI, ML, data-driven fields, and game development, but web development is important and this project seems like it would absolutely solidify my understanding.

I look forward to seeing what this series of courses is going to bring me! Regardless of which project I get assigned to, I know that I’m going to have an absolute blast. I’m hard-working, very easy to get along with, and my availability allows for communication/grouping with pretty much anyone. Thank you for reading my post! Catch ya next time.

Welcome to blogs.oregonstate.edu. This is your first post. Edit or delete it, then start blogging!