Course Syllabus

Essentials

Overview

This course explores the foundations of modern computing through the lens of retrocomputing and emulation. Retrocomputing allows us to revisit the pioneering technologies of the past, from early mainframes and minicomputers to the iconic 8-bit microcomputers that revolutionized personal computing. Emulation allows us to recreate these systems in software, providing a hands-on experience with early computer environments that wouldn't otherwise be accessible.

In this course, students will not only get hands-on experience working with (and writing code for) these vintage systems, but will also gain a deep understanding of the principles that underpin modern computing. In particular, the 8-bit machines of the 1980s allow us to understand “the whole enchilada” of a computer system, from hardware to software, in a way that is difficult to achieve with modern systems.

Students will also gain understanding and experience working with the software that emulates these systems, as well as the challenges and opportunities that come with it. The construction of “virtual machines” (in this case virtual retro machines) is an enduring topic in computer science with broad applications beyond retrocomputing. A final project will allow students to apply their knowledge, potentially creating demos, or exploring hardware emulation.

As a new offering, student input will help shape the course's direction.

In other words, you can expect to learn

• How computers “really work”—things you ought to know but didn't learn in CS 105 or CS 134.
• Techniques used in solving challenging problems in the real world (not just on old 8-bit systems, but everywhere) where there may not be an elegant theoretical answer. Solving real problems is all about looking at the trade-offs.
• How to work within the limitations imposed by hardware built under both technological (because of where CPUs and other electronics were at when the machines were designed) and market forces (where “cheaper is better” = more profit for the manufacturer).

But this course also aims to be fun! Getting code running on iconic machines of the past can be quite a blast!

Electronic Access

Much of the communication for this course will be handled electronically through the class website, mailing list(s), and Piazza. You are responsible for being familiar with announcements posted to the class mailing list(s) and with the contents of the class website.

Office Hours

I'm generally available to chat about things after class, but I can also chat by appointment using this Calendly link, which books a Zoom chat

Website & Wiki

The class website is available at

• https://www.cs.hmc.edu/cs181ar/

As well as providing useful general information (such as how to find me when you have questions), homework assignments will be posted on the class website.

The class also has a wiki, which is available at

• https://github.com/hmc-cs181ar-spring2025/hub/wiki

Communications and Getting Help

If you have questions about the course (about assignments, course policies, C++, etc.) that you cannot answer yourself, please use Piazza for asynchronous communication (not email); there are more eyes on Piazza so you are more likely to get a quick response.

There are several different ways to get help, ask questions, and otherwise reach out, each with their own purpose. We will use Piazza for asynchronous communication, and professor office hours either online or in-person for synchronous communication.

Computer and Website Accounts

• Course Website: This website is the hub for all course content, including course policies, learning material, and homework descriptions.
• Course Wiki: The course wiki is a collaborative hub where we'll share resources, tips, and other useful information. You can also use it to document your own learning journey.
• Piazza: Most communication about the course, including announcements, requests for help from the instructors, grutors, or fellow students (see the help page for more on Piazza).
• GitHub: Your coursework will use Git for version control, and GitHub for distributing starter code, sharing code with classmates.

Coursework & Grading

The work in this class is unlike most other classes you've taken, being far more open ended, with more opportunity to explore and experiment than typical classes. Each week, you'll have a challenge of suggested pathways to explore. You'll have a week to work on the challenge, and then you'll share your work to the class, sometimes in a class discussion, sometimes a presentation, and sometimes showing demo of the code you've written, but often a mix of all three.

Group Programming

You are allowed (and encouraged) to work on these challenges as a team of up to three people. You can work with different people on different challenges, or stick with the same team throughout the semester. You can also work alone if you prefer. As team size increases, so do expectations for the quality and scope of the work. Your team may also include any large language models (LLMs) you find helpful, but you must follow the LLM usage policy and disclose any significant contributions from LLMs in your work—expectations rise as the amount of LLM-generated content increases.

Readings

