azure

I haven't even gotten over 5,000 chips. ​ I may have to increase the player's chips to support up to 8 digits if you keep winning. I'm going go figure something out with a move indicator. I'm thinking of having a joystick icon show the available moves.

This is the latest version of my blackjack game. It is a WIP. Current version is 0.93. BlackJackThetaVIII-0-93.bin BlackJackThetaVIII-0-92.bin BlackJackThetaVIII-0-91.bin The features I've implemented so far are: F6 bank switching Screens: Title screen, Ship crash landing animation, Betting screen Play with 1, 2, or 4 decks Dealing to 75% penetration, Deterministic card dealing Navigation menu, Dashboard display of current options Game Options: Early surrender (Es); Late surrender (Ls); Hit on soft 17 (H17); Stand on soft 17 (S17) Hand Options: Double down (D); Surrender (Su); Insurance (I); Splitting hands (Sp) Card flip animation, Sound effects Features I will be adding next: Expanding the betting denominations Keypad controller support Making the player's chips represent current number of chips Fixing the split hands interface, because it's confusing Winning hand animation Out of money animation (you're doomed) Breaking the bank animation (the ship departs) Idle animation More graphics and sound touches Features I'm considering: Red/Black pip colors Looking into allowing more than 2 split hands ---------- Premise: You're a NASA astronaut who crash landed on the uninhabited, inhospitable planet Theta VIII. You're living out the rest of your life in an artificial hotel casino created for you by the intelligent species who damaged your craft and killed your crew. Not knowing your preferred living conditions, the intelligent species constructed the hotel using the narrative from a poorly written pulp fiction novel in your possession. You can't leave and Blackjack is your only entertainment. However, there may be an escape. The casino closely resembles the story in the novel, which describes a casino being bought up by foreign investors. Perhaps your way out is to break the bank! ---------- Instructions: This game uses the joystick in the left port. Left difficulty switch: A = late surrender (harder) B = early surrender (easier) Indicated by Es and Ls Right difficulty switch: A = dealer hits on soft 17 (harder) B = dealer stands on soft 17 (easier) Indicated by S17 and H17 Select switch: Cycles between 1, 2, and 4 decks Changing decks will trigger a reshuffle and empty the discard pile Indicated by 1d, 2d, or 4d Black & White switch: Currently not implemented. This may enable red and black color pips in a future release. Title Screen Press Fire to continue Landing Screen Press Fire to continue Betting Screen Up or Down to increase or decrease the bet Left or Right to select the chip denomination Press Fire to begin the hand Game Screen Left and Right cycle through available moves Pressing Fire or Down takes the selected action When the hand is over, pressing Fire starts a new game Pro-Tip for quick play: When Hit is selected, pressing Up will stand pat Split Hands The currently selected hand is white and the inactive hand is grey. When both hands are over, pressing Up or Down displays the score of each hand. ---------- Blackjack Rules: A bet must be made before playing a hand. The goal is to reach a score of 21 without going over. A player requests more cards by hitting and ends their hand by staying (i.e. standing pat). Face cards are worth 10 points. An ace is worth 1 or 11 points depending on which is preferable. The remaining number cards are worth their number value. Achieving a 21 score is a blackjack, which pays out 2 to 1. Achieving 21 with only two cards is a natural blackjack, which pays out at 3 to 1. Scoring over 21 is a bust, which loses the hand and the bet. If the dealer receives an equal score, the game is a push, so the bet is returned. If both the player's opening cards are duplicates or 10 point cards, they may split their cards into two hands. Splitting cards requires making a 2nd equal bet. The player may double the bet on any opening hand by doubling down. The hand will be dealt one card then play moves to the dealer or the next split hand. Doubling down requires making a 2nd equal bet. The player may take an insurance bet if the dealer's opening card is an ace or 10 point card. Taking insurance is betting on the dealer having a natural black jack. If the dealer does not have a blackjack, the player loses their insurance bet and play on the hand continues as normal. Insurance requires making a bet one half of the original bet. A player may surrender on any hand. Surrendering ends the hand and returns one half of the bet. Surrender is not available after the opening move. Receiving a blackjack or 21 score will automatically end the hand. Play moves to dealer or the next split hand. Additional Info: Blackjack A natural blackjack pays 3 to 2. A blackjack on any split hand pays 2 to 1. The dealer checks if it has blackjack before hitting the player's hand. A player's natural blackjack is a push against the dealer's natural blackjack. Dealer The dealer may hit or stand on soft 17 as configured by the left difficulty switch The dealer reshuffles at 75% deck penetration. Double down Double down pays 2 to 1 of the original bet. Double down is available on split hands. Splitting Splitting hands is permitted on two equivalently valued cards. It requires another bet equal to the original bet. Split hands cannot be split again. Double down, insurance, and surrender are available on split hands. A blackjack on a split hand pays out 2 to 1. Surrender Early and late surrender is configured by the right difficulty switch Surrender returns 50% of your original bet. Insurance Insurance is offered when the dealer shows an ace or 10 value card. The insurance bet is 50% of your original bet and pays 2 to 1. Miscellaneous Winnings that are not evenly divisible by 2 are rounded down. The game ends when the player is out of chips or breaks the bank. A soft 17 is a hand containing an 11 point ace that totals to 17. Example: Ace + 2 + 4 = 17 New title screen: Old title screen left for comparison: Dev Notes: The user interface still needs work. The split hands are confusing, because it's hard to tell which is the active hand. The in-game bets need more feedback when the player lacks the chips to make the bet. The in-game bets include double down, insurance, and splitting cards. I'm looking into adding red and black pip colors. They will be enabled with the Black & White switch. The texture background must be disabled, because I need the playfield to render pip colors. I like the look of the textured background, so I'm keeping it as an option. What I mean by deterministic card dealing is the random number generator is seeded once when the deck is shuffled. It is not reseeded again until the next shuffle. The intent is to mimic a physical deck of cards, so once the cards are shuffled they will be dealt in a deterministic order. Continuously reseeding would mimic a continuously reshuffling deck, which was not my preference, because it defeats card counting. I'm also looking into allowing more split hands. It should be possible with the available RAM. I don't know if this version works on the portable, because I have only tested on Stella and a 4-switch. Known bugs: This was working before, so I'm not sure what happened. There are line count issues with 2 decks, but apparently not with 1 or 4 decks. You can force a reshuffle and switch decks in the middle of a hand.

