Specifications

ManualsBrandsCheckpoint LAB ManualsMedia ConverterUSB-RS232

ECE391: Computer Systems Engineering Fall 2014

Machine Problem 2

Checkpoint: Wednesday, October 1

Midterm 1: Monday, October 6

Due: Monday, October 13

Device, Data, and Timing Abstractions

Read the whole document before you begin, or you may miss points on some requirements.

In this machine problem, you will extend a video game consisting of about 5,000 lines of code with additional graphical

features and a serial port device. The code for the game is reasonably well-documented, and you will need to read

and understand the code in order to succeed, thus building your ability to explore and comprehend existing software

systems. Most code that you will encounter is neither as small nor as well documented—take a look at some of the

Linux sources for comparison—but this assignment should help you start to build the skills necessary to extend more

realistic systems. As your effort must span the kernel/user boundary, this assignment will also expose you to some of

the mechanisms used to manage these interactions, many of which we will study in more detail later in the course.

Before discussing the tasks for the assignment, let’s discuss the skills and knowledge that we want you to gain:

• Learn to write code that interacts directly with devices.

• Learn to abstract devices with system software.

• Learn to manipulate bits and to transform data from one format into another.

• Learn the basic structure of an event loop.

• Learn how to use the pthread API.

Device protocols:

We want you to have some experience writing software that interacts directly with devices and must adhere to the

protocols speciﬁed by those devices. Similar problems arise when one must meet software interface speciﬁcations,

but you need experience with both in order to recognize the similarities and differences. Unfortunately, most of the

devices accessible from within QEMU have fully developed drivers within Linux. The video card, however, is usually

managed directly from user-level so as to improve performance, thus most of the code is in other software packages

(e.g., XFree86).

We were fortunate to have a second device designed by Kevin Bassett and Mark Murphy, two previous staff members.

The Tux Controller is that funny little game controller attached to each of the machines in the lab.

The Tux Controller connects to the USB port of the lab machine. An FTDI “Virtual Com Port” (VCP) driver makes the

USB port appear to software as a standard (old fashioned) RS232 serial port. We can then set up QEMU so that one of

the emulated serial ports on the virtual machine maps to the emulated serial port connected to the Tux Controller. In

this assignment, you will write code that interacts directly with both the (emulated) video card and the game controller

board.

Device abstraction:

Most devices implement only part of the functionality that a typical user might associate with them. For example, disk

drives provide only a simple interface through which bits can be stored and retrieved in ﬁxed-size blocks of several

kB. All other functionality, including everything from logical partitions and directories to variable-length ﬁles and ﬁle-

sharing semantics, is supported by software, most of which resides in the operating system. In this machine problem,

you will abstract some of the functionality provided by the Tux controller board.

Summary of content (10 pages)

PAGE 1
ECE391: Computer Systems Engineering Machine Problem 2 Fall 2014 Checkpoint: Wednesday, October 1 Midterm 1: Monday, October 6 Due: Monday, October 13 Device, Data, and Timing Abstractions Read the whole document before you begin, or you may miss points on some requirements. In this machine problem, you will extend a video game consisting of about 5,000 lines of code with additional graphical features and a serial port device.
PAGE 2
Format interchange: This machine problem gives you several opportunities for working with data layout in memory and for transforming 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 easily used by the Video Graphics Array (VGA) operating in mode X.
PAGE 3
adventure.c assert.c input.c modex.c photo.c text.c world.c Game logic, including the main event loop, helper thread, timing logic, display control logic (motion and scrolling), and a simple command interpreter (command execution code is in world.c). Support for assertions and cleanups as design and debugging aids. Input control. Provides for initialization and shutdown of the input controller. The version provided to you supports keyboard control. You must write the support for the Tux controller.
PAGE 4
one-byte pixel color values into this space. The table used in this mapping is called a palette, as it is analogous to a painter’s palette, which in theory holds an infinite range of colors, but can only hold a few at any one time. Palettes are often used to reduce the amount of memory necessary to describe an image, and are thus useful on embedded devices even today.
PAGE 5
dynamically as necessary to fill the screen. This facet is useful for games in which drawing the entire virtual world at once requires too much memory.
PAGE 6
The next question is the size of the build buffer. If we can limit the size of the room photo, we can allocate a build buffer large enough to hold any logical view window. If the window starts at pixel (0,0) in the room photo, plane 3 is placed at the beginning of the build buffer. If the window occupies the lower right corner of the room photo, plane 0 is placed at the end of the build buffer. Such calculations are not particularly hard.
PAGE 7
answer questions about memory fences or other code given to you, but it’s not ok to give code or pseudo-code for writing a vertical line to the mode X build buffer (one of the tasks below). We expect you to follow good software engineering practices in your code. Variables should almost never be global. On the other hand, don’t go parameter-happy: file scope variables are fine.
PAGE 8
To improve the visual quality of the game, you must optimize the remaining 192 colors for the photo being displayed and adjust these colors whenever the player moves to a new room. Color optimization requires that you implement an algorithm based on octrees, which will be explained later. Final CP: Tux Controller Serial Port Device This portion of the MP is due on the final due date. A subsequent document will be released with the tux controller requirements.
PAGE 9
level is an array of 64 elements that you can index by any interleaving of the two MSBs of each color—we suggest RRGGBB, but just be sure to use the same interleaving of bits for all uses. Other levels are equally straightforward. The Algorithm: This section outlines the algorithm that you must use. The text here is simply a rewriting of Section 2.2 from http://www.leptonica.org/papers/colorquant.
PAGE 10
Grading Note that the “correct” behavior of certain routines includes interfaces that allow one to prevent buffer overflows (i.e., the interfaces do not leave the size of a buffer as an unknown) and other such behavior. While the TAs will probably not have time to sift through all of your code in detail, they will read parts of it and look at your overall design.