azure
-
Content Count
173 -
Joined
-
Last visited
Posts posted by azure
-
-
FYI: There is a buffer overrun bug in the latest version. It's happened twice in the span of 15 minutes of play, so if you see weird graphic issues or blanking out, it's probably that.
-
Is there anyway of adding a few seconds at the end of each hand to the program where you can't press a button or move the joystick and make the program take a timeout before moving on?
I could disable the joystick for a short period of time after the hand ends to eliminate inadvertent button presses.
-
Awesome!!! I love the sounds now!
There's still a glitch where once the dealer's hand is dealt, it immediately goes to the next hand and you can't see the cards that were dealt. The same thing happened during the broadcast of ZeroPage Homebrew.
I've not been able to reproduce this. I'll spend some time trying to reproduce it, but right now I don't know what it is.
I checked the Award's video again frame by frame. I'm pretty sure Darcy pressed the joystick up (STAY) and followed with a trigger press (CONTINUE), which means it worked as I intended it to. I made the trigger button function only as continue, because if I make the same button be both hit and continue, then accidental double presses would quickly advance to the betting screen, which would deny the user a chance see the result.
I could switch around the joystick functions, but I think that would be more confusing. I chose up for stay and down for hit to mimic the motion you make on a real blackjack table. I'm not sure how I can program the buttons differently to prevent missing the results. If I add confirmation dialog to continue, it would disrupt the flow of fast play. As I have it now, you can double press the trigger button to quickly select the same bet and start a new hand.
I'm open to anyone's suggestions on how to make the functions easier. I was planning to use the bottom chip row to show a joystick indicator or maybe put it above the dealer's row and shift everything else down. I'm running out of screen real estate, so I don't have many options without dramatically changing the layout (which I don't want to do). I really wanted to avoid flicker in this game so, using the side areas isn't going to work.
-
I've attached version 0.6 to the first post. Most the changes are non-graphical. I've bumped the ROM size up to 16K, because there wasn't going to be enough space for the animations I plan to add. I will be adding card animations on the deal (suggested by Thomas Jentzsch), but it's going to require some refactoring. There is a lot of code that could be further optimized, but it may not be worth the effort.
The next priorities are going to making available moves more intuitive, adding game options, animations, and finishing polish.
This update includes:
- A patch for a betting bug found by Arenafoot
- Sound effects
- A few routines were optimized
- Reorganized code for F6 bankswitching
- Wrote a simplified sound driver for sound effects
The bank layout is:
- Bank 0 contains the title screen.
- Bank 1 contains the game screen.
- Bank 2 contains game logic.
- Bank 3 contains the sound driver and sound data.
I had to add ballast code to get it to work on the Atari portable. I presume the portable was having trouble detecting the memory model. Thankfully, I had previously read a thread recommending it, so that saved a lot of debugging time.
-
3
-
It's interesting. The character sprites are great.
Although, something strange happened standing on the spot on this screen. I kept picking up something whenever I pressed select (ESC on the keyboard). It happened on the chest also. Repeatedly pressing the button seems to keep adding points.
-
I bought two of these extension cables last year. They're somewhat cheap, but there's a long shipping time. I think it was about 3 weeks.
They are not high quality, but they work fine. I use them as an easy way to swap joysticks without re-plugging into the back of the 2600.
-
I'm uploading a patched binary that works on the Flashback Portable. The AFP doesn't seem to like my program calling VBLANK in the overscan.
-
2
-
-
It does seem reminiscent of Xevious. The air battle would be similar, but I was thinking of interaction with ground bases. I like the idea of landing on bases for completing tasks (picking up colonists or supplies). That's why the ship flies backwards, so if you miss something you'll have to go back. I also like River Raid's game play so there might be elements of that in there like blowing up bridges or enemy encampments. I plan to add water, desert, and snow terrain. I can get that free by changing colors.
-
Just reporting in my results. My SD card was not working when it was formatted by Windows 10. It worked after reformatting with SD Formatter linked on the 1st comment.
It's a SanDisk Ultra II 2GB card and the portable is the 2017 version (70 games).
-
2
-
-
This is something I've been working on. It's not much. It's very basic, but the motion took way too long to get working the way I like. It's my 2nd game, so I'm still figuring things out: mostly audio and sprite positioning. It's coded in assembly.
It started out as a background scrolling experiment. Then it became a kick ball game. Then I added motion acceleration. Then the player became a space ship. I suppose now it's going to be a shoot 'em up.
The ground detail was supposed to be 1 line resolution, but that didn't leave enough cycles left, so it's a 2 line kernel now. The ground pattern is generated by an algorithm at compile time and repeats on a 64 byte cycle. I was thinking about doing horizontal scrolling too, but I'm not sure yet. I'm going to add some alien ships and some ground bases. It'll be about defending an exoplanet colony called Proton.
It's also using my code for table driven vertical positioning. It's an algorithm that uses a generic table of offsets, which is referenced by pointers. It shaves off a couple cycles at the expense of ROM (2 x 192 bytes + SpriteHeight). All sprites share the same table, so it's not duplicated. I'll put code samples in a blog post later on.
-
4
-
-
I'm pretty sure you meant 11 *AM* PT. Just want to make sure that no one misses it because they tuned in too late.
I ended up missing the live show. When I went to check the time again tonight, I thought I had read the time wrong.
-
What's the most obtuse Rube Goldberg contraption for loading a game? I think it needs a robot arm to tap the telegraph machine and a Raspberry Pi to control the robot. Some how this connects to the record player reading the game software.
-
What you're asking for is extremely difficult. Displaying any photograph on an Atari 2600 is a major undertaking, because the system doesn't natively support bitmapped graphics beyond two 8 pixel wide sprites. It can be done, but it requires a combination of sophisticated techniques and tricks, and the result is sub par with a blocky and pixelated result.
The second issue is which game? If it's an original game released in the 70s or 80s, there is no source code. The game would have to be disassembled and commented instruction by instruction by hand. Variables and subroutines would have to be identified, understood and named. That is a difficult multi-week or multi-month undertaking depending on the complexity of the game, the experience of the developer, and how much free time they have. Most of us are working on this part time, so we might have anywhere from 4 to 20 hours per week to work on projects. The best option would be selecting a game that's already been disassembled and commented, but that list is very short.
The third issue is does the game have enough remaining ROM space for inserting a photo and the accompanying code for rendering it? Space is limited so just about every 2600 game consumes all or most of the available ROM space. Half of the development process involves weeks or months optimizing and shrinking code so that more features can be squeezed into ROM. Every developer wants to pack their game with the most features possible, so they aren't going to leave blocks of ROM going unused.
The fourth issue is does the game have enough remaining RAM space? Many 2600 games use all the RAM, so extracting a single byte could require rewriting parts of the game that have already been through several rounds of optimization for space reduction.
The fifth issue is with the memory model of the game. Is it 2k, 4k, or 8k bankswitched or higher? Converting a 4k game to a bankswitched game is not a simple process. It requires decisions such as: Do I need one kernel for all banks? Should I use a different kernel for each bank? Can I move subroutines to another bank? Can I share subroutines between banks? Does this kernel need speedy access to data in another bank? Which subroutines and data must be duplicated in each bank? Answering these questions requires extensive analysis and deep understanding of how the game works. Simply adding another bank is not enough. The easiest option would be choosing a 2k game and expanding it to a 4k, but have you seen many 2k games? The original 2k titles were very simplistic and not that appealing next to 4k games that came out later.
The sixth issue is time and motivation. What's in it for the developer? It may seem like an easy task for someone unfamiliar with the Atari 2600's internals, but making simple things happen on the 2600 is not simple. Is there a compelling reason for someone to spend months working on your project? I wouldn't, because I don't have enough time for my own game. In addition to working on a game, I've been spending time on several partially implemented projects that will never be posted online. I have a text file containing 17+ game concepts I'm thinking about for my next game. Maybe one of those will get implemented, but I have to be choosy, because I'll be living with it for 6 to 18 months. I'm also investigating interesting graphic effects that could be used as the basis of a game. I've been a lurker since 2008, but I've only begun to get involved in the late spring of 2018. I'm positive the experienced developers doing this a lot longer have considered and discarded thousands of concepts and hundreds of unfinished projects. There isn't enough time in a life to accomplish all things we want to do on this platform.
Atari 2600 development is really time consuming, and it's an uphill struggle every step of the way, so I'm skeptical you're going to find someone interested.
-
-
I got a copy of Ace Combat 3 off Ebay. It looked interesting, so I'll see how it goes.
-
I got it at the Goodwill for $20. It turns out it's a NTSC Japan region locked PS1. I live in USA, so I've been debating on whether to keep it or sell it. Do you think it's worth keeping? I'll still be getting a USA PS1 in either case.
I don't know much about PlayStation systems, because I have only owned a PS4 and my kid mostly plays that.
-
Loved the Arcade version with Trak Ball. 2600 Version with joystick isn't any fun IMO. What you think?
Crystal Castles is one of my favorite 2600 games. I have the joystick down. I try to move diagonally to scoop up the gems in a diagonal row.
I'd like to try a trackball version though.
-
-
I finally finished reading the thread from start to finish. Whew. That was a lot of hard work.
-
5
-
1
-
-
I'm getting an AFP for compatibility testing, but not sure which one to get. Is the emulation in the 2016 version identical to the 2017 version? Did they fix the emulation bugs in the 2017 version?
-
After receiving some feedback, I updated my E.T. Completely Fixed version.
If I had this version in 1983, I would have played a lot more E.T.. I read the manual a few times, but I still could not get a handle of the game due to those pits. Raiders of the Lost Ark was one of my favorites, but it had a polished feel to it. E.T. felt rushed.
If only HSW had just a couple more weeks to fine tune this one...
-
That premise reads like a Season 2 Star Trek TNG episode.
-
I'm doing pretty good at it! up to $51,599.....can I cash out now?!?!?!?
Suggestion- anyway of adding an up or down arrow display for hit or stand? I keep forgetting which way is which.
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.
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.
-
7
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Clever or interesting uses of the BRK instruction?
in Atari 2600 Programming
Posted
It can be used for calling a subroutine with an argument. The BRK instruction takes an extra padding byte after the instruction. References frequently list BRK as being a 1 byte instruction, but it actually uses 2 bytes. I'm using it in my game for a generalized way to call subroutines in other banks with 1 byte argument.
It can be used to quickly strobe two bytes on RESx. That's also mentioned in the link above.
It can also be used to implement cooperative multi-tasking by placing task switching code in the interrupt handler.