Course Project - Agra: Objectives
Course Project - Agra: Objectives
Course Project - Agra: Objectives
Objectives
● Apply all the skills learned in the course to develop software library in Assembly
language
● Learn about a test bench
● Learn about graphics primitives
● Optimize the code for speed, avoiding costly instructions
Description
Develop agra - a graphics library of functions in Assembly that could be called from C. The
functions implement drawing operations on a graphics buffer in memory. The graphics
primitives to be drawn are:
● A point (a pixel)
● A line
● A circle, not filled
● A triangle, filled
You should also develop a C program that tests the library by calling its functions to draw a
picture.
You must create the following files with these exact names:
● Makefile - the makefile used to compile and test your program
● agra_main.c - the main C program for testing the library
● agra.s - the Assembly program, implementing the graphics primitive drawing
functions
● agra.h - the header file with the prototypes of the Assembly functions, in C
● framebuffer.c - the implementation of buffer access functions, in C
● framebuffer.h - optional
● report.pdf - the report about the accomplishments of the project
All the files must be in the directory named agra under your home directory on the course
server.
Data Types
The data types and the prototypes of the functions to be implemented in Assembly are
declared in the file agra.h, and should be as follows:
Suggestion: start the development by ignoring the operation op field, assuming that the
operation is always to replace - “paint over” the contents of the frame buffer. Once you have
this functionality up and running, see to the implementation of the various operations as
defined in the “pixop_t”.
Frame Buffer Access Functions
Your library functions must use the following FrameBuffer functions to access the frame
buffer and to determine its properties.
FrameShow() should assume that the (0,0) coordinate is at the top left corner of the frame.
In all cases when the return value type is int but it is not described, 0 means success, and 1
means failure.
Color coding
In a general case the framebuffer would stream the contents of the buffer to a real graphical
display, such as LCD or OLED screens. However, for testing purposes in this project, the
frame buffer contents will be represented using characters when printed. Each pixel is
represented by one character.
Use the following encoding for the pixels, when printing them:
● The black color is a space ' ' (black)
● The white color is a star '*' (white)
● Use the corresponding characters if the dominating color
is as follows:
○ 'R' (red)
○ 'G' (green)
○ 'B' (blue)
○ 'C' (cyan)
○ 'M' (magenta)
○ 'Y' (yellow)
A color is considered dominating if this color has the most intensity. This could be observed
with a help of a color cube, where each of the RGB components is a coordinate on one axis
of the cube. One might ask, how do we determine the dominating color if each component
has 10 bits? A possible solution is to divide the RGB cube with three planes so that you end
up with 8 smaller cubes. Then assign one dominating color for each of the small cubes. A
crude approximation would be normalizing each of the RGB components to a single bit (e.g.
taking the most significant bit). Then RGB will represent a 3-bit combination that determines
which of the 8 colors is dominating.
Test bench in C
The Assembly program should be wrapped in a main program written in C. The main
program will parse the arguments and prepare the memory buffers as needed. It will also
print the results.
For this task, the main program will act as a test bench - the environment for testing your
library. It will create a graphics buffer in memory that will be passed to the library function
calls. Then it will call the library functions in succession to draw a picture on the memory
buffer. Finally it will print the buffer contents to verify the result of the function calls.
Error handling
The following situations may happen and should be handled accordingly:
● If a pixel for any primitive is drawn outside the buffer dimensions, the pixel should be
ignored (not drawn). Thus, you may have a primitive that is just partially visible on the
buffer.
● If a function is called with incorrect parameters, it should do nothing and just return.
Testing
The programs should be compiled, linked, and tested with the qemu-arm emulator.
When testing, the arguments should be passed on the command line, as in the example:
In the example above outfile.txt is a file where the result should be written.
The Report
You should write a report about your project and save it to a file in PDF format.
The report should contain the following:
● What functionality has been implemented? How is it implemented?
● What is not implemented, and why?
● What was the biggest challenge in the project?
● What would you do differently next time?
● Other comments.
Even though the report should be submitted in a written form, you should also be ready to
discuss your solution with the instructor during the exam.