TICTACTOE
Implementation of ArcadeGame using Blackfin ADSP-BF533 EzKit Lite
by
Shriram Kunchanapalli
PROBLEM STATEMENT:
Tic-tac-toe, also called noughts and crosses, hugs and kisses, and many other names, is a pencil-andpaper game for two players, O and X, who take turns marking the spaces in a 3×3 grid. The player who
succeeds in placing three respective marks in a horizontal, vertical or diagonal row wins the game. This
game is won by the first player, X [1].
So the idea was to design a two player game of 3 by 3 tictactoe, get a good understanding of
NTSC standard, and representation of images in memory.
DESCRIPTION:
A little about the processor:
Combines dual-MAC state-of-the-art signal processing engine, advantage of a clean,
orthogonal RISC like microprocessor instruction set, and single instruction,
multiple data( SIMD ) multimedia capabilities into a single instruction set architecture
Processor is completely code and pin compatible, differing only with respect to their
performance and on-chip memory
Blackfin processors support a modified Harvard Architecture in combination with hierarchial
memory structure.
Level1 (L1) memories are those that typically operate
at the full processor speed with little or no latency.
At the L1 level, the instruction memory holds instructions
only.
The two data memories hold data, and dedicated scratchpad data memory stroes stack and
local variable information.
In addition, multiple L1 memory blocks are provided, offering a configurable mix of SRAM and
cache. MMU takes care of operations on core and architecture offers three modes of operation.
User Mode:
Supervisor Mode:
Emulation Mode:
Blackfin processor assembly language uses an algebraic syntax for ease of coding and readibility
The architecture has been optimized for use in conjunction with the C/C++ compiler,
resulting in fast and efficient software implementation
Each event type has an associated register to hold the return address and an associated returnfrom-event instruction. when an event is triggered, the state of the processor is saved on the
supervisor stack.
The ADSP-BF533 processor event controller consists of two stages, the core event
controller(CEC) and the system interrupt controller( SIC ). The core event controller works with
the system interrupt controller to prioritize and control all system events. Conceptually,
interrupts from the peripherals enter into the SIC, and are then routed directly into
the general-purpose interrupts of the CEC.
DMA Controllers:
Processor offers multiple, independent DMA channels that support automated data transfers
with minimal overhead for the processor core. DMA transfers can occur between the
processor's internal memories and any of its DMA-capable peripherals.
DMA-capable peripherals include SPORTs, PPIs, SPI port, UART and PPI.
Each individual DMA-capable peripheral has at least one dedicated DMA channel.
ADSP-BF5333 processor DMA controller supports both 1-dimensional (1-D) and 2dimensional(2-D) DMA transfers. DMA transfer initialization can be implemented from registers
or from sets of parameters called descriptor blocks.
DMA types supported by processor DMA controlled include:
- A single, linear buffer that stops upon completion
- A circular, autorefreshing buffer that interrupts on each full or fractionally full buffer
- 1-D or 2-D DMA using a linked list of descriptors
- 2-D DMA using an array of descriptors, specifying only the base DMA address within a
common page
Processor's 2D DMA capability - allows processor to be interrupted when line transfer , frame of
a video transfer or DMA error
DMAx_XCOUNT and DMAy_YCOUNT MMRs( Memory Mapped Registers ) allows for flexible
data interrupt points
In addition to dedicated peripheral DMA channels, two pairs of memory DMA channels
provided
for DMA transfers between various memories of processor system.
Enables transfer of blocks of data between any of the memories- including external
SDRAM, ROM, SRAM and flash memory - with minimal processor intervention
Memory DMA transfers can be controlled by a very flexible descriptor-based methodology or
by a standard register-based autobuffer mechanism.
For more on memory architecture for ADSP Processor [2]
A look at the code and representation of image in the memory:
The main header file initializes the registers at the beginning and creates the video
frame using the header file code and the linker file for the VideoUtility class. A for loop is used
to display the frame for extended time.
Four functions that check the board for a win, three functions that draw shapes as per
the function and a function to switch between players with the help of few global variables
helped a lot. I tried using the inbuilt functions (in the Drawing Utility class) with the classes
designed by the University of Calgary team. The description of the functions wasn’t helpful
enough and with little trial and error, could have figured out a way to use those functions.
For representation of images in memory, in order to the even lines in the memory,
Start of Active Video (SAV): 4 bytes
End of Active Video (EAV): 4 bytes
Ancillary Data: 268 bytes
Video data: 1440 bytes
Therefore for 525 lines (the NTSC standard), the number of memory needed for a single frame
is: 525 * (4 + 4 + 268 + 1440) = 900900 bytes.
[4]
In order to reach the even lines, 20 lines needed to be skipped and 282 of 1716 bytes (NTSC
standard ) for odd lines .
An interesting project is to implement a game of DDR with the help of the UART port on
the blackfin processor, providing the visual interface thereby resulting in a low cost package
(product) with the help of ADSP BF533 Ezkit Lite.
IMPROVEMENTS:
It could have been made more user interactive and delve into AI for the computer
player implementation. To give the user option of choosing the single player to two player
options and to let the user choose the symbol of representation on the board and to choose
player turn at the beginning of the game.
-Design of code,
-functions
- lesser global attributes
Colorful background of the frame, board, borders and symbols would add to the game.
Text messages or closed captioning could have been included at the beginning and the victory
or loss messages at the end with a flashy different background. May be provide hint for the
users based on buttons.
Instead of hardcoding the values in sections of code, it could have been written in a
generic class for eg., for different screen sizes, thickness and border, background colors.
If you find any errors, have questions or need clarifications, feel free to send an email to
skunchan@fit.edu
The presentation slides for the project is also found at the web link below and viewable only on
Firefox (1.5.0.12 or higher ) , Internet Explorer( 6.0 or higher )
http://docs.google.com/Presentation?id=dgrxcskj_8cwk4mrfr
References:
[1] “Tic-tac-toe”. http://en.wikipedia.org/wiki/Tic-tac-toe
[2] BF533 - Hardware Reference Manual
[3] Compiler Manual for programming purposes (C,C++)
[4] “ECE 3552 Project – Snake “. Alexander, Todd.
[5] “NTSC”. http://en.wikipedia.org/wiki/NTSC.