Black Jack Theta VIII - (A new 2600 game) - WIP
blackjack Theta VIII Atari 2600 WIP homebrew programming
This is very early version of my first Atari 2600 game. It is is intended be more feature filled than the Blackjack game released by Atari. My goals are accurate casino play, higher quality graphics, and supporting a true multi-deck shoe without dealing duplicate cards.
Why am I making this game? I like Blackjack, and I don't like the official Atari version. The Atari 2600 is the reason I became a programmer, so I'm somewhat fond of the 2600 and 6502 programming. I made an attempt in 2008 with a different game concept, but I didn't have the time to work on it. I had accepted a new job that kept me extremely busy.
The joystick controls are simple:
- Press down to HIT.
- Press up to STAY.
- Press fire to begin a new game.
This is a work in progress, so the features are very limited. The controls will evolve as features are added. The core game play appears to be working, but it's not well tested. The status bar at the bottom displays the player's score, dealer's score, and the current game state. Those will be removed in future revisions, but the status bar will show message prompts, chip totals, and win/loss status.
I'm posting on my blog to stay off the forums for now. This version is way too early for game reviews. It's bare bones. I have to return to my other work for a while, so my rate of progress will slow down for a while. I hope I can have it complete after about a year.
I have plans to add many more features and user interface touches. Here's a short list in order of descending priority (although they're all important):
- accurate casino game play with betting, double down, splitting (only 1 split planned), surrender, insurance, etc
- no duplication of cards (cards are unique by deck, rank, and suit)
- betting mechanics and player's chip management
- sound effects
- a 2nd player: paging left and right will switch between players. I gave up my original plan to show 3 hands on a single screen. It won't be practical.
- support for 1 deck with 75% penetration and up to 4 decks with less penetration
- improving UI feedback: getting rid of the ugly Hit/Stay/Win/Lose graphics; using the bottom status bar instead
- lots of game options and variations (such as dealer hits on soft 17, early or late surrender, color scheme, number of decks, etc)
- sprite animations
- more graphic touches
I've attached the binary and some screenshots, but not the source. I'll attach the source after I've rewritten a few messy subroutines. I'm somewhat inexperienced with 6502 assembly, so there's lots of room for optimizing the code (and data). Let me know if you find any bugs or inconsistent scan line counts. I'm rendering at 262 lines. When I release the source, I hope to get some tips on better assembly programming. Until then I just really like solving problems on my own.
The only problem I've been unable to solve so far is I couldn't get the joystick latches to work. I had to write my own latch logic, but I'd prefer to use the hardware latches to free up some space.
You're probably wondering how I'm storing 4 decks in 128 bytes. Well, I'm not. I'm storing the cards in play (meaning they're dealt to an active hand) in a packed format. I'm currently using this format:
; Card: Single packed ; deck suit rank ; Bits: 7 6 5 4 3 2 1 0 ; ; Rank: 0-13 = ranks Ace through King ; 14-15 = unused
The discard pile is a different situation from the active cards in play. I'm currently not storing discards. Cards shifted off screen are summed into a total, which doesn't work for preventing duplicates. A combination of strategies is what's going to work.
The discard pile doesn't require knowing who has which card. It only needs to know which card is available to deal, so I could use a bitmap. Four decks contains 208 cards. If one card is one bit, then the entire 4-deck shoe can be stored in an array of 26 bytes.
; Cards 0 to 8 : 7 6 5 4 3 2 1 0 ; Cards 9 to 16 : 7 6 5 4 3 2 1 0 ; Cards 17 to 24 : 7 6 5 4 3 2 1 0 ; Cards 25 to 32 : 7 6 5 4 3 2 1 0 ; Cards 33 to 40 : 7 6 5 4 3 2 1 0 ; ...
The average hand consumes about 4 to 6 cards, so the RAM usage is low for the average case. The trouble is dealing with worst case scenarios, which could deal 20 or more cards to a single player given multiple decks and splitting hands. The worst case contains all the lowest valued cards for both the player's and dealer's hands.
I have to balance the worst case scenario of active cards in play with the format for the discard pile. If I don't go with the bitmap, then I'll have to settle for implementing a circular buffer for storing the discards. It will truncate the card history, but would only affect a very small percentage of hands.
I currently have about 45 bytes of RAM free. I'm wasteful with RAM, so I have some easy optimizations to make for freeing up space.
This version represents the culmination of about 1 month's work so far. I spent a week rewriting code that wasn't going to work, and then spent another 2 weeks goofing around with writing my own horizontal and vertical positioning algorithms. In the end I just ended up just using the divide by 15 method. Heh. Heh. SkipDraw is not used, because the vertical positioning in this game is trivial. Nothing moves and everything is divided into fixed size rows.
The game is completely untested on hardware, because I don't have a Harmony cart. I'll get one sooner or later.
- Gemintronic likes this