Stella's print command doesn't appear to work correctly for $1e and $1f. But it works without the $ prefix. Stella 5.1.3, 64-bit

Tapper.

You caught me. Could you tell by the pixels?

Define.. "edit".

I think I have you beat. Totally legit!

Does anyone know if there will be live streaming at the PRGE?

ok

Playing Missile Command would be interesting with a mouse. Also, have you thought about trying a PC mouse with a PC to ST adapter?

I'm using the latest stable version. Stella 5.1.3 Features: Sound Joystick Debugger Cheats Build 4152, using SDL 2.0.5 [x86_64] I get different results based on when and where I break into the code and whether or not the code gets stepped into. I wasn't seeing a pattern earlier, because some subroutines were disassembled and others weren't. It seems to work better if I let it step through the code and don't mess with manually changing the bank in the UI. Doing that gives weird results.

I'm using F8 bankswitching, which is working fine, but I have an issue with Stella when it's in debug mode. It's not showing the right labels for the 1st bank nor is it showing consistent disassembled source code. For example: if you have these banks: ; bank 0 ORG $1000 RORG $d000 ; bank 1 ORG $2000 RORG $f000 See attached images. It works fine when running from the 2nd bank, but switching to the 1st bank shows labels from 2nd bank. This is hampering testing, so is there is there a way make Stella show the right labels and disassembled source when it's running on the 1st bank?

One of the things that keeps me digging through old threads is the lore of "Atari programming" particularly the trials and tribulations. Has anyone made a project out of curating all the fascinating homebrew stories? And it's not just the successfully released games, it's also the failures, the grandiose claims, the evolution of the algorithms, and the struggle to understand the platform. Documenting the notable failures might be embarrassing to some, but it's also an interesting part of the record.

I worked on some artwork for the game using Inkscape. It could use some more details, but the gist is there I think. It's a strange concept, but I think all Atari 2600 games should be space games.

You got up to 6500 chips? Wow. I think my RNG algorithm is probably biased. I just slapped it together. I intend to spend some time on it; however, the thing about that is I might implement difficulty levels, so an algorithm that can be tuned to bias the results would be nice.

I don't think it's possible without going to a 2 line kernel or skipping frames, because there aren't enough cycles to alternate colors that fast. I think it's more important to stay with a higher resolution and avoid flicker, so I don't plan to implement suit colors.

I wanted to go with 8 decks, but I won't have enough RAM once I implement the remaining features. I would have to cut game play, which I really don't want to do. I track the dealt cards in a 26 byte data structure. One bit represents one unique card. Going to 6 or 8 decks would require another 26 bytes of RAM. I have 28 bytes free, so while it is technically possible now, I would still need to re-think (or combine) some of the other variables to reclaim more RAM. I've already been through a few rounds of optimizing for space, so I've done the easy optimizations. I'll revisit the 6 & 8 decks after I've implemented more features, but right now I consider it less important, because it doesn't affect the player's experience. I also have a plan to add an option to select the number of decks, so single deck play will be in the game. I can see this working technically, but I really like the horizontal layout. If I went with a staggered or vertical layout, it wouldn't resemble a blackjack table very much. Suits and colors don't matter in blackjack, so I figure it's not worth making compromises on the layout. I can't think of any way it's possible with the horizontal layout without introducing flicker or reduced vertical resolution. There aren't enough cycles, and I really don't want to introduce flicker. Flicker is a lot more annoying for fixed position sprites.

