Weeboy A portable, color, tilt-controlled video game system

An ECE 476 final project
by Christian Montoya (cmm98) and James Luk (jl478)

Introduction

The Weeboy is a portable color video game system that is not dependent on stationary displays or external power sources and features novel tilt-based control.

Our purpose for designing this project was to demonstrate that a complete portable video game system could be implemented at an affordable price. There currently exists a large community of "homebrew" and DIY video game hobbyists who develop their own games for portable consoles. This practice is usually very expensive, as the total hardware required can cost more than $150 (the GP2X, a programmable linux-based portable console, costs $189.99. Programmable 2G flash cartridges for the Gameboy Advance cost $137.26, which does not include the price of the console). By pulling together a handful of low-cost parts and building the system ourselves, we have demonstrated that a complete programmable portable console can be had for less than $70, even when purchasing the parts we sampled. Our implemenation runs on a single 9V battery and features tilt-based control, monophonic sound, and 3 playable games. We call it the Weeboy because it combines features of the Nintendo Gameboy Color and the Nintendo Wii.

High Level Design

Our original source of inspiration for this project was the Color LCD 128x128 Nokia knock-off which Professor Land recommended from the ECE 476 web page. This LCD was intriguing because it supported color, was inexpensive, was small enough to fit inside a small container, and had a good amount of sample code which was contributed by the hobbyist community. In our efforts to come up with a novel design project related to video games, we realized that a portable standalone console had not been attempted before and it was obvious that this LCD would be perfect for the project.

From the beginning we planned to use a total of 6 push buttons to control the system, but Professor Land informed us that he had sample accelerometers from Freescale which could be used for tilt-based control and we opted for one of those to replace four of our buttons. This was ideal because it saved us $4 in our budget and it made the user experience much more novel and exciting.

The rest of the parts, including the speaker, container, and battery, were components that we expected in our initial write-up for the project and we were able to afford everything within our budget.

The complete system functions as such: the Atmel Mega32 microcontroller contains all the code for controlling the system as well as backgrounds and a font stored in flash memory. The accelerometer is an input to the Mega32 which is sampled by the on-board ADC. This data is used to check whether the user has tilted the system, and the direction of the tilt translates to movement in-game. There are also two push buttons at the front shoulders of the container which are used for actions on the menu and in the paint game. The Mega32 draws the display by sending coordinates and colors to the LCD via the SPI. The Mega32 also outputs sound with the PWM to a small piezoelectric speaker. The system is powered by a 9V battery on a board which was also a sample from Freescale. This board provides a regulated 3V supply for the LCD and accelerometer. It is also connected directly at the 9V head to the PCB which holds the Mega32.

On starting the system, the user is prompted with a menu where the left button is pressed to select from the three games or toggle the sound and the right button is pressed to start the selected game. In the first game, called "Dodge," the user tilts the system to avoid two balls coming towards the player from the top of the screen. Holding the right button slows the balls considerably. Upon being hit, the player dies and the score and high score are displayed. Pressing the left button returns to the menu screen. The second game, called "Tunnel," is very similar except that the player is trapped in a tunnel of missiles that move side-to-side on the screen. Also, the player can only move horizontally in this game. The third game, called "Paint," does not have a win or lose condition and is more of a toy. The user can tilt to move a cursor around the screen. The left button is used to change the current color and the right is used to draw a colored block at the current location. The user can point at the top bar and press the right button to return to the menu screen. Upon exiting Paint, the complete canvas is preserved.

The software for the system is based on a simple function for sending a color to an x,y position on the LCD screen. From this, functions for drawing sprites, background, text and random colors were developed. The main challenges were speed and memory space, and the techniques used to overcome these challenges are explained in the following section.

