Specifications

ManualsBrandsCheckpoint LAB ManualsMedia ConverterUSB-RS232

ECE391: Computer Systems Engineering Spring 2015

Machine Problem 2

Checkpoint 1: Monday, March 2, 7pm

Checkpoint 2: Monday, March 9, 7pm

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 4,000 lines of cod e 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 succee d, thus building your ability to explo re and comprehend existing software

systems. Most code that y ou will encounter is neither as small nor as well docum ented—take a loo k at some of the

Linux sour ces 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 som e of

the mechan isms used to manage these interac tions, 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 fro m one format into another.

• Learn the basic structure of an event loop.

• Learn how to use the pth read API.

Device Protocols:

We wa nt yo u to have some experience writing software that interacts directly with devices and must adhere to the

protocols speciﬁed by those d evices. Similar problems arise when one mu st mee t software inte rface speciﬁcations,

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

devices accessible from within QEMU have fully developed dr ivers within Linux. The vid eo 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 secon d device designed by Kevin Bassett and Mar k Murphy, two previous staff member s.

The Tux Controller is that funny little game controller attached to eac h 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 sof tware as a stand ard (old fashioned) RS232 serial port. We can then set up QEMU so that one of

the e mulated serial ports on the virtual machine m a ps to the emulated serial port connected to the Tux Controller. In

this assignment, you will write cod e 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 th e m. For example, disk

drives provide only a simple inter face through which bits can be stored and retrieved in ﬁxed-size bloc ks of several

kB. All other functiona lity, 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.

Format Interchange:

Summary of content (12 pages)

PAGE 1
ECE391: Computer Systems Engineering Machine Problem 2 Spring 2015 Checkpoint 1: Monday, March 2, 7pm Checkpoint 2: Monday, March 9, 7pm 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 4,000 lines of code with additional graphical features and a serial port device.
PAGE 2
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
assert.c blocks.s input.c maze.c mazegame.c modex.c text.c Support for assertions and cleanups as design and debugging aids. Graphic block images of the maze, the player, fruits, etc. 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. This file is not compiled with the rest of the game and should be used only to test your inputs separately from the game.
PAGE 4
Each pixel in mode X is represented by a one-byte color value. Although only 256 colors are available in mode X, the actual color space is 18-bit, with 6-bit depth for red, green, and blue saturation. A level of indirection is used to map 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.
PAGE 5
The game defines a two-dimensional world of pixels, and the screen at any time shows a region of that world. The maze world is never fully constructed in memory; rather, it is constructed 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 maze world, we can allocate a build buffer large enough to hold any logical view window. If the window starts at pixel (0,0) in the maze world, plane 3 is placed at the beginning of the build buffer. If the window occupies the lower right corner of the maze world, plane 0 is placed at the end of the build buffer. Such calculations are not particularly hard.
PAGE 7
easy place to start. The main difficulty is for you to understand both how mode X maps pixels and how the abstractions in modex.c work, so try to read the code and documentation to the point that you feel you understand these things, then try to write the function with the help of the examples. Find the VGA documentation for the status bar. Doing so was part of PS2, and you can work together and discuss how it should be done, but not trade code to do it. Add the status bar to the game.
PAGE 8
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. Your tasks for checkpoint 2: 1. Enable the device driver to control the LEDs on the Tux controller 2. Enable the device driver to report when buttons are pressed and released 3. Handle device resets correctly 4. Enable reading the LED state from the Tux controller. 5.
PAGE 9
Building the Driver: The mp2/module directory contains a framework for the driver you will be implementing for the Tux controller. A module is similar to a dynamically-loaded user-level library but instead of being used by an application it is used by the kernel to extend functionality. Modules allow for drivers to be loaded without having to recompile (or even reboot) the whole kernel. This simplifies the process of debugging as well.
PAGE 10
level programs such as the game. You must implement the following ioctls for your device abstraction: TUX INIT Takes no arguments. Initializes any variables associated with the driver (see TUX READ LED) and returns 0. Assume that any user-level code that interacts with your device will call this ioctl before any others. TUX SET LED The argument is a 32-bit integer of the following form: The low 16-bits specify a number whose hexadecimal value is to be displayed on the 7-segment displays.
PAGE 11
7 0 0 1 0 0 0 1 0 0 0 1 X X X C B A S 1 1 X X X R D L U 2 That is, the first byte will have the value MTCP POLL OK, the second and third will contain active-low bit masks of which buttons are pressed; that is, a bit will be ‘0’ when the corresponding button is pressed. The C, B, A, and START (S) buttons are in the second byte, and the right (R), down (D), left (L), and up (U) bits are in the third. Bits marked as ‘X’ in the diagram are unused. MTCP LED SET See mtcp.
PAGE 12
adjacent levels look different (you can reuse some colors if you want, but you can’t have just one). You can also make them glow, change with the number of fruits, etc., but these last things aren’t required. Create floating, semi-transparent text that lasts a few seconds when a player finds a fruit. For transparency, you can use a linear interpolation of RGB values between the underlying color and white.