As a seminar-style class, some challenges will involve reading and discussing papers or other materials. You will be expected to read the materials before class and participate in the discussion.

Exams

There are no exams in CS 181AR; grades are based on your participation in class discussions and project work.

Final Project

In the final few weeks of the semester, you will have the opportunity to focus on a retro-computing project of your choosing, which could involve writing code, creating a demo, or exploring hardware emulation. You will present your project to the class (and outside guests) at the end of the semester.

Grading Policy

Many aspects of the course will be assessed on the following scale:

• Outstanding!
• Good
• Proficient
• Nearly There
• Needs Work
• Attempted
• Not Attempted

In many contexts, you will be asked to self assess your own peformance on this scale. You will also be asked to assess your peers' work on this scale. I will also use this scale when assessing your work.

At the end of the semester, letter grades will be assigned based on a holistic review of your work throughout the semester. Roughly speaking, the following guidelines will be used:

• A — Outstanding work, consistently demonstrating an impressive understanding of the material and going above and beyond the requirements of the course.
• B — Good work, demonstrating a solid understanding of the material and meeting the requirements of the course.
• C — Satisfactory work, demonstrating a basic understanding of the material and meeting the requirements of the course.
• etc.

Overall, I encourage you not to worry too much about grades in this class, and instead focus on learning and creating awesome things. If you are engaged and participating in the class, you will do well.

Your Responsibilities

You have a number of responsibilities in this class. It is important that you understand them so that you can avoid costly mistakes such as loss of credit on an assignment or accidental violation of the honor code.

Collaboration and the Honor Code

All students—even those from other colleges—are expected to understand and comply with Harvey Mudd College's Honor Code. If you haven't already done so, you must read, sign, and abide by the computer-science department's interpretation of the Honor Code to participate in this course.

You are encouraged to discuss general features of assignments and the ideas involved with other students, including general approaches to the problems, bugs in the specification, how long you've spent working on a problem, and so forth. You may also help each other with issues related to completing the assignments—how to use Unix, basic C++ programming issues, and the like.

Two good rules of thumb are the “in your head” and “understanding, not rote learning” rules. When students help each other, they should leave with understanding in their heads, not physical or electronic artifacts. Thus you are not allowed to meet as a group and leave with notes on paper, nor can you help someone fix a bug and then leave without first reverting the bug to its unfixed state. Similarly, it is not okay to leave with an answer you don't understand (in the worst case, where such a situation seems unavoidable because you have found out the answer but still don't understand it and have to leave, it is vital for you to say so, since not doing so is dishonest). Also, if you are helping someone, remember that giving away answers can actually be detrimental to someone's understanding—often it is better to ask leading questions instead. Working together as peers and coming to an understanding together is, of course, even better.

If your work is influenced by materials you have read, or discussions with other students, you should document that influence. When coding, you should describe those contributions in your comments.

You must not exchange literal copies of material, whether that material consists of code, program output, or English-language text (e.g., documentation). You also may not copy material from published or online sources, with or without cosmetic changes (such as altering variable names), without explicit permission. If you do have permission to use externally written material, you must attribute it properly and clearly indicate which material is yours and which material is not yours.

If you aren't sure whether something you've done or plan to do is allowed, you should explicitly document what you did and—if at all possible—consult with the course staff, ideally before you take the questionable action. Similarly, document any extensive or particularly important help you obtain, even if that help seems legitimate. If the questionable material or extensive help is explicitly marked as such, you might lose points but still avoid violating the Honor Code.

These principles apply to all methods and media of discussion or exchange (voice, writing, email, etc.).

Attendance and Participation

You are expected to attend every class. I will not be formally taking attendance, but many classes will have group exercises that will affect your final grade (both directly, because I grade for class participation, and indirectly, because questions on the exams are often similar to the group-exercise questions). If you wish to miss a class for any reason, you should ask beforehand about the make-up work you will need to do. If you are sick, you can send word to me through another student.

