I'm thinking about making an AVR (non-Arduino) portable game console. I'm evaluating the type of display to be used (including multiple 8x8 LED matrix, graphical LCD, TFT/OLED screen, alphanumeric LCD and combination of them). Then I came up with a weird idea. What if I use a alphanumeric LCD as a graphical LCD? That'd cut me quite a bit of the cost compared with using graphical LCD of the same physical dimension.
I'm a bit bored today. I feel like tinkering around with Arduino and 1602 LCD that has been around in my home. Here's what I've got as a result of hours of boredom. An Arduino-based 1602 Snake Game:
Check out the source code in this github repository!
The hardware is roughly based on this official Arduino LCD Hello World tutorial, with an addition of two push buttons.
The left push button is connected to D8, while the right push button is connected to D9. Both push buttons are pulled-down. For other connections, please refer to the schematics in the tutorial.
HD44780-compatible LCD driver supports up to 8 custom characters. By carefully defining those 8 characters, it's possible to subdivide each character into multiple "pixels". That can effectively turn the alphanumeric display into a graphical LCD display.
My design subdivides each character two rows. Each row on the character can be either empty, snake, or apple as shown below:
There're two "pixels" in each character. Each pixel can have three possible values. Therefore, the total combination is 3^2 = 9. Since one of these combination is visually empty, a space character were used to represent that. At the end only 8 custom characters are needed. So the 8 available characters in CGRAM of HD44780 are just enough for our purpose.
To reduce RAM usage, each pixel is represented by 2 bits. So a byte can store 4 pixels. Everything is cramped into a
uint8_t graphicRam[GRAPHIC_WIDTH*2/8][GRAPHIC_HEIGHT]. At width of 16 and height of 4, only 16 bytes of RAM are taken for the graphic! Had I used a uint8_t for each pixel, 64 bytes of RAM would be required.
After the completion of this project, I've found other designs like spliting each character into three rows, or try making use of all pixels by generating the CGRAM on-the-fly. I'll consider using these techniques for my future projects.
To make the position looks random, we need to somehow seed the random number generator. For computer programs, we usually seed it with the current time of the machine. However, this couldn't be done on Arduino because it doesn't have a real time clock.
My solution is to make a menu screen of the game. When the user start the game, the time of the moment that the user pressed the button is used to seed the random number generator. The micros() method of Arduino Time library were used. This has the equivalent effect of using system time.
I was having fun playing with this game. I thought that it was reasonably bug-free because I had played it for a while. I've also asked one of my family members to try it out. I swear. We haven't spotted any bug.
Until I tried to record a video of the game play, something funny happened. I realized that I haven't implemented self-collision detection of the snake. I was like "Wow. How come no one had notice that earlier?". Hah. What a terrible failure!
Upon the discovery of the bug, it was fixed in no time.
Seems that using alphanumeric LCD as graphical LCD is promising. I'll consider going for this solution for the portable game console project. Of course, I won't be using Arduino for that. Arduino is good for prototyping. But it isn't as efficient as lower-level C/C++ programming.
I've played this game for many times. While it's technically possible to win, I haven't managed to do so. And I haven't tested the code of winning the game. I doubt that anyone could beat it anyway. I guess I'd just leave the code there as it is. :P
Alright. That's enough fun for today. Gotta sleep.
Hey guys! Finally I got time to blog about the technical details behind the whack-a-mole game.
Click here to view the previous part of this blog post, which is a release announcement of this game.
The game is powered by Dinbo Prototype A, which is a telephone system that I developed using SIM900A module with Raspberry Pi 3.
The schematics diagram of the system is shown below:
I knew. This system is stupid. Instead of connecting the mic and speaker of SIM900A with Raspberry Pi, GPIO is used for voice communication between them. To make the thing even funnier, an ATtiny13 is used as an ADC.
Anyway, this is just an early prototype. I just wanted to tinker around with the electronic parts that I have. And this design suits the purpose very well. More importantly, this system works. :P
Here is how does the SIM900A and ATtiny13 look like after everything is connected:
As shown above, the entire system is deployed on a breadboard.
Due to the high current requirement, multiple breadboard wires is required for the power supply of SIM900A. A capacitor is also connected between VCC and GND to smooth the voltage level over time(not shown on the outdated photo above).
Many programs were written for this system. They are ATtiny13 ADC program, serial multiplexer program, voice to socket program, and the whack-a-mole program. All of these programs are written in C.
The ATtiny13 ADC program, as its name suggests, is a program installed on the microcontoller for the purpose of converting the analog voice signal from SIM900A to time-based digital signal. When a "get sample" signal is received by PB1, it will read the analog input of PB3 send a digitized signal via PB4 to Raspberry Pi. This is the first non-Arduino embedded program I have ever developed. I had some fun on reading the specification of ATtiny13. The library avr-libc was used.
The voice to socket program is a program that converts the digitized audio signal received from the ATtiny, then send it to the whack-a-mole program using unix socket file. This is the first real time program I have developed in my life. To achieve real time execution of code, a CPU core is reserved solely for the linux process of this program.
The serial multiplexer allows multiple programs write to the serial interface of SIM900A. It redirects all of the data received from socket to the serial interface. It is adapted from this program found on Stack Overflow.
The Whack-a-mole program works by communicating with the serial multiplexer as well as the voice to socket program. It also detects DTMF tones by processing the audio signal received. Other than that, it is just like other C programs.
The source code of these programs are poorly organized. I still don't have time to package them. There are also some copyright issue on the serial multiplexer because majority of code is taken from the Stack Overflow answer with unspecified license. Therefore, I cannot release these programs too publicly. However, a copy of source code can be requested by email and they are considered on case-by-case basis.
For the final year project of my college, the development of Dinbo Prototype B is started, which will be a successor of the current system. Standard analog audio interface will be used(instead of doing the analog<->digital conversion hack using GPIOs). I also plan to solder it on a perfboard.
The library will be written in Python, which is much more flexible than C. It will be mainly designed for non-game telephone systems. However, it should be possible to make a game with it. After the completion of the library, I'll port this game to Dinbo Prototype B. I will update you guys about any news on it.
Sorry for not updating for a while guys.
Spent almost $100 on hardware and stuffs, worked for more than a month, Whack-a-mole over telephone is finally completed!
各位! 好耐無打廣東話嘅blostpost. 耗資陸佰港元. 動工參拾陸夜. 小弟嘅電話扑傻瓜終於搞掂喇!
Behold the gameplay(Cantonese with English subtitle)!
The gameplay is simple. First, dial the number 5517 6408 in Hong Kong(does not accept international call, Cantonese only). Then, when you hear certain sound, you'll have to press certain key. The sounds and the keys are randomly generated. If you press the correct one, you get a score. When it reaches the threshold, the difficulty will be increased as shown below:
Level 1: Score requirement: 0; Three random animal sounds. Each requires the player to press a key.
Level 2: Score requirement: 10; Three additional random synth'd wave sounds. Each requires the player to press a key.
Level 3: Score requirement: 30; Three additional random voice of numbers. Each requires the player to press another key that is usually inconsistent with the number that the player have heard.
Level 4: Score requirement: 60; After this level, the player has to press certain key for every 5 sounds, regardless what is the sound that the player has heard.
Level 5: Score requirement: 100; Upon hearing any of 5 random sounds, the players has to press a key. Upon hearing another 5 random sounds, the players has to press another key. Upon hearing yet another 3 random sounds, the player has to press yet another key.
遊戲玩法好簡單. 首先打5517 6408(唔收國際電話, 唔收133電話), 跟住佢就會叫你聽到某D聲就要撳某D制. D聲同D制係隨機嘅. 撳啱加分. 夠分就LEVEL UP:
LEVEL 1: 所需分數: 0; 三個隨機動物聲. 每個聲要撳一粒制.
LEVEL 2: 所需分數: 10; 三個隨機電腦合成聲. 每個聲要撳一粒制.
LEVEL 3: 所需分數: 30; 三個隨機數字聲. 每個聲要撳一粒制, 而嗰粒制通常唔係你聽到嗰個數字嘅聲.
LEVEL 4: 所需分數: 60; 每聽到五個聲就要撳某一粒制.
LEVEL 5: 所需分數: 100; 聽到某五種聲要撳一粒制. 聽到另外某五種聲要撳另一粒制. 聽到另外某三種聲又要撳另一粒制.
If you press the wrong key, or if you're too slow, then you lose. If your score is the highest among everyone else, the score will be recorded.
如果你撳錯制或者撳得太慢就會輸. 如果你嘅分數係最高嘅話, 個分將會被記錄.
Alright! That's it for the first part of the blogpost. The second part will be about the technical details of this project. See you! :)