There were serious hardware and software tradeoffs that had to be made in the high-level design of our system. The LCD itself is much slower than a standard NTSC television display, so we did not have the option of updating the entire screen at 30 fps during operation. We had to draw as little as possible on each update of the screen. Also, because the Mega32 has a limited amount of on-board flash memory and we could not afford more with our budget, we could not make any games with a lot of map data, sprites, or varying backgrounds to store. Also, even though the LCD can support 4,096 colors, we had to stay in 256 color mode to keep it running fast.

There are no standards relevant to our design. All code in our project which was written by others was released under a GNU General Public License, so our code is also placed under this license. An issue of copyright concern would be the images and sounds used for the backgrounds, sprites and music in our games, which were based on sprites, images, and sheet music found on the web, but we believe that our work constitutes fair use since all music and images in our games are very simple digital representations. They are not direct copies and are only used for the purpose of demoing the complete project. If, however, this project became a mass-market product, all images and sounds in the system would have to be completely original.

Program/Hardware Design

The first pieces of hardware we obtained were the color LCD and carrier board. Christian found the LCD on Professor Land's website, and we decided to use it because example code was available for the Mega32. We also bought the carrier board because we were not sure whether we would be able to solder the tiny LCD pins onto our own board. The carrier board allowed us to connect to the LCD with six pins, and it contains a voltage booster for the backlight of the LCD which boosts the 3.3V input to 6.7V. The LCD easily snaps directly onto the carrier board. During testing we connected the LCD on port B. We powered the carrier board with 3V from the variable power supply board. After soldering the six wires, loading the correct code for the LCD, and connecting the LCD to the correct port pins, we were able to display a multicolored box on the screen, just like the examples provided on the web. After this, we looked for the tilt sensor that Professor Land talked about in class, but he recommended using an accelerometer instead, since it came as a sample from Freescale Semiconductor and could be used just like a tilt sensor. It was actually better than a tilt sensor because we could detect variable tilt in both axes. We connected the accelerometer to the ADC on-board the Mega32 and we used the same ADC code that we used in previous labs to get the x axis of the accelerometer working correctly. We soldered a wire from the x_out of the accelerator and connected it to A.0. We used the test code from Professor Land to display the ADC readings in hyperterm. We found that it read around 65 when flat, 35 when tilted 90 degrees and 95 when tilted -90 degrees. We then made our first "sprite" move left when Ain was less than 55 and move right when greater than 75. This implementation was exactly how we would have made our project work if we used a tilt sensor instead. We then found that changing the ADMUX would change the port pin read by the ADC, so we were able to read the y-axis as well. We soldered a wire from Y_out and connected that to A.1. To read both axes concurrently, we set up our code to alternate reading A.0 and A.1 on each iteration of the while loop. Since there is enough code in between iterations, the 200 uSec wait time needed between switching the ports and reading on the ADC is hidden in the code. Our initial code was able to move on both axes with near immediate response, and even both at the same time for diagonal movement. It should be noted that the response in the "tunnel" game appears a big sluggish compared to that in the "dodge" game; this is due to the fact that the "tunnel" game has more being updated on the screen on each iteration. Sampling only on the x-axis for "tunnel" was our way of reducing that sluggish response.

With these tests completed, we went into game designing mode and came up with two games. In order to get complex backgrounds, we used the lcdphoto utility provided by Cathy (see references). We converted our images to Photoshop RAW format and then converted them to matrices with lcdphoto for use in our code. Next we took a sample 9V board from Freescale and successfully used it to power the LCD and accelerometer. We found, however, that the devices were capable of draining the battery very quickly, so we did the majority of our testing with the external power supply.

We then approached the task of selecting the right circuit board for the Mega32. We thought about making our own solder board, but Professor Land advised us that these usually do not work and we went with his custom PC board. We soldered all the components described at the custom PC board page except for the RS232 serial adaptor and serial connection. We used machine socket pins for the ports in case we needed to change the ports during development. Since the PC board uses port B during programming, we moved the LCD to port C. Plugging the wires into the sockets and making a good connection was a real challenge, and on the advice of other students we used duct tape around groups of wires to keep them spaced evenly and drove the wires straight down into the sockets. During testing we used the buttons on the STK500 and connected them to port C because the buttons we ordered had not yet arrived. The buttons we ordered were single pole, normally open momentary switches. We chose them because they were a good size for a person's finger, had a bright red color, and had a thick base for screwing through the wall of an enclosure.