You are expected to participate actively in each class. The only way to receive a high grade for class participation is to be an active participant in the class (duh!).

Due Dates and Late Policy

Because you will usually be sharing your accomplishments in class, there is no opportunity to turn work in late or early. Instead, you have three “different path exceptions” you may use during the semester. These exceptions allow you to propose a different path for a challenge (or a different challenge entirely). You may use these exceptions for any reason. You may not use more than one exception in a row, and you may not use more than two exceptions in a row. You may not use more than three exceptions in total. If you use an exception, you must notify me by email before the due date of the challenge you are replacing. If you do not notify me, you will receive a zero for that challenge.

Unforeseeable Extenuating Circumstances

A similar approach is taken for unforeseeable extenuating circumstances, but the exceptions do not count against your total.

In general, extenuating circumstances (such as illness) are dealt with on a case-by-case basis. In general, you are only excused for situations you could not have forseen, and only if you explain the situation at your soonest opportunity (either directly or via someone else, such as the Dean of Students), before the due date.

Illness

If you get sick during the term, notify me immediately, even if you think that being sick will not affect your ability to complete your assignments. You should also notify me any time that you're sick enough to miss any classes (not just CS 70) or find that your performance is below par for any reason.

Getting Help

If you need help with a course-related problem, come and see me. Talking in person is often the fastest way to resolve a problem, especially if it's conceptual. If you speak to a grader and are not happy with (or convinced by) their answer, you should see it as their failure rather than yours, and seek me out for a better answer.

If you have a simple question, a clarification, or a simple request, you may prefer to use email. You should send email to the mailing list, which is read by me and the graders, maximizing your chances of getting a quick answer to your question.

I believe that you learn best when you discover answers for yourself, so I will often respond to conceptual questions with questions of my own, designed to help you find the answer for yourself. If you wait to ask your question until you are feeling very frustrated (or until the last minute), you may find my answer maddening. For that reason, ask your questions early.

If you have sensitive issues—such as personal issues or Honor Code violations—that you need help with, contact me directly.

Large Language Model (LLM) Usage Policy

As artificial intelligence and large language models (LLMs) become increasingly prevalent in the tech industry, it's important to establish clear guidelines for their use in academic settings. This policy outlines the acceptable use of LLMs, such as ChatGPT, Claude or GitHub Copilot, in this course.

Permitted Uses

1. Concept Understanding: You may use LLMs to help clarify complex OS concepts or to get alternative explanations of course material.
2. Brainstorming: LLMs can be used for generating ideas or approaches to problems, but implementation must be your own.
3. Debugging Assistance: You may use LLMs to help identify bugs in your code, but you must understand and implement the solutions yourself.
4. Research Aid: LLMs can be used to find relevant resources or summarize research papers related to OS topics.
5. Direct Code Generation: Unlike other classes, you may use LLMs to generate code snippets or pseudocode. But if you do have LLMs write code, you must be transparent about the extent of your use of AI-generated code, and it should not be seen as a way to do less work, but as a way to achieve more.

Prohibited Uses

1. Uncited Use: Any significant ideas or insights gained from LLMs must be cited in your work.

Requirements

1. Critical Evaluation: Always critically evaluate any information or suggestions provided by LLMs. They can make mistakes or provide outdated information.
2. Citation: When using LLMs for research or idea generation, cite them as you would any other source. Example: "Idea explored after discussion with [LLM name], [date]."
3. Transparency: If you're unsure about whether your use of an LLM is acceptable, consult with the instructor.

Academic Integrity Reminder

Your submitted work must represent your own understanding and efforts.

If you present the output of a large language model as your own work, that is an academic integrity violation.

Accommodations

HMC is committed to providing an inclusive learning environment and support for all students. Students with a disability (including mental health, or chronic or temporary medical conditions) who may need accommodations in order to fully participate in this class are encouraged to contact their home college's accessible-education officer:

(When logged in, completion status appears here.)

Go to Parent Page Next Page