Specifications

This machine problem gives you several o pportu nities for working with da ta layout in memory and for tr ansforming
data from one form to another. Most of these tasks relate to graphics, and involve taking bit vectors or pixel data laid out
in a form convenient to C programmers and changing it into a form ea sily used by the Video Graphics Array (VGA)
operating in mode X. Although the details of the VGA mo de X layout are not particularly relevant today, they do
represent the end prod uct o f good engineers working to push the limits on video technology. If you work with cutting-
edge systems, you are likely to encounter situations in which data formats h ave been contorted for per forman ce or to
meet standards, and you are likely to have to develop system s to transform from one format to another.
Event Loops:
The idea of an event loop is central to a wide range of software systems, ranging from video games and discrete event
simulators to graphical user interfaces an d web servers. An event loop is not much different than a state machine
implemented in software, and structuring a software system around an event loo p can help you to structure your
thoughts and the design of the system.
Threading:
Since the advent of faster p rocessors, it became possible to exploit code parallelism by creating multiple threads.
Multiple threads of execution also allow logical separate tasks to be executed using synchronous operations. If one
thread blocks waiting for an operation to complete, other threads are still free to work. Note that threads are different
from processes. A thread is the smallest unit of processing that can be scheduled by an op e rating system. Mu ltiple
threads can exist within the same process and share resources such as memory. Different processes can not share these
resources. On a single processor, multithreading generally occurs by having the processor switch between different
threads, which is k nown as context switch ing. Since context switching happens frequently, the user perc eives the
threads as runnin g concurrently.
In this machine problem, we illustrate the basic concepts by using a separate thread to get updates from the keyboard.
You will need to synchronize your co de in the main threa d with this helper thread using a Posix mutex. You will also
need to add a new thread to take input from the tux controller. This thread may also need sync hronization to guarantee
correctne ss.
You may want to read the class notes on Posix threads to help you understand these intera ctions. Later classes will
assume knowledge of this materia l.
Software examples and test strategies:
In addition to these five learning objectives for the a ssignment, this machine pro blem provides you with examples of
software structure as well as testing strategies for software components.
Two of the files include main f unctions th a t are only included when a defined value is changed at the top of the file. By
setting this value to one and compiling the file by itself, you create an executable that tests the func tionality provided
by the file in the absence of other co de. When you design software interfaces, you should do so in a way that allows
you to test compo nents sep arately in this manner and thus to de al with bugs as soon as possible and in as small a body
of code as possible. Individual function tests and walking through each function in a debugger are also worthwhile,
but hard to justify in an academic setting. The input control file allows y ou to develop an d test your Tux controller
code without using the game interface. Since the game changes the display to mode X, testing without the hassle of
changin g back to text mode can be quite helpfu l.
The modex.c file is compiled by the Makefile to create a separate executable that returns your system to text mode.
We a lso made use of a technique known as a memory fence to check some of the more error-prone activities in the
file; read the code to understand what a memory fence is and what it does f or you.
The Pieces Provided
You are given a working but not fully-functional copy of the source tree for a maze game along with a skeletal kernel
module for the Tux con troller. The Tux controller b oards are a ttac hed to each machine in the lab.
The table below explains the contents of the source files.