Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
ECE391: Computer Systems Engineering
Machine Problem 2 Checkpoint 1 due in Gitlab repo by 5:59 PM CST on Monday 8 March
BE AWARE THAT U.S. TIME CHANGES BETWEEN THE DEADLINES!
Device, Data, and Timing Abstractions
Read the whole document before you begin, or you may miss points on some requirements.
In this machine problem, youwill extend a video game consisting of about 4,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 specified by those devices. Similar problems arise when one must meet software interface
specifications, but you need experience with both in order to recognize the similarities and differences. Unfortunately,
most of the devices accessible fromwithin QEMUhave 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 are 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
fixed-size blocks of several kB. All other functionality, including everything from logical partitions and directories
to variable-length files and file-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: 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 modeX. Although the details of the VGAmodeX layout are not particularly
relevant today, they do represent the end product of 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 have been contorted
for performance or to meet standards, and you are likely to have to develop systems 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 and web servers. An event loop is not much different than a state
machine implemented in software, and structuring a software system around an event loop can help you to structure
your thoughts and the design of the system.
Threading: Since the advent of faster processors, 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 operating system.
Multiple threads can exist within the same process and share resources such as memory. Different processes cannot
share these resources. On a single processor, multithreading generally occurs by having the processor switch between
different threads, which is known as context switching. Since context switching happens frequently, the user perceives
the threads as running 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 code in the main thread 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 synchronization to guarantee
correctness.
You may want to read the class notes on Posix threads to help you understand these interactions. Later classes will
assume knowledge of this material.
Software examples and test strategies: In addition to these five learning objectives for the assignment, this machine
problem provides you with examples of software structure as well as testing strategies for software components.
Two of the files include main functions that 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 functionality provided
by the file in the absence of other code. When you design software interfaces, you should do so in a way that allows
you to test components separately in this manner and thus to deal 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 you to develop and test your Tux controller
code without using the game interface. Since the game changes the display to mode X, testing without the hassle of
changing back to text mode can be quite helpful.
The modex.c file is compiled by the Makefile to create a separate executable that returns your system to text mode.
We also 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 for 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 controller. The Tux controller boards are attached to each machine in the lab.
The table below explains the contents of the source files.
assert.c Support for assertions and cleanups as design and debugging aids.
blocks.s Graphic block images of the maze, the player, fruits, etc.
input.c 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. Can be compiled stand-alone to test the input device.
maze.c Maze generation and logic. Creates the maze; creates, checks for, and consumes fruit; checks for
win conditions. Transforms the block image data in blocks.s into pixelized graphic images of
maze lines and columns for use by modex.c in drawing parts of the logical view. Can be compiled
stand-alone to test maze generation.
mazegame.c Multithreadedmain process of the mazegame. There is a thread that controls the game logic, includ-
ing the main event loop, level set up, all timing logic, display control logic (motion and scrolling).
Includes a computer-controlled player as well as one using the regular input control. Another thread
is created to handle keyboard control. You will eventually need to add another thread for the Tux
Controller control.
modex.c Functions to support use of VGA mode X. Includes things like switching from text mode to mode
X and back, and clearing the screens. Provides a logical view window abstraction that is drawn in
normal memory and copied into video memory using a double-buffering strategy. When the logical
view is shifted, data still on the screen are retained, thus only those portions of the logical view that
were not previously visible must be drawn. Finally, supports mapping from pixelized graphics in
formats convenient to C into drawing a screen at a certain logical position. Relies on maze.c to
provide vertical and horizontal lines from the maze. Is also compiled stand-alone to create the tr
text mode restoration program.
text.c Text font data and conversion fromASCII strings to pixelized graphic images of text (youmust write
the latter).
We have also included two stripped binaries to illustrate your end goal. The mazegame-demo program is a fully
working version of the game that allows both keyboard and Tux controller input. The input-demo program is a
stand-alone compilation of input.c, again allowing both forms of input.
The tr Program
The make file provided to you builds both the game and a text-mode-restoration program called tr. The latter program
is provided to help you with debugging. One difficulty involved with debugging code that makes use of the video
hardware is that the display may be left in an unusable (i.e., non-text-mode) state when the program crashes, hangs, or
hits a breakpoint. In order to force the display back into text mode for debugging purposes (or, if you are not running
the program in a debugger, to regain control of your shell), you can run the tr program. Unless you are fairly confident
in your ability to type without visual feedback, we recommend that you keep a second virtual console (CTRL-ALT-F1
through F6) logged in with the command to execute the text restoration program pre-typed, allowing you to simply
switch into that console and press Enter. Using this program is substantially easier than rebooting your machine to put
it back into text mode.
You should also look at the cleanup handlers provided by the assert module (assert.h and assert.c). These
cleanup handlers provide support for fatal exceptions, putting the machine back into a usable state when your program
crashes. However, there may be instances and problems not covered by the handlers, and GDB can stop the program
before the handlers are invoked, leaving the machine in an unusable state until you restore text mode with tr.
Mode X and Graphic Images
Mode X is a 256-color graphics mode with 320x200 resolution. It was not supported by the standard graphics routines
that came with the original VGAs, but was supported by the VGA hardware itself, and was quickly adopted as the stan-
dard for video games at the time because of certain technical advantages over the documented 256-color mode (mode
13h, where the ‘h’ stands for hexadecimal). In particular, mode X supports multiple video pages, allowing a program
to switch the display between two screens, drawing only to the screen not currently displayed, and thereby avoiding the
annoying flicker effects associated with showing a partially-drawn image. This technique is called double-buffering.
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. Palettes
are often used to reduce the amount of memory necessary to describe an image, and are thus useful on embedded
devices even today. For your final projects, some of you may want to play with graphic techniques such as palette
color selection to best represent a more detailed image and dithering to map a more detailed image into a given palette.
- 经济Economics
- 金融Finance
- 会计Accounting
- 工商管理Business Management
- 计算机computer science
- 商业分析business analysis
- 法律Law
- 管理Management
- 市场营销Marketing
- 哲学Philosophy
- 心理学Psychology
- 物理Physical
- 统计学statistics
- 电气工程electric engineering
- 化学chemistry
- 生物biology
- 数学mathematics
- 语言学linguistics
- 土木工程civil engineering
- 工程力学engineering mechanics
- 艺术art
PROFESSIONAL HELP!
在线咨询
立即下单
Wechat：THEend8_ 
Email：