On the STK500 it was possible to use the AREF jumper and ground the accelerometer and Mega32 together to give the ADC the correct reference voltage. On the custom PC board, however, it was necessary to set bits 6 and 7 of ADMUX for a 2.6V reference, which again forced us to change our threshold values for the tilt control.

We then decided to add a speaker for music. We used a simple and cheap piezoelectric speaker from the lab and the code Professor Land gave us for playing music from Lab 4 which uses the fast PWM and OCR0, with the output on B.3.

Our next task was to secure a container for our project. We wanted to go with clear plastic cases that were actually intended for electronics projects, but they were too expensive. We had to search out something cheap, ideally within $3. It should be noted here that Christian originally had the idea of using a wooden box to house the system, which everyone else advised against, including Professor Land. When we went out to shop for a box, we ended up finding a wooden craft box with a glass lid that was the perfect size for our project and cost us exactly $3. Our task was then to place all the components inside this box. The most difficult component was the 9V battery board because it required a good amount of force to remove and insert the battery. We didn't want people smashing the box just to remove the battery, so we soldered springs and pieces of metal from an old RC controller battery compartment to the leads of the board to create a sort of "slide-in" battery compartment. We placed the board in the bottom left corner of the box and measured out the correct distance so that the battery would be secure when inserted. Next came the accelerometer, which had to be in the middle of the box so that the x and y axes would be in the center of the user's perspective. Professor Land gave us the idea of screwing supports into the base of the box for the accelerometer, and we found a very long nut which we secured from the bottom of the box with a wood bolt. We placed this nut a bit off center and secured the accelerometer to it from the top at one corner with a another small bolt. We then used flat head wood screws to secure the battery board and PC board to the base and covered the spots where they almost poked through the other side with a bit of cement glue so users would not cut themselves while holding the box. We used one of the empty RS232 sockets and the hole exposed from removing the power socket to screw down the PC board. When the buttons arrived we found that we couldn't use the included nuts to secure the buttons from the inside of the box, so we used hot glue instead. We had to drill very large holes for the buttons, using both the drill bit and the round sander bit on the Dremmel tool, and we attached them on the front shoulders of the box (away from the user) so they could be reached with the pointer fingers.

We also cut a square hole for the LCD to show through the wooden separator underneath the glass lid and drilled a round hole in the front for the sound from the speaker to come out of the box. When we added the LCD, we found that we did not need to secure it to the lid of the box or even to the base, since it did not move around where it sat. With the large capacitor bent downward and the 6 wires connected on the header of the carrier board, the LCD was as secure as it needed to be right above the accelerometer and it showed through the lid perfectly. In testing the system, we found that the 9V battery could be drained very quickly by the three components using it, so we added wires for an external DC source connection and drilled a groove into the right side of the box to make them accessible while the box was closed.

In the process of developing three different games with unique functions for displaying on the LCD, our code became both complex and very meticulous. There are a handful of functions which serve only one purpose in a single game, but this approach allowed us to keep the logic for our three games separate and optimize for speed in every case.

Since the LCD has its own memory buffer, we did not use interrupt-based timing for the display. We decided that throughout the game logic we could simply send updates to the LCD as they happened, which worked all right as long as we were not trying to draw too much at once. The LCD itself happens to be very slow, much slower than an NTSC television, so games are only feasible if a small fraction of the screen is being updated at a time. In hindsight, it might have been better to use interrupt-based timing to update the LCD, but we were able to optimize for the speed of the LCD and keep our timing consistent enough that we had to add hard-coded delays to the first two games in order to make them playable. In the long run, programming for the LCD is much less processor-intensive than NTSC TV because everything only needs to be drawn once, which leaves more time for other logic.