Thanks guys.

Blackjack Theta VIII You're an astronaut stranded on the planet Theta VIII living out the rest of your days in a hotel casino. There is no exit and Blackjack is your only entertainment. This game uses the joystick: Betting Screen Up or Down to increase or decrease the bet Left or Right to select bet amount Fire starts a new game Game Screen Up to stand Down to hit Fire starts a new game This game is still a work in progress, so this version is a beta. The core functionality is working, but I have plans for many more features including double down, surrender, insurance, splitting hands, difficulty modes, more graphics touches, and sound. My goals were accurate casino play and better graphics compared to Atari's Blackjack game. The current features are: true 4 deck card game dealt cards are tracked to prevent dealing duplicates 6 on-screen cards unlimited off-screen cards, which are tracked as a point total I'm running out of ROM space, so I'll have to increase the ROM size to 8K in the next version. I don't have enough space for the title screen, so I placed it into a separate demo. Let me know if you find any bugs or have any game play suggestions. BlackJackThetaVIII-beta-0-3.bin Title-beta-0-3.bin

Artifacts happen when your kernel doesn't write to the graphics registers on time. When the beam is running across the visible part of the screen, the kernel has little time to do much else, because its busy shuffling data to the graphics registers. The kernel is like a passenger trying to catch a moving train. If you're late you've missed your chance, so your sprite doesn't get displayed. If you're on time it gets displayed. If you're early, it's okay in the simple case when you only have 2 sprites on the same line (e.g. Combat). However, if you're dynamically repeating sprites with NUSIZ0/NUSIZ1, such as using the 48 pixel trick, writing registers early doesn't work. Each write must occur precisely within a narrow window of time, because the kernel is playing a shell game with the GRP0 and GRP1 registers. That's the cost of using two sprite registers to simulate six sprites. This is why cycle counting matters so much. The timing of each write depends on which cycle count it lands on. That's because the timing has already been worked out. If you insert a nop in the middle of the 48-pixel sprite algorithm, you'll see rendering artifacts, because it will shift the timing of the writes. It can happen with the playfield if the kernel is trying to do asymmetric playfields (e.g. Ms Pac-Man) and it gets the timing wrong. But, if your playfield remains static for the duration of a line (e.g. Combat), it's a set and forget situation. You can write the patterns early to PF0, PF1, PF2 at the start of the line while the beam is in the horizontal bank and then sleep for the rest of the line. I really recommend Andrew's tutorials. They get into specific details explaining how things work.

