LCD Blackjack by (Pipe) Brandon Backlund & (Jerome) Lujie Mo


Motivation and Introduction:

Blackjack has been an icon in the history of gambling. This simple card game has the power to change a person completely. We are therefore inspired by the blackjack, and decided to build our own LCD version of it.
The rules of Blackjack varies from player to player, and we took the most commonly accepted one. It will be explained later.

Project Equipment and Material:
Hardware:

1x target AT90S8535 microcontroller (mcu) with onboard flash program memory.
1x programmer for the target flash memory, including a serial connection to a PC.
8x general pushbuttons, 8x LEDs
1x serial connection for applications.
1x small power supply provides power to the development board.
1x prototype board. A separate power supply will be used for powering the prototype board.
Some wires.
1x 10K potentiometer.
1x digital 20 characters x 4 line LCD, Optrex DMC 20434
Software:
The AVR assembler which takes assembler source code and produces an object file, a hex file and a listing file.
AVR Studio which simulates the execution of an object file.
AvrISP which downloads the hex file to the target mcu.

Design Procedure:

We were originally interested in making a generic LCD game using the microcontroller. We envisioned using a dot matrix LCD display to make a game with custom graphics (à la Game Boy). Unfortunately, dot matrix displays are very expensive, making such a project impractical. We instead hit upon the idea of making a blackjack LCD game -- it would not need a special display and should automatically be fun to use. (An action game, on the other hand, would be tough to make enjoyable, especially with only a character-based display.)

Designing a blackjack game is obviously more of a programming project than a hardware project, but required quite a lot of work to implement. What seemed at the beginning to be a simple game turned out to be a little more complex than expected. The player chooses his own actions, but the dealer has to follow certain rules, general game scoring and other rules need to be implemented, and, most importantly, deck shuffling has to be designed.

We decided upon using Las Vegas rules for the game. The basic objective of the game is to reach a point value as close to 21 as possible without going over. Las Vegas rules means that the player and the dealer are dealt two cards each to begin, where one of the dealer's cards is hidden from the player (turned upside-down). The player then proceeds with play, choosing to take more cards if desired. After the player is finished, the dealer reveals both its cards and then proceeds to draw more cards until it has reached a point value of 17 or higher. At this point the play phase has been completed and the winner is chosen based upon the final point values of both sides. After the player has finished reviewing the results, the game is restarted with a new selection of cards. We decided not to implement all possible rules to the game, but enough to get normal functionality.

At the last moment, we received a 20x4 LCD, and that enabled us to implement a scoring system. Player starts the game with 100 points, each winning bet will earn him/her a 10, and a loss will cost him/her a 10 as well. A tie has no effect on the score. If the player reaches 0 points, the game automatically regenerate 100 points. (Free money beats real casino games!)

Program/Hardware Design:

The blackjack program consists of six states: shuffling, dealing, hit/stay, hit, stay, and winner. We stuck with a state jump table, as we have used in previous labs. The program as a whole was a bit tricky to program, as it is fairly complex and required hundreds of lines of code. Please check out our state diagram for reference.

The shuffling was achieved using a random number generator and memory storage. First a preshuffled version of the deck was stored into memory, then a random number was generated to choose one of these cards for the shuffled deck. The chosen card is removed from the preshuffled deck, and the process is repeated. For random number generation we decided to use a 7-bit RNG algorithm: a random seed is placed into a register (taken from timer 2), and every time a new random number is needed, we shift the register one bit to the right and XOR the two least significant bits of the register into the MSB. The seven bits on the right side of the register are used for the random number (though we never needed any more than a six bit number, as we only have 52 cards). It is only a pseudo-random number generator, but it works well enough for a primitive blackjack game.

The dealing state is relatively simple, assigning the first four cards in the shuffled deck memory location to both sides, and then displaying the dealt cards. The dealer has one card flipped over, shown as a black block.

Hit/stay takes player input for further state transitions. If the player chooses to hit, then the machine transitions to (logically enough) the hit state, while a stay transitions to the stay state (with no further player input). As a special case, if either side has a blackjack, the program will automatically transition to the winner state.

Hit removes a card from the shuffled deck in memory and assigns it to the player. The LCD is updated to reflect this added card. If the player's total point value exceeds 21, then a bust has occured and the machine transitions to the winner state. If not, the machine returns to the hit/stay state for a hit or stay to be chosen again.

Stay results in the dealer algorithm being activated. The dealer is forced to continue hitting until his total is above 17, at which point he must stop (as Vegas rules dictate). After the dealer has achieved an adequate point value, the machine transitions to the winner state.

The winner state determines which side has won, according to Vegas rules. Whoever has the highest point value that is still 21 or under is the winner with a few exceptions: if there is a tie on point totals 17 through 19, the dealer wins; on a tie on 20 or 21, it is a tie. At this point the program displays a W, L, or T, as necessary. When a button is pressed the game starts over again.

At reset, A "100" will be displayed at the bottom of the LCD, and each time the player wins/loses, it will be updated through a register at the winner state. Which will also determine if player should get some free money.

Results:

The blackjack game worked well by the end of our debugging. On the hardware side, it is unfortunate that we could not get the two line LCD to work at all (for whatever mystifying reason), for it would have allowed a more enjoyable game with the dealer's hand on one line and the player's hand on the other line. Yet at the very end, we managed to "steal" a 4 line LCD and were able to maximize the utilization of it. On the software side, it would have been better to have a 16-bit random number generator, as our 8-bit RNG has some recognizable card patterns during play. However, as a whole the program works well. We did not incorporate more advanced play options, such as "split" or "insurance", but we implemented the basic blackjack game, which is fun enough by itself.


What We Would Do Different Next Time:

It would also be ideal to increase or decrease bet size, for which we could have used the keyboard as input. We would also improve the RNG. As it is right now, the game is playable, but not as fun as it could be with a more reliable RNG. By "reliable" we mean a RNG can simulate real card shuffling pattern, instead of some "random" card pattern. That we have researched for, and the result was amazingly complicated and difficult to accomplish. Thus it remains a future key improvement for our game.


Link: http://instruct1.cit.cornell.edu/courses/e...jects/s1999/mo/