Here is an explanation of the game logic for each game and the functions we wrote to implement them:

For the "dodge" game, the player starts at the bottom center of the screen and can move anywhere within the bottom half. Tilting horizontally and vertically translates to x,y movement. The function draw_nerd uses a state variable moveState to draw one of four sprites for the player. The sprites are stored as matrices of colors, and the sprite drawn depends on the last direction the player moved in. There are two balls which come down the screen at constant speed towards the player. They are given a random position at the top of the screen and a random horizontal speed as well. The horizontal movement is in the range of 0 to 3 pixels and is in the direction of the player. This basic AI ensures that the player cannot simply stand still and earn a high score. When a ball reaches the edge of the screen, the user gains a point and the ball is started from the top again. When the player is moved, the previous sprite must be erased before the new one is drawn, and the balls move on every iteration of the main loop. In order to demonstrate the variable response of the accelerometer, we gave the "dodge" game two tilt threshold values on each axis, so tilting the container slightly moves the player by 3 pixels, while tilting the container further moves the player by 6. The balls move down by 6 pixels on every iteration, except when the right button is held; then the balls move down by 1 pixel at a time. This is called "matrix time" and is very helpful when demoing the game. Collision detection is constantly checked between the player and the two balls, and collision with a ball moves the game into the "dead" state, in which the high score is updated and the score and high score are displayed.

For the "tunnel" game, the player starts at the bottom center of the screen and is restricted to horizontal movement. The walls on each side of the player are stored in 2 arrays which are 10 indices long; the value stored in each index is the x coordinate of that segment of the wall (specifically, a missile) and the index itself is multiplied by 12 to get the y coordinate of that segment. Only the top left piece is randomly moved right or left on each iteration; the top right piece is kept a set distance from the left and the values for both walls are passed through the arrays on every iteration. As the game progresses, this width between the top two indices decreases from 64 pixels to 16 pixels. The player's ship is 12 pixels wide. The walls are kept within the screen's boundaries and the random direction of the top left wall segment can only be changed on every other iteration, so there are no runs of back-and-forth left-right wall movement (which would act almost like a straight tunnel). Collision is checked with the last indices in the left and right walls, and on collision the game moves into the "dead" state, which is indentical to the dead state for the "dodge" game. The function DWall is used to draw each segment of the wall from the array. The index is multiplied by 12 to calculate the y position on the screen, and the functions draw one sprite for odd y values and another for even y values. The two sprites make the missiles which make up the walls and look as though they are rotating as they descend. The function DShip draws the sprite for the player's ship.

The collision detection in both games is basic "bounding-box" collision, where the sprites are treated like rectangles and the locations of the edges are compared. This works well for our implementation since pixel accuracy is not necessary to correctly find a collision.

Both of these games use backgrounds which are stored as 65x65 matrices of colors. Even though the screen is 130x130, storing matrices of that size would be too much to fit in the available flash memory. Therefore, we have to use a draw_bg function which doubles the background image as it draws to the screen. We found that we can draw to a pixel and then send another color to draw the pixel to the right of it, and we exploited this optomization in all of our display code. The draw_bg function draws each pixel at point i,j, then i,j+1, then i+1,j, then i+1,j+1, where i is the y coordinate. Both of these games also have to erase sprites when they move, and this requires redrawing the background where the sprite once was. To do this, we took the x,y coordinates where we need to erase, shifted them right by 1 to divide them by 2, and then took the colors from the 65x65 matrix and doubled them on the screen. In the event that x or y was odd, we had to add 1 to the indices in the background matrix to get the adjacent colors to be placed on the screen. Another way we optimized the sprite drawing was by defining the color 0x01 as "trans," or transparent. Wherever this color was stored in sprites, we skipped drawing so the background would still show through.

For the "paint" game, there is no background. Instead there is a 26x20 "canvas" matrix which the user edits. This canvas starts white and each index represents a 5x5 square on the screen. This makes it easy for the user to draw across the screen in a reasonable amount of time and because the matrix is stored in RAM, the small size does not fill up the RAM. Pressing the left button cycles through an array of available colors, 8 in all, and pressing the right button fills the current color in the current square. The draw_canvas function draws the canvas from 30 pixels off the top of the screen in similar fashion to the draw_bg function. There is also a function draw_topbar which fills the top 30 pixels with black. Finally, there is a function draw_cursor which draws a crosshair within the 5x5 square. The lines are the currently selected color and the center is black as long as the user is in the canvas. When the user moves to the top bar, the cursor is all white. The user tilts to move around the screen and the position is indexed as 26x26, then multiplied by 5 in each direction when drawn on the screen; this goes along with the size of the canvas. Since the canvas can be changed often, it must constantly be redrawn, but to save time it is drawn on every other iteration and it is only drawn when the cursor is in it. When the cursor is in the top bar, it is also redrawn continuously, and the user can press the right button while within the top bar to exit the game. The canvas is available again when the user returns to "paint."

The menus use font text for numbers and capital letters stored as 6x6 matrices in Flash. These were originally drawn true-to-size on the screen, but this was found to be too small for most people to read. Therefore, these letterforms are doubled when drawn on the screen, which makes them legible. The menu always has a random background color which is generated with the gen_color function, which avoids colors which are too light compared to the white text. The function fill_screen is then used to quickly fill the screen with the random color, and text is drawn on top with LCD_say. There is also a triangle which is drawn on the side of the main menu to show the currenly selected game. For every display function, there is an equivalent erasing function for drawing the background or the current random color back in place. Finally, there is a running counter in the timer 0 ISR which is used to seed the rand() function when the user presses the right button to start a game, as well as debouncing logic for the buttons, and there is code for playing music which we took from Professor Land's video test code from lab 4 that is used to play songs in each game.

All of our display code is built on code by Refik Hadzialic, who derived his work from code by Thomas Pfeifer and Owen Osborn. Refik's code is contained in basic.c and contains functions for sending data and commands via the SPI and drawing a single pixel on the screen. The initialize() function also has Refik's commands for starting up the LCD. A utility by Cathy, lcdphoto, was used to convert images in Photoshop RAW format to matrices for the LCD.

It's worth mentioning all the problems we had in developing this project. For the first week we were completely unable to get the LCD to work. We were using the sample code provided by the supplier, but we did not realize that there were two versions of the LCD being sold on the market, one with a Phillips controller and another with an Epson controller. The sample code turned out to be intended for the Phillips controller, which we discovered when new code inteded for the Epson controller worked for us. We would have saved a week of frustration if we had known this earlier. Even with the correct code, there was always the issue of adjusting the contrast, which is done in hardware. At the very bottom of main.c is a loop that increases the contrast, and we found that we needed more contrast than what Refik and others working with these LCDs had used. The initial working displays on the LCD showed moving waves across the colors, which we eliminated by adding 100 uF capacitor between Vdsp and Gnd as per the supplier's recommendation. We had ongoing problems during testing with loose connections, especially when using alligator clips. If the LCD lost power for even a second, it would reset and stop working. This is why all the connections in the enclosure were meticulously soldered.

On the last day before our demo, we had all the components in the box except for the switch which Professor Land recommended for the custom PC board. At one point we placed a 9V battery into the battery board backwards with the battery board switch on and fried the voltage regulators on the battery board and the custom PC board. Without the voltage regulators, nothing worked. This was a huge setback and we had to solder new regulators onto the board after we had connected all the components. In the end, almost everything that went into the enclosure had been de-soldered and re-soldered at least once.

The final setup for the hardware was battery board on the bottom left, custom PC board on the right, accelerometer in the middle, LCD above it, speaker at the bottom standing on its side, and buttons connected through the top edge. The custom PC board was placed so that the power connections were at the bottom, since most of the connections we used were on ports A and C. Someone rebuilding our setup, however, would only need to follow the connections in our schematic, since it would probably be better to design a new enclosure setup.

Results of the Design

Since the framerate of the LCD is so low, there is considerable flickr during animation which cannot be helped. As for response to user input, we were able to set up our debouncing and sampling on the accelerometer to make the input response nearly immediate throughout the system. The only exception would be in the "paint" game, where so much is being drawn on the screen that the response to user input is slightly sluggish. As for accuracy, the only portion of normal operation that must remain consistently accurate is the timing of each game. This is maintained by drawing only as much as necessary on each iteration of updating the LCD, and always relatively the same number of pixels at a time. Since interrupts were not used to time the system, we simply added delay_ms calls in the "alive" states to slow each game to an ideal speed. The paint application has the worst time, but it is still acceptable because there is no lose condition that makes accurate timing necessary. The important data such as scoring and speed of movement are always accurate and the operation is free of bugs, except for one caveat: an expert user could overflow the score by reaching the maximum unsigned integer value supported by the Mega32, and the scores are printed as 3 digit decimals, so a score above or equal to 1,000 would not be reproduced correctly on the menu. As for the balance of the tilt response, we tested the tilt control extensively to find the best values for the x and y axes. We also made the response more sensitive on the positive y so users wouldn't have to lean too far forward to move upward.

There are no high-voltage or high-current components in the design, and during normal operation, all of the components are contained within the enclosure, isolated from the user. The only concern is when opening the case to change the battery or turn the system on, where the user could come in contact with electrical components. In a better implementation, the battery compartment and power switch could be isolated from the rest of the circuit, so the user will always be safe.

The system does not produce any external signals and is completely isolated, so it does not interfere with other projects. The sound, however, can be very loud and serve as a nuisance to others. For this reason we added the option of turning the sound off.

Usability of the system was a major concern since the small screen can be hard on the eyes. It was for this reason that we doubled the size of the text and made the sprites relatively large on the screen. We also tried to ensure strong contrast at all times by choosing contrasting colors for sprites and backgrounds. We then made the enclosure comfortable to be held so that users can pick it up and play it easily. We believe that the tilt-control is easy to understand and we placed the buttons in a place where they would be easy to reach.

Conclusions

Looking back on our project now that it is complete, there are a number of things we would have done differently if we could. For example, using hardcoded delays to slow down our program rather than relying on hardware-based interrupts was a bad idea. The games work fine as they are implemented now and they definitely demonstrate the power of the LCD, but if we were to make new games for this system we would definitely use ISRs. Also, we do not know how well the SPI code for our system performs compared to using the provided Codevision SPI routines, but there is a good chance that rewriting the code to use the routines would give better performance.

Aside from that, we definitely exceeded our own expectations for this project. We originally thought the LCD might be too slow for fast-paced games, but we were able to optimize the display code to make up for the low speed. We were also concerned that we might not be able to get the entire system into a portable conclusion and power it with a 9V battery, but we managed to build all the necessary components and find an affordable container. Plus, in our initial write-up we only planned to make one game, but once we got used to programming for the LCD we were able to program two more games in a short amount of time.

Still, there are many ways in which our project could be improved upon. While the system can function on a 9V battery, a single battery cannot last very long with the LCD, accelerometer, and Mega32 drawing from it. One improvement would be to power the system with multiple batteries, or even with a rechargeable battery pack that can provide more current. More games with more complex algorithms could be implemented, such as sophisticated enemy AIs, graph-searching, and even 3D graphics. With an external Flash memory component, map and sprite data for a wide array of levels and enemies could be stored and used to make a more complete game. Even multi-layer sound could be implemented to use MIDIs for the game music.

On the topic of Intellectual Property, all of the code we used in our project from others was released under the GNU General Public License or provided by Professor Land. The only exception would be the font used for letters and numbers on the screen, which was an original design by Christian Montoya. The music sheets and images we used for our sprites, backgrounds and sounds could not be used in a marketed product, but they were appropriate for the purposes of demoing this project as students. There may be some opportunity for patenting the completed design of our enclosure or the concept of making a tilt-based portable console, but we would have to research similar patents to see if our ideas are really original and novel.

In regards to the IEEE Code of Ethics, we believe that we followed the complete code throughout our project. In designing our console, we ensured that the enclosure would be safe to users by making it free of sharp edges and splinters. We also avoided any high-voltage or high-current components which would be dangerous to users, especially children. In basing our code on the work of others, we made sure that all the code we used was provided under the GNU General Public License or free for use. We also communicated directly with Refik Hadzialic and told him about our intentions for using his code, which he approved of. We were honest in our claims for what this system could achieve, and our documentation explains what this system, especially the LCD, is not capable of. We were honest about reporting all the costs of our components and we did not attempt to cover up our costs to keep our project within the budget. We believe that our project is useful to others and can improve the understanding of technology, especially as an educational tool. Students can build the hardware setup on a small budget by following our instructions and program their own games for the system, which teaches them both hardware and software skills. We challenged ourselves and improved our technical competence with this project, exploring new programming concepts and hardware techniques that we had never tried before. We sought constant criticism for our project by inviting teaching assistants, classmates, and visitors to test our system while we were developing it so we could get their feedback. Incremental testing was a focus of our project and observing the way others used the system gave us a good idea of how to make the system more usable. Our system treats all people fairly, but it could definitely be improved with multi-language support.

Media

We kept a photo and video record of our project throughout the development process. All videos have sound.

Local files: (images link to full size pictures)

• Final demonstration video (68 MB)

External files:

• Photo gallery at Flickr.com
• "Working Test 1" video at blip.tv
• "Working Test 2" video at blip.tv
• "Working Test 3" video at blip.tv

Commented Program Listing

All of our code is contained within the following 9 files. All logic and functions are heavily commented in order to make our thought process easy to understand.

• main.c (998 lines)
• basic.c (103 lines)
• fonts.c (282 lines)
• dodgeball.c (193 lines)
• tunnel.c (479 lines)
• display.c (283 lines)
• paint.c (155 lines)
• music.c (33 lines)

Schematic

Our complete circuit layout is available as a PDF document or PNG image.

• Weeboy Schematic, PDF (15 kB)
• Weeboy Schematic, PNG (38 kB)

Cost Details

Part	Cost
Color LCD	$19.95
LCD Carrier Board	$14.95
Mega32	$8
Custom PC Board	$5
Wooden Box	$2.99
Pushbuttons	$2 ($1 each)
9V Battery	$2
Piezoelectric Speaker	$1
Accelerometer	$0 Sampled (Freescale)
9V Battery Board	$0 Sampled (Freescale)
Total	$55.89

It should be noted that the accelerometer and 9V battery board can be purchased for less than $15. Anyone wishing to build the complete circuit could easily do it with a budget of $70.

Specific Tasks

Christian Montoya was responsible for the font and background functions as well as the programming for the "dodge" and "paint" games. James Luk was responsible for the hardware planning and color testing as well as the "tunnel" game. All other tasks, including soldering, woodworking, programming the majority of the logic and building the components, were shared equally by both members of the group.

References

1. Color LCD Product Page
2. Epson Controller datasheet (for Color LCD)
3. Color LCD Carrier Board Product Page (includes datasheet)
4. Red pushbutton (no datasheet)
5. Controlling a color graphic LCD, Epson S1D15G10 Controller, with an ATMEL AVR ATMega32L, Refik's page and sample code
6. Mega32 with sound test code for music
7. Sample Atmel AVR Code for the Spark Fun Nokia-like graphic color LCD, Cathy's page with full download that includes lcdphoto utility.