TV Jezzball with dangling mouse, created by Cornell ECE476 students Arthur Zhang and Yewen Ying, is a hot, new, cool, retro look back to when times were simpler, computers were slower, and TV’s were black and white.
From the beginning, because of our interest in computer games, we wanted to make a fun game that we could play on the television. However, each time we came up with a seemingly great idea, we checked the past final projects and found that it has already been done. Idea after idea was shot down, until finally, after many hours of discussion, we finally came up with the idea of Jezzball. We checked through most of the past final project web pages and did not find any other people who had done this project before. It was perfect! (For information regarding what the game Jezzball is, just use Google to search “jezzball” and plenty of information will come up with respect to the classic game and new variations that have resulted from it).
We used two MCU’s: one to interface with the mouse and one to generate the television signals. The two MCU’s communicated via SPI (Serial Peripheral Interface). Our final version is very similar to classic Jezzball but has slight modifications that we felt made the game more playable and was more reasonable to implement.
For our final project, we knew we wanted to construct a video game that had not been made before in ECE476. While brainstorming for project ideas, we came up with many games, but they had all been done before. After many attempts, we came up with Jezzball. It seemed like a good choice to us, because it was a game that we had both enjoyed as a child, and we felt a nostalgic impulse to recreate the classic game. Since we had both not played it in such a long time, we searched online for a freeware version of the classic game, but were only able to find various adaptations, that we felt didn’t do the original justice. This compelled us even further to complete the game, not only for our enjoyment, but for the pleasure of all classic gamers out there.
The recreation of Jezzball consisted of using two Atmel Mega32 MCU’s on prototype boards, an old PS/2 mouse, and a black and white TV. One of the MCUs is used to control the logic for the actual game play and outputting to the TV. The other is used to interface with the mouse. We communicated between MCU’s using the built-in SPI. We chose this method of communication as opposed to the UART or just using port pins because SPI provided a synchronous and fast transmission. We were forced to use two MCU’s because outputting video to the TV is very time critical (each frame must be timed and synced), and we could not add mouse input on top of the already processor intensive Jezzball control logic.
Outputting to the TV, we generated a non-interlaced signal that consists of a sync and a video signal. Our signal differs from the NTSC standard interlaced signal in that we generate pairs of lines of the same pixels where the NTSC would have generated alternating lines of pixels. We used a standard RCA cable to connect to the TV video and sound.
Communicating with the mouse involved using the PS/2 mouse protocol for a standard 6-pin Mini DIN. This is discussed in more detail in the hardware design section.
Although Jezzball was originally created and copyrighted by Microsoft in 1992, it has been adapted many times since its creation. We feel we did not violate any copyrights, as modified our version from the original, and do not intend to profit from the game in any way besides our final project grade and our own satisfaction.
Our implementation of Jezzball used two MCU’s, one to connect to the TV, and another to the mouse. They communicated with each other using the SPI. The overall circuit diagram is found in our Appendix.
The TV setup is the same as in our video game lab. We used PORTD.5 for generating the sync signal, PORTD.6 for the video signal and PORTB.3 for input of sound into the TV. The two video signals are summed together in the following manner:
The Input to the TV is through standard RCA connectors with one end stripped to allow us to connect directly to the lines.
To control the game, we used a PS/2 optical mouse. The mouse is connected to our MCU by way of a PS/2 connector that we scrounged up from a previous year’s project. The mouse and connector have the following pin outs:
Figure taken from: http://www.computer-engineering.org/ps2protocol/
We connected the data line to PORTA.0 and the clock signal to PORTA.1 and powered the mouse with the MCU power. Communication with the mouse is done by sending back and forth data packets. The mouse MCU sends packets of 12 bits: 1 start bit, 8 data bits, 1 parity bit, 1 stop bit, and 1 acknowledge bit. The mouse sends packets of 11 bits, including all the bits mentioned earlier, minus the acknowledge bit. When the mouse sends data, it sends 3 bytes of data seen below.
The x-direction and y-direction is encoded using 9 bits in two’s-complement notation. We initialize the mouse by resetting it. This entails sending to the mouse 0xFF, then reading the acknowledge from the mouse (0xFA). We then send the mouse to remote mode by sending 0xF0, and again reading the acknowledge from the mouse. The remote mode is used so the mouse only sends data when requested by the MCU sending a 0xEB byte to the mouse. We then pull the clock low for 100ms to inhibit any transmission.
To request data from the mouse, we send the mouse the request byte. We then wait for the acknowledgement followed by the three data bytes, which we convert to the x and y-directions and the mouse button status. This procedure is explained in the Software Design section.
Further restrictions on mouse timing, as well as a step by step implementation procedure can be found at the mouse protocol website found in our references.
The four most important parts of the code were:
- Mouse code
- SPI code
- Jezzball game code
- TV video code
The implementation of the mouse was done by adapting code from the previous years Paint Program with Mouse Control by Steven Keiper and Ragavan Mahedevan. We used their functions: mouse_send, mouse_read, update_cursor, poll_mouse, and reset_mouse. The mouse methods were originally written by Chee Ming, Chaw and Elaine Siu for their TV Minesweeper.
Sixty times every second or every frame, we poll the mouse for data and update the cursor position on the Mouse MCU, and send off the three bytes of mouse data to the TV MCU. Polling the mouse and updating the cursor position is done when the TV MCU is generating the viewable video signal to the TV.
The poll_mouse method, sends a byte to the mouse requesting data, reads the acknowledgement from the mouse, and then the three data bytes, every time we wanted input from the mouse. In the modified update_cursor method we save the last cursor position, update the new cursor position from the mouse data that we’ve received, and error check to make sure the mouse has stayed within the bounds of our game. We then shift the cursor position to the right one byte to reduce its sensitivity and convert. This is purely for ease of game play. We also read in the state of the mouse buttons to transfer over to the TV MCU.
After the TV MCU receives the data, we had to debounce the mouse buttons or else we would detect multiple button clicks for each valid user click.
For more detail: ECE 476 Spring 2005 by Arthur Zhang (ayz2) and Yewen Ying (ydy2)