Soccer Shootout
Our project idea was to create a game that would simulate a soccer penalty shootout. It was our goal to allow a player to kick a ball while another person played goalie in order to simulate the shootout. The ball kick and keeper dive would then be displayed on a graphics display. The game would also keep score and declare a winner at the end of the shootout.
The user will interface with the game by kicking a soccer ball that will enclose an accelerometer to determine position the shot will go towards the “goal”, which ended up being a fixed direction on the pool noodle to maintain the right orientation on the accelerometer . A Nintendo 8 controller will be polled for the second player to control the keeper’s attempted save. These signals would then be processed and simulated on the field, containing the goal, the ball, and the goaltender, which is then shown on a Graphics Display.
Tasks completed by Matt:
Tasks completed by Tim:
Nintendo 8 Controller
The hardware for the Nintendo 8 controller consisted of an address decoder that would trigger whenever a read to address 0x02600000 occurred. Once this was decoded the last value in the shift registers would be put out onto the bus. Simultaneously, our verilog logic would begin to create the 12 us latch pulse followed by 8 6 us pulses in order to read the current status of the controller. These pulses cause the Nintendo controller to send back whether or not each button is pressed. This data was then stored into a shift register to be read the next time a read of the appropriate address occurred. In order to control how often we read the Nintendo controller a timer was used that would cause a read to occur every 30th of a second.
Accelerometer
The accelerometer we chose was the ADXL202EB. This accelerometer creates PWM signal that represents the amount of acceleration it detects. We placed the accelerometer near the end of a noodle tube in order to measure the acceleration of the ball. In order to use our accelerometer, we again created an address decoder that would trigger whenever a read to address 0x02900000 occurred. This allowed the current value of the x-axis and y-axis to be read onto the data bus. In order to trigger an ISR whenever the ball was kicked, we created hardware that would detect the rising edge of each PWM signal. This would begin a counter that would be compared to our determined trigger value. If the PWM signal had a positive length greater than our threshold an interrupt on IRQ1 would be asserted signifying that the ball had been kicked.
Graphics Display
The hardware for our graphics display again consisted of an address decoder that would create the appropriate signals based upon a read or write of address 0x03400000. The address 0x03400000 was used to write commands and to check the status of the display and the address 0x03400004 was used to read and write data from the RAM. After anytime the display was written to or data was read from it was necessary to check to statues to make sure that it was ready to transfer any more data. Because the display could read and write data it was necessary to use the bi-directional buffer on the expansion board, which was controlled by R/WR_BAR.
Nintendo 8 ISR
The Nintendo 8 controller was read by using a timer that would trigger every 30th of a second. When this timer caused an interrupt this ISR would be called and the value of the controller buttons would be read. These values would then be inverted, due to being received as active low. If no buttons were pressed the ISR would quit. If a button had been pressed the value of all buttons would be stored in a global variable and a flag set to assert that there was new data. This ISR was written in assembly.
Accelerometer Software
The software to deal with the accelerometer had two main pieces. First, once the hardware generated an interrupt on IRQ1, an ISR would be called that would switch to a second timer (not the timer used for the Nintendo controller) and mask out other interrupts. The second piece is the software to deal with the interrupt created by the timer. This interrupt would read the values generated by the accelerometer. It would take 100 samples over one period of the accelerometer in order to get the duty cycle of the PWM signal. It would take these 100 samples 3 times in order to give us 3 samples of the PWM signal from which to determine the direction of the kick of the soccer ball. All of these samples are stored as global variables and a flag is set in order to determine when sampling is finished. Both of these ISR’s were written in assembly.
Graphics Display Software
The Graphics Display software was fairly split between assembly and C. First the initialization sequence was entirely written in assembly, it could have been written with the functions written later on to simplify, but we wanted to have something that was 100% working to start the board. We wrote a status read function to simplify future status reads and save space. We also wrote command write and data write functions to be called in C. To finish assembly we wrote functions to clear text, clear graphics and set the address pointer. C was used to draw all of the graphics including the field, the ball, the goalie, and any text we wanted to output. We also wrote a delay function to be able to control the speed that the screen was refreshed at.
General Sequencing Software
Our program begins by calling initialization functions in order to set up the interrupts and timers and the graphics display. After initialization the main game program is called which then goes through the game. This works by calling functions that display the appropriate graphics to the screen. Helper functions were also created to do the following tasks: check for start button being read, get goalie direction, wait for PWM sampling to complete, switch between Nintendo controller timer and PWM timer, and pick ball direction based upon PWM samples. The game would loop through this whole process 5 times in order to create a 5 shot shootout and then display the winner. Initialization code was done in assembly, but the general sequencing was written in C.
Button checks/PWM sampling completion
These functions basically looked at global variables that would be modified by the corresponding ISR’s. The first function would wait for the start button to be pressed on the Nintendo Controller, the second would wait for button presses to determine the goal keeper direction (left, right, or center), and the sampling completion was basically used to delay in order to make sure we had sampled the ball kick before continuing. All of these functions were written in assembly.
Switch functions
These functions were used to turn certain interrupts on and off in order to allow for easier interrupt handling. Thus when looking for start or the goalie direction only Nintendo controller interrupts would be allowed and while getting the kick direction only accelerometer interrupts were allowed. These functions were written in assembly.
Pick Ball Direction
This function took the 3 samples from the accelerometer and determined the ball direction. This was done by comparing the 3 samples and looking for a consensus direction based upon are knowledge of common results for a kick in each direction. This function was written in C.
Our original project design used an additional interrupt for the Nintendo controller we would have requested a read of the controller and it would have asserted an interrupt one the data was ready. However, we were having trouble clearing interrupt due to problems in hardware, so we switched to the previously described way of controlling it. We had some difficulty initializing the graphics display due to assuming the wrong endian. In the end though are project worked how we wanted it to
The final version of our game worked extremely well. Given our components it is possible to implement the soccer shootout game, however a different accelerometer might give better results for distinguishing between ball kick positions. We found that it was especially hard to distinguish between what would be a high kick (a harder kick) and a low kick (softer kick). A better accelerometer might also allow for more position along the x-axis as well.