I've completed another small milestone with my project. Most of the updates aren't visible to the user, but I added a new message bar which I think looks a lot better than what was there before. The most significant update is the addition of the discard pile and reshuffling logic. The discard pile prevents duplicate cards from being dealt. A duplicate card in my game is two cards with the same deck, suit, and rank values. The game is still minimal, but the basic play is working much better compared to the last update. The features so far include; basic play for 1 player 4 decks of cards 6 on screen cards cards pushed off screen are stored as a sum tracking of discarded cards deck penetration to 75% reshuffle upon reaching 75% message bar for prompts and win/loss results status bar that displays player and dealer scores event driven loop: it makes it easy to split computations across frames and greatly simplifies game logic Joystick Controls: Down for hit Up for stand or start new game Fire for start new game Current Problems: I'm running out of ROM space, so I've had to make significant changes in order to reduce ROM usage. I pushed many of my MACROs into subroutines to reduce repetitive code. The game is very light on the CPU, so I have plenty of CPU to work with. Subroutine overhead is not really an issue even within the kernel, because the gap spaces are available for computation. The player will be idle for 1 to 2 seconds before they make a move, so that gives me more than enough frames for computations. I may have to switch to an 8K ROM if I want to keep most of the features I originally planned for. I will be adding sound and possibly some animations, so realistically that's not going work with my current 4K implementation. I really wanted to remain at 4K, so I'm going to dig deep into refactoring. The sprites can be compressed a little by overlapping whitespace., but more savings can be made by compressing the title screen's graphic. The title screen uses very little RAM and CPU, so decompressing it on the fly to RAM might work if I horizontally split the graphic into three smaller pieces with gaps in between. The gaps provide time for loading the next block. Despite all that, I still think I will eventually end up going to 8K. Maybe I'll have a 4K version and an 8K enhanced version. I'm unsure. As for RAM space, I've still got 25 bytes of RAM free. I'm thinking about cutting out the 2nd player option and reducing the on-screen cards to only 5. Those changes would free up 11 bytes. I'm using 8 bytes for the stack, so I could probably save 2 bytes there. I might be able to save another 3 to 6 bytes by merging a few variables and recalculating scores on the fly. The discard pile uses 26 bytes of RAM, which is at its minimum possible size. I use 2 sets of sprite pointers for displaying the upper and lower halves of the cards. The 2nd set consumes an extra 12 bytes, so this has bothered me from the start, so I'll be thinking about how to free those bytes up. VDEL might work for me here, but I need to understand it better. I had been thinking about supporting 6 and 8 decks of cards, but I can't currently do it, because it needs another 26 bytes of RAM and significant changes to the bit packing. I could support it by cutting out the 2nd player and the ability to split hands, but I'm prioritizing accurate game play, so I will be going ahead with split hands and only 4 decks. There is some infrequent screen bounce that happens when the discard pile is close to 75% capacity. The problem is caused by my card dealing logic, which has to enter retry logic whenever the random number generator selects an already discarded card. I have a plan for fixing it, but it will require rewriting my card dealing routine. I'm still not completely sure how I'm going to display the player's chips and how the betting mechanics are going to work. I have some ideas, but they're rudimentary. I'll be working on that part next along with refactoring the code to reclaim more ROM space. Programming: Here's a quick description of my discard pile's layout and how they're indexed by the cards. The cards are represented as a byte. ; card: single packed; deck suit rank; bits: 7 6 5 4 3 2 1 0;; rank: 0 = empty card slot; 1-13 = ranks ace through king; 14-15 = unused The discard pile is an array of 26 bytes. Each byte represents 8 cards and each nibble is a composite of deck and suit values. A card is flagged as discarded if its bit is set to 1. The card's rank (low nibble) selects the row in the discard pile. The deck and suit (high nibble) select the bit within a row. Furthermore, bit 7 determines which row of decks the card belongs in. Shuffling the decks simply erases the discard pile and re-inserts cards from the player and dealer's currently active hands. Bit assignments: Diamonds: bit 0 or 4 Clubs: bit 1 or 5 Hearts: bit 2 or 6 Spades: bit 3 or 7 ; suits suits; | S | H | C | D | S | H | C | D |; ---------|----|---|---|----|----|---|---|----|------; byte|rank| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | index; ----|----|----|---|---|----|----|---|---|----|------; 1 A |.................|.................| 0; 2 2 |.................|.................| 1; 3 3 |.................|.................| 2; 4 4 |.................|.................| 3; 5 5 |.................|.................| 4; 6 6 |.. ..|.. ..| 5; 7 7 |.. Deck 1 (01) ..|.. Deck 0 (00) ..| 6; 8 8 |.. ..|.. ..| 7; 9 9 |.................|.................| 8; 10 10 |.................|.................| 9; 11 J |.................|.................| 10; 12 Q |.................|.................| 11; 13 K |.................|.................| 12; ----|----|-----------------|-----------------|------; 14 A |.................|.................| 13; 15 2 |.................|.................| 14; 16 3 |.................|.................| 15; 17 4 |.................|.................| 16; 18 5 |.................|.................| 17; 19 6 |.. ..|.. ..| 18; 20 7 |.. Deck 3 (11) ..|.. Deck 2 (10) ..| 19; 21 8 |.. ..|.. ..| 20; 22 9 |.................|.................| 21; 23 10 |.................|.................| 22; 24 J |.................|.................| 23; 25 Q |.................|.................| 24; 26 K |.................|.................| 25; ----|----|----|---|---|----|----|---|---|----|------; byte|rank| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | index; ---------|----|---|---|----|----|---|---|----|------

Sort of. The cards are aligned to the columns to help hide the fact the suits are a little too large for the cards. I tried making smaller suit sprites to make them fit, but they didn't look right. 7 pixels wide is about the minimum you can make a club and heart look like a club and heart.

Thanks guys. I wasn't aware of the Blue 21 game. The adult theme is probably why I didn't see it. My game will be for all ages, so I think it's worthwhile increasing the game library. I actually hope to support up to 8 decks, but I can't estimate the RAM usage until I settle on a final data model, so I'm only committing to 4 decks for now.

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. Why Theta VIII? You're an unfortunate guest of the Hotel Royale on the planet Theta VIII. Roadmap 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 Accurate game play is my number one priority. My goal is for card counting to actually work with a single player, 1 or 2 deck game, which requires that no duplicate cards can be dealt, random numbers must be unbiased, and the deck is dealt to a realistic depth of penetration (between 50% to 75%). Technical Details 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. Hardware Testing The game is completely untested on hardware, because I don't have a Harmony cart. I'll get one